Should a Schedule or a Trigger Run Your Automation?

Should your automation run on a schedule or fire on an event?

Use a trigger when the work must happen close to the moment something changes, and a schedule when it must happen reliably. Those two properties pull against each other more than most people expect, and picking the wrong one is the most common structural mistake I see in marketing automations.

The default is usually a trigger, because triggers feel modern and demos look better when something happens instantly. That instinct is right about half the time. The other half, it produces a workflow that is fast when it works and silently absent when it does not.

The decision is worth making deliberately, because it determines how your automation fails, and how it fails matters more than how it runs.

What does a trigger actually give you?

Immediacy and precision. A webhook fires when a specific thing happens, carries the details of that thing, and does no work at all the rest of the time. For anything where a delay is visible to a customer, such as a lead notification or an order confirmation, that is exactly what you want.

The precision is underrated. Webflow's webhook events are specific rather than general, covering form submissions, site publishes, page creation, page metadata updates, page deletion, ecommerce orders and inventory changes, collection item creation, changes, deletion and unpublishing, and new comments. You subscribe to the event you care about instead of polling everything and comparing.

That specificity is what makes triggered automations cheap to run. A scheduled job that checks for new items has to look at everything and work out what changed. A webhook already knows, which means less compute, fewer API calls, and no window in which a change can slip past unnoticed.

What happens when a trigger fails?

It gets retried a limited number of times and then it is gone. Webflow's documentation is precise about this. Your service should return a 200 response, any other response is regarded as a failure, and the maximum number of retry attempts after an unsuccessful call is three, at an interval of ten minutes between each retry.

Read that as a total window rather than as a safety net. Three retries at ten minute intervals means your receiving endpoint has roughly half an hour to come back before that event is simply lost. If your deploy takes forty minutes, every event during the outage is gone, and nothing in your system will tell you which ones they were.

The failure conditions are broader than an outage, too. Webflow counts redirects encountered while delivering the payload as a failure, and counts it as a failure if it cannot successfully negotiate or validate your server's SSL certificate. A certificate that renews badly at three in the morning is a webhook outage, and it will not look like one in your monitoring.

Why do triggered automations go quiet without warning?

Because platforms switch them off. Webflow says that if it repeatedly encounters failure conditions while attempting to deliver a webhook payload, it will deactivate your webhook to prevent further delivery attempts. That is sensible platform behaviour and it is also the single most dangerous property of event-driven workflows.

The reason it is dangerous is that deactivation produces no error. Nothing fails afterwards, because nothing runs. Your dashboards show zero failures, your logs are clean, and the workflow has stopped existing. Weeks later somebody asks why the CRM has no new leads from the website, and the answer is that a certificate expired in month one.

This is the specific shape of an automation that fails silently, and it is why I treat the deactivation clause as the deciding factor on anything business-critical. The question is not whether your endpoint is reliable. It is what happens during the one window where it is not.

When is a schedule the better choice?

When completeness matters more than speed. A scheduled job that asks what has changed since the last run will pick up everything eventually, including whatever happened while your endpoint was down. It is slower, it is less elegant, and it is much harder to lose data with.

Reporting, syncing, enrichment, cleanup and anything that feeds a weekly or monthly number all belong on a schedule. Nobody cares whether the figure updated at 09:00 or 09:15. Everybody cares if three days are missing from it, and the scheduled version simply cannot produce that failure as long as it tracks a watermark of what it last processed.

Schedules also fail loudly, which is their real advantage. A job that did not run is visible as an absence at a known time. You can alert on it trivially, because you know exactly when it should have happened, and that is not true of an event that may or may not have occurred.

Can you use both?

Yes, and for anything important you should. Run the trigger for responsiveness and a scheduled reconciliation job behind it that catches whatever the trigger missed. The trigger handles the common case in seconds, and the schedule guarantees that the system converges on correct.

The reconciliation job does not need to be clever. It asks what has changed since the last successful run, compares against what was processed, and handles the gap. Most of the time it finds nothing, which is exactly what you want it to find, and the days it finds something are the days it paid for itself.

Make sure the reconciliation is idempotent, meaning that processing the same item twice produces the same result as processing it once. Without that property, your safety net creates duplicates, which is a worse problem than the one you were solving. This is the same care rate limits and retries demand elsewhere in the stack.

How does this change what you monitor?

You stop monitoring for errors and start monitoring for absence. For a scheduled job, alert when it has not completed by an expected time. For a triggered workflow, alert when no event has arrived for longer than your normal quiet period, because the absence of events is the only signal a deactivated webhook produces.

That second alert is the one almost nobody builds, and it is the one that would have caught most of the broken automations I have been asked to look at. It requires knowing your own baseline, which means you need to have looked at how often the event normally fires before you can say what suspicious looks like.

Also monitor the webhook registration itself, not only the traffic. If the platform can deactivate a subscription, then whether the subscription still exists is a thing worth checking on a schedule. Checking that the wiring is still connected is cheap, and it is a different question from whether the wiring is carrying anything.

What does this look like on a Webflow site?

Form submissions are the obvious trigger case, because the delay is visible to a person waiting for a reply. Collection item events are useful for keeping an external system in step with published content. Site publish is the one people forget, and it is genuinely handy for cache clearing and downstream rebuilds.

The case I would put on a schedule is any sync between Webflow and a system of record such as Airtable or a CRM. Those syncs care about completeness rather than latency, and a nightly reconciliation catches the items that were created during a deploy, a rate limit, or a certificate problem. Being minutes behind on a blog post has never cost anybody anything.

Whichever you choose, decide what the workflow may write before you decide when it runs. A scheduled job with too much access is no safer than a triggered one, which is why I keep coming back to what an automation should never be allowed to do as the first question rather than the last.

What should you do next?

List your automations and mark each one as latency-critical or completeness-critical. Very few are genuinely both, and the ones that are should have a trigger plus a scheduled reconciliation behind it, rather than a meeting about which approach is philosophically better.

Then go and check whether any webhook you depend on has been deactivated. This takes minutes and it is the highest-yield check in this whole article, because a deactivated subscription is invisible from every other angle and it may already have been gone for weeks.

Finally, add one alert for absence on your most important workflow. Not an error alert, an absence alert. If you want help working out which of your automations is quietly one bad certificate away from disappearing, reach out and I will go through them with you.