What is an automation trigger, and which kind should you use?
Schedules, events, webhooks, and polling behave differently when things go wrong. Choosing by what a missed or duplicated trigger costs, rather than by what is convenient.
Rebecca Pearson11 min read
On this page
A trigger is whatever causes an automation to run. The choice looks like a detail and is not: it determines how promptly the automation reacts, how it behaves when something is briefly unavailable, and — most importantly — what happens when a trigger is missed or delivered twice.
That last question is the one worth deciding first, because every trigger type has a failure mode and choosing without knowing which you are accepting is how automations quietly stop doing what anybody expects.
What we'll cover
The four kinds
A schedule runs at a time. Predictable, independent of anything else, and blind to whether there is work to do.
A webhook is the source system telling you something happened. Prompt, efficient, and dependent on somebody else's delivery.
Polling is asking repeatedly whether anything changed. Reliable, wasteful, and delayed by the interval.
Manual is a person starting it, which is underrated and appropriate more often than automation enthusiasm suggests.
Most real automations combine them: a webhook for promptness, with a scheduled reconciliation to catch what the webhook missed. That pairing is the single most useful pattern here.
Schedules
Use them for work that should happen regardless — reports, reconciliations, cleanups, checks.
Beware the interval that encodes a dependency. A job scheduled thirty minutes after another because that is usually long enough will be wrong on a slow day, and the downstream job will process stale data and succeed.
Consider the timezone, explicitly, including what happens at a daylight saving transition — where an hour repeats or vanishes and a job runs twice or not at all.
Avoid the top of the hour. Every system in the world schedules there, which means contention at the sources you call.
Spread the estate. Forty automations at nine o'clock is a self-inflicted load spike against your own rate limits.
Alert on not running, because a schedule that silently stops produces nothing, and nothing looks exactly like a period with no work.
Webhooks
They are the efficient option — no wasted calls, and near-immediate reaction.
Delivery is at-least-once, so duplicates are normal and the handler must be idempotent.
Ordering is not guaranteed. A later event can arrive before an earlier one, which breaks anything that assumes a sequence.
They are lost when your endpoint is down. Most senders retry for a limited period and then give up, so an outage longer than that window means permanently missing events.
Verify the signature, since the endpoint is public and will receive things you did not expect.
Respond quickly and process afterwards. A slow endpoint causes timeouts and retries, which multiplies the duplicates you then have to handle.
Always pair with a reconciliation. A scheduled comparison catching what the webhook missed is not optional in any system where missing an event matters.
Polling
Use it when there is no webhook, which is common, or when you need a guarantee the webhook cannot give.
Use a cursor, not a full scan — a modified-since filter with a stored high-water mark — or the cost grows with the data.
Store the cursor after success, not before, so a failure mid-run does not skip records permanently.
Overlap the window slightly, because records can be assigned a timestamp before their transaction commits and a strict cursor misses them.
It cannot see deletions. A deleted record simply stops appearing, which is the characteristic gap and needs a periodic full comparison to close.
Choose the interval by what a delay costs, not by what feels responsive. Most work tolerates fifteen minutes, and a one-minute interval is usually fifteen times the calls for no benefit anybody notices.
Manual and conditional triggers
Manual triggers are legitimate. A person pressing a button when they judge it appropriate is the right design for anything requiring judgement about timing.
They are also a good starting point. Run it manually for a fortnight, see what goes wrong, then automate the trigger.
Conditional triggers fire when a condition becomes true, which is usually implemented as polling underneath and inherits polling's properties.
A trigger on a change to a field needs to define what counts as a change — any edit, or a transition to a specific value. The second is almost always what people mean and the first is usually what gets configured.
Chained triggers, where one automation starts another, are convenient and make failure hard to trace. Prefer one automation with several steps where you can.
Choosing by what failure costs
The decision framework, and it is short.
If a missed trigger is unacceptable, use polling or pair a webhook with reconciliation. Webhooks alone are not sufficient.
If a duplicate trigger is harmful, make the handler idempotent first and worry about the trigger type second — you cannot prevent duplicates, only tolerate them.
If promptness matters in minutes, use a webhook.
If promptness does not matter, use a schedule and accept the latency, which is simpler and easier to reason about.
If nothing bad happens when it is late, run it less often. The instinct towards frequency is rarely examined and frequently costly.
Write down which failure you accepted, because somebody will later ask why the automation missed something, and the answer should be a decision rather than an oversight.
The trigger that never fires
The failure mode common to all four, and the one nobody builds for.
A schedule that stopped, a webhook that was deregistered, a poll whose credentials expired — all produce silence.
Silence is indistinguishable from no work. This is the entire problem.
Alert on absence. Each automation should run within an expected window, and not running is the condition worth reporting.
Report at the estate level, weekly: what ran, what did not, what has not run in a month.
Include a heartbeat for anything important, so the automation reports "nothing to do" rather than saying nothing at all.
Check webhook registrations periodically, since they are removed by third-party systems more often than anybody expects — by an integration being reauthorised, a permission change, or a tidy-up.
When the trigger arrives faster than you can work
A situation every successful automation eventually meets, and the trigger choice determines how badly.
Overlapping runs. A schedule firing every five minutes for a job that now takes seven means two copies running, both processing the same records.
Decide whether overlap is allowed, explicitly. Most automations should skip a run rather than start a second copy, and most platforms let you say so.
Webhooks arriving faster than processing means a growing backlog, and a backlog is only visible if something is watching the lag rather than the throughput.
Batch where the work allows. Processing fifty records in one run is dramatically cheaper than fifty runs, both in overhead and against rate limits.
Debounce bursty sources. A system emitting five events for one logical change is common, and collapsing them within a short window removes most of the volume.
Watch the oldest unprocessed item, not the count. Depth without age cannot distinguish a busy healthy system from one falling behind.
Setting triggers up with CodeWords
CodeWords connects to more than 3,000 integrations, and the trigger, the retry behaviour, and the handling of duplicates are part of describing the automation rather than infrastructure to configure.
- Open CodeWords and start a new automation.
- Describe what should happen in plain language to Cody, the automation builder, including what should start it.
- Describe the exceptions: a duplicate trigger, a missed event, a source that is unavailable.
- Connect the systems involved once and reuse the connections.
You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.
What to get right first
Idempotent handling, before choosing the trigger type. Every kind of trigger can fire twice — webhook retries, a schedule overlapping a slow run, a poll re-reading a record — so tolerating duplicates is a precondition rather than a refinement, and it makes the trigger choice a matter of latency rather than correctness.
Two habits make the difference. Pair every webhook with a scheduled reconciliation, since webhooks are lost during an outage and nothing tells you which ones. And alert on an automation not running, because silence is the failure mode all four trigger types share and none of them reports it.
Frequently asked questions
Webhook or polling?
A webhook for promptness, paired with a scheduled reconciliation to catch what it missed. Polling alone when there is no webhook, or when missing an event is unacceptable and you want the guarantee rather than the speed.
Can I prevent duplicate triggers?
No. Webhook retries, overlapping scheduled runs, and re-read records all produce them. Make the handler idempotent instead — it is a precondition for any trigger type rather than something specific to one.
Why did my automation miss an event?
If it is webhook-driven, most likely your endpoint was unavailable and the sender retried for a limited period before giving up. This is why a scheduled reconciliation is not optional wherever missing an event matters.
How often should a poll run?
By what a delay costs, not by what feels responsive. Most work tolerates fifteen minutes comfortably, and a one-minute interval is usually fifteen times the calls for a difference nobody notices.
Why does a polled automation miss deletions?
Because a deleted record simply stops appearing — there is no event and nothing in a modified-since query indicates it existed. Only a periodic full comparison of identifiers closes that gap.
What is the most overlooked failure?
The trigger that never fires. A stopped schedule, a deregistered webhook, or expired credentials all produce silence, and silence looks exactly like a quiet period. Alert on absence rather than on failure.
Are manual triggers a failure of automation?
No. A person deciding when something should run is the right design wherever timing requires judgement, and running manually for a fortnight before automating the trigger is a good way to find out what actually goes wrong.
What happens when a scheduled job takes longer than its interval?
Two copies run simultaneously, processing the same records, unless you say otherwise. Decide explicitly whether overlap is allowed — most automations should skip the run rather than start a second copy.
How do I tell whether an automation is falling behind?
Watch the age of the oldest unprocessed item rather than the count. A large backlog that drains quickly is fine; a small one holding items from four hours ago is not, and only the age distinguishes them.
Why did a webhook stop arriving with no changes on our side?
Registrations get removed by the third party more often than people expect — by a reauthorisation, a permission change, or a tidy-up. Check that your registrations still exist on a schedule rather than assuming they persist.