Webhook, Poll or Schedule? How Automations Actually Get Started
Every workflow starts with a trigger, and that choice affects speed, running cost and reliability more than anything else you'll build. Here's how to pick.
Every workflow you’ll ever build has one thing at the top: a trigger. It’s the part people spend the least time on and the part that causes the most problems six months later. There are really only four kinds, and knowing which to use is most of the skill.
Get this right and the workflow is fast, cheap to run and quietly reliable. Get it wrong and you’ll be paying for 43,000 empty executions a month, or wondering why the same order was processed twice, or explaining to a client why their notification arrived forty minutes late.
1. Webhooks — the app tells you
A webhook is the source app pushing data to you the moment something happens. You give it a URL, and when a new order comes in, it sends the order data to that URL. Your workflow wakes up and runs.
Use it when: you need speed, and the source app supports it. Payment received, form submitted, deal moved to “won”, new signup.
What it costs you: almost nothing. No wasted runs, no delay.
The catch: if your endpoint is down or throws an error, the event is gone. Most services retry a few times, but not all do, and not forever. So a webhook workflow should do two things immediately — save the raw payload somewhere, and return a success response fast. Do the actual processing after that, in a separate step or workflow. If you spend 30 seconds calling three APIs before responding, the sender may time out and retry, and now you’ve processed the same order twice.
The receive-then-process pattern
This is worth stating as a rule, because it prevents a whole class of problems. Split every webhook into two workflows:
- The receiver. Verify the signature, write the raw payload to a store (a database table, a queue, even a spreadsheet), respond
200. Nothing else. This should complete in well under a second. - The processor. Picks up unprocessed rows and does the real work — calling APIs, transforming data, sending mail.
The payoff is large. A slow third-party API can no longer cause duplicate deliveries. If the processor has a bug, the raw events are still sitting there and you can replay them after the fix instead of asking the client to re-send yesterday’s orders. And when something looks wrong, you can see exactly what arrived, rather than what your workflow thinks arrived.
A webhook URL is a public door
Anyone who learns the URL can post anything to it. Treat it accordingly:
- Verify the signature. Most serious providers (Stripe, Shopify, GitHub) sign each request with a shared secret. Compute the hash and compare before you trust a single field. This is usually five minutes of work and it is the difference between a webhook and an open API for forged orders.
- Don’t rely on the URL being secret. Random URLs leak — into logs, browser history, screenshots, support tickets.
- Validate the payload shape before using it, and never pass raw webhook values into a database query or a shell command.
- Rotate the secret if anyone who had access to it leaves.
2. Polling — you ask the app
Polling means your workflow asks “is there anything new?” on a fixed interval. Every 5 minutes, check the inbox. Every 15 minutes, query the database.
Use it when: the source has no webhooks — which is most older systems, most databases, RSS feeds, and a surprising number of SaaS tools.
What it costs you: runs. A workflow polling every minute fires 43,200 times a month whether or not anything happened. On most platforms you pay per execution, so this adds up quickly for nothing.
The arithmetic is worth doing before you pick an interval, because the difference is not small:
| Interval | Runs per month | Typical worst-case delay |
|---|---|---|
| Every 1 minute | ~43,200 | 1 min |
| Every 5 minutes | ~8,640 | 5 min |
| Every 15 minutes | ~2,880 | 15 min |
| Hourly | ~720 | 60 min |
Going from 5 minutes to 1 multiplies your run count by five. Ask what the business actually loses in those four minutes. “Real time” usually means “before the customer notices,” and five minutes is almost always fine.
The catch: duplicates. Polling has no memory unless you give it one. You need to store the last thing you processed — an ID, an updated-at timestamp, a cursor — and start from there next time. Without that, a workflow that pulls “the last 10 records” will process the same records over and over.
Two traps with cursors, both of which I have watched bite people. If you filter on updated_at > last_run, use the source system’s clock, not your own — a few seconds of drift silently skips records. And prefer >= with a de-duplication check over >: processing one record twice is recoverable if your workflow is idempotent, whereas skipping one is invisible and permanent.
3. Schedule — the clock tells you
Time-based, not event-based. Nothing needs to happen for it to run.
Use it when: the work is periodic by nature. The Monday morning report. The nightly sync. The weekly cleanup of stale records. The monthly invoice batch.
The catch: timezones and empty runs. Set the schedule in a timezone you’ve actually thought about, especially if your team and your clients aren’t in the same one — and remember that daylight saving will shift a “9am” job by an hour twice a year unless the platform handles it properly. If a job genuinely must run at a fixed real-world moment, store and schedule it in UTC and do the conversion deliberately.
And build in an early exit — if there’s nothing to report, don’t send an empty email every Monday. People stop reading those, and then they stop reading the ones that matter.
One more scheduling habit worth having: don’t start every job on the hour. If six workflows all fire at 09:00 and all hit the same API, you’ll trip a rate limit that none of them would have hit alone. Stagger them by a few minutes.
4. Manual and form triggers — a person tells you
A button, an internal form, a Slack command. Underrated, and the right answer more often than people expect.
Use it when: a human decision has to happen anyway. Approving a refund, kicking off onboarding for a new client, generating a proposal. The automation still saves the 20 minutes of assembly work — you’ve just kept the judgement where it belongs.
This is also the safest way to launch something risky. Run a new workflow manually for a fortnight, watch what it produces, and only then swap the trigger for a webhook. The logic is identical; you’ve just kept a person between the automation and the customer while you build confidence in it.
The pattern most people miss: webhook plus a safety net
These four options get presented as a choice. For anything that genuinely matters — payments, orders, signed contracts — the right answer is often two triggers on the same job.
Run the webhook for speed, and add a scheduled reconciliation sweep that runs a few times a day and asks the source system: “give me everything from the last 24 hours.” Anything that has no matching record on your side gets processed. If your workflow is idempotent — and it should be — records that already went through are simply skipped.
This costs a handful of extra executions a day and eliminates the single worst failure mode in event-driven automation: the silently dropped event. Webhooks fail for boring reasons — your server was restarting, the provider had an incident, someone deployed at the wrong moment — and without a sweep, nobody finds out until a customer complains about an order that never shipped.
Picking, in one line each
- The app supports webhooks and speed matters → webhook
- No webhooks available → polling, with a stored cursor, at the slowest interval you can live with
- The work is periodic, not event-driven → schedule
- A human has to decide first → manual trigger
- Money or legal obligations are involved → webhook + a scheduled reconciliation sweep
One thing that saves a lot of pain
Whichever you pick, log the trigger. One row per run: when it fired, what came in, what happened. When something goes wrong in three months — and it will — the first question is always “did it even fire?” Without a log, you’ll spend an hour guessing. With one, you’ll know in ten seconds.
Keep it cheap and keep it separate from the workflow’s own execution history, which most platforms prune after a few weeks. A dated row in a spreadsheet or a small database table is enough, and it survives long enough to answer the question “has this been broken since the last update?”
Triggers are the first half of a reliable workflow. The second half is what happens when a step fails at 2am — retries, duplicate protection and alerting are covered in why your automation broke at 2 AM. And if you’re still deciding which process to automate at all, start with the five-day audit.
If you’d rather have this built and maintained for you, that’s what n8n workflow automation covers — or book a free intro call and tell me what you’re trying to connect.
