Scheduled or event-driven: choosing a trigger

Use events when latency matters or when polling would waste most of its runs. Use a schedule when the source has no webhooks, when you need a complete picture rather than a stream of changes, or when batching is genuinely cheaper. Most production systems need both - events for responsiveness and a scheduled reconciliation for correctness - because events alone cannot tell you about the ones that never arrived.

Event-driven is treated as the modern default and polling as legacy. The distinction that matters is not modernity, it is what each one can and cannot tell you.

Key takeaways

Polling gives you a complete current picture. Events give you a stream you might have gaps in.
A schedule that finds nothing most runs is waste; that is the real argument for events.
Events cannot tell you what did not arrive. Only a scheduled check can.
Frequent polling is not a substitute for events - it is expensive and still not immediate.
The hybrid, events plus periodic reconciliation, is the shape most correct systems end up with.

Who this applies to

You are deciding how a workflow gets triggered - a scheduled poll, a webhook from the source system, or something in between.

What each one actually gives you

A schedule is a query. At 2am you ask the source system what its state is, or what has changed since last time, and you get a definitive answer. If your job ran, you know what was there.

An event is a notification. The source tells you something happened. You learn about it faster, and you only learn about the things it chose to tell you and successfully delivered.

That difference is the whole decision. A query gives completeness; a notification gives latency. Which you need depends on the workflow, and a surprising number of workflows need completeness far more than they need speed.

	Scheduled	Event-driven
Latency	Half the interval on average	Seconds
Runs when nothing changed	Every time. Most runs do no work	Never
Load shape	Predictable, and spiky at the boundary	Follows the source, including its bursts
Tells you about deletions	Yes, by comparing state	No. There is no event for a thing that stopped existing
Tells you about missed items	Yes, inherently	No. A dropped webhook is silent
Survives your endpoint being down	Yes. The next run catches up	Only if the sender retries, and only for as long as it does
Needs the source to support it	No	Yes, and many do not
Fails by	Being late, visibly	Being incomplete, invisibly

A schedule is late and complete. Events are fast and occasionally, silently, incomplete. The hybrid is events for speed with a scheduled reconciliation for the items that never arrived, and the number it finds is a health metric.

When a schedule is right

No webhooks available. Plenty of systems, particularly older or internal ones, have no push mechanism. The decision is made for you.

You need the current state, not the changes. A nightly report on all open positions is a query. Reconstructing it from a stream of change events is possible, more complex, and wrong if you dropped one.

Batching is genuinely cheaper. One request for 500 changed records beats 500 individual webhook-triggered runs, against both your rate budget and your platform’s billing - see rate limits and API quotas.

The work is inherently periodic. Month-end close, weekly digest, daily reconciliation. There is no event; the schedule is the requirement.

Latency genuinely does not matter. If acting within a few hours is fine, the added machinery of reliable event handling buys you nothing.

When events are right

Latency matters to a person. A customer waiting for a confirmation notices four minutes. Polling at that frequency is expensive and still not immediate.

Most polls would find nothing. A schedule running every five minutes against a source that changes twice a day wastes 570 runs to catch two. That is worker capacity, API quota and money spent on nothing, and it is the strongest argument for events.

The volume is spiky. Events absorb bursts naturally; a fixed schedule either lags behind a spike or over-provisions for the quiet period.

The source charges per request. Polling a metered API frequently is a direct cost that events remove.

Events also arrive more than once, out of order, and occasionally not at all - see webhooks that drop for the three defences that handle each case. And a sync that quietly stops producing anything reports success the whole time - see the integration that silently stopped syncing.

What events cannot do

The limitation that decides the architecture: an event you never received is invisible.

If the sender had an outage, if your endpoint was briefly down, if a delivery exhausted its retries - the event is gone and nothing in your system knows it existed. There is no error, no gap in a sequence, nothing to alert on.

This is not hypothetical. Deployments cause brief outages, and webhook providers abandon delivery after their retry window. See webhooks that drop for the delivery mechanics.

The only defence is a query: periodically ask the source what changed since your last confirmed sync, and process anything you do not have.

Which means that for anything where correctness matters, you need a schedule regardless of whether you use events. Not as the primary path - as the safety net.

The hybrid

The shape most correct systems converge on:

Events for the fast path. Webhooks trigger immediate processing. This is what users experience.
A scheduled reconciliation for the slow path. Daily, or hourly for higher stakes, query the source for changes since the last successful sync and process anything missing.
Deduplication across both, so a record processed by the event path is not processed again by reconciliation. Dedup on the source’s record and version, not on arrival.
Monitoring on the gap. If reconciliation regularly finds items the event path missed, your webhook handling has a problem worth investigating rather than absorbing.

That last point is what stops the reconciliation job from quietly masking a broken webhook endpoint. It should find nothing on most days, and the number it finds is a health metric.

The cost of the hybrid is one extra scheduled workflow and a deduplication check. That is small against the alternative, which is a system that is fast and occasionally, silently, incomplete.

Choosing a polling interval

Where you do poll, the interval is a cost decision more than a latency one.

Ask what a run costs - platform billing, API quota, worker capacity - and what a stale record costs. Then pick the longest interval where staleness is acceptable, rather than the shortest your platform allows.

Two practical notes. Poll on a change cursor, not a full scan, where the API supports it - “give me records modified since X” is dramatically cheaper than fetching everything and comparing. And stagger schedules so that twenty workflows do not all fire at the top of the hour, creating a load spike and a rate-limit collision that would not exist if they were spread.

What we default to

Events where the source supports them and latency matters, a scheduled reconciliation alongside for anything where a missed record has consequences, and deduplication across both paths.

The reconciliation job is the part clients most often want to cut, on the reasonable grounds that the webhooks work and the job finds nothing. The argument for keeping it is what it costs to be wrong: a gap in event delivery is undetectable by construction, so the choice is not between two ways of finding out, it is between finding out and not.

The related position: we treat “how often does reconciliation find something” as a monitored metric rather than an incidental. If it climbs, the webhook path has degraded, and that is a signal you get nowhere else.

Where we push back the other way: teams sometimes ask for five-minute polling as a substitute for webhook handling, because polling is simpler and they would rather not build reliable event intake. That is a defensible trade at low volume and a bad one at scale - it spends real money on runs that find nothing, and it still is not fast. If latency genuinely matters, build the event path properly; if it does not, poll far less often than five minutes.

When neither is the right question

When the work should not be automated yet. A trigger design for a process nobody has agreed is premature.

When the source can push into a queue directly. Some platforms integrate with a message queue rather than HTTP webhooks, which gives you durability the webhook path lacks.

When it is really one job. A daily report does not need this analysis. Schedule it.

Frequently asked questions

Is polling always more expensive?

No. At low change rates with batch endpoints, one scheduled query for many records can be cheaper than many individual webhook-triggered runs, particularly where your platform bills per execution.

How often should reconciliation run?

Daily for most business systems. Hourly where a missed record has customer-visible or financial consequences. The cost is one query.

Can we use events without deduplication?

Only if processing is genuinely idempotent. Webhook delivery is at-least-once, so duplicates are expected rather than exceptional.

What if the source has neither webhooks nor a change cursor?

Full scans with change detection on your side, at the lowest acceptable frequency. Unpleasant, common with older systems, and worth pushing the vendor on.

Does event-driven mean lower latency in practice?

Usually seconds against minutes, provided your intake acknowledges fast. An event path that processes synchronously and times out is slower than polling and less reliable.

Next step

If you are event-driven with no reconciliation, the gap is real and currently invisible. The business process automation engagement builds both paths with deduplication across them.