Cron vs Webhook: Pick the Trigger That Matches the Failure Mode

Pick the trigger by how you will notice it dying — not by which demo looks faster. Webhooks win when the source can push and you can detect a dead subscription. Schedules win when freshness can wait and you need a heartbeat you control. Many production paths need both: a webhook for speed and a reconciliation cron that catches what the push missed.

This sits under the Production n8n handbook. Trigger choice is reliability design, not a preference for “real-time” branding.

The short answer

• Webhook when the vendor supports push, latency matters, and you monitor subscription health.
• Schedule / cron / polling when the API is pull-only, batch is fine, or you want a run you can prove happened.
• Both fail silently in different ways — design detection for the mode you chose.
• Hybrid is normal: webhook for the hot path, daily or hourly cron to reconcile gaps.
• Zapier polling intervals are plan-dependent — do not quote a single number for every account.

Decision table

Signal	Prefer webhook	Prefer schedule / poll
Latency need	Seconds to a few minutes	Tens of minutes to daily is fine
Vendor capability	Documented webhook / event API	List/search API only
Volume shape	Spiky, event-driven	Steady batch windows
Idempotency maturity	Required (retries duplicate)	Still required (overlap windows)
Silence detection	Dead subscription / no traffic	Missed cron / empty success
Cost shape	Execution per event	Polls may burn tasks even when nothing changed (tool-dependent)

If two rows conflict, ship webhook for intake and add a reconciliation schedule before you declare “done.”

When real-time is actually required

Real-time is required when delay creates irreversible cost:

1. Lead routing while a human is on the phone
2. Fraud / access revoke
3. Inventory or booking hold
4. Payment confirmation that unlocks fulfillment

“We like seeing it appear instantly in Slack” is not a reliability requirement. For that, a five-minute schedule is often enough and easier to reason about.

If the vendor offers only polling on Zapier or Make, buying a tighter poll interval is not the same as a true push. You are still sampling. Plan for gaps.

When polling wastes money and still misses events

Polling costs show up as:

• Zapier tasks (or Make operations) when each poll run performs billable work — exact billing rules are product-specific; check your plan docs
• n8n executions every schedule tick even when the query returns nothing (depending how you build the flow)
• API rate-limit budget burned on “anything new?” loops

Miss modes polling still has:

• Item created and deleted between polls
• Pagination bugs that skip page two forever
• Clock skew / “updated after” filters that skip edits
• Plan interval too coarse for the SLA you promised sales

Prefer webhooks when the vendor has them. Prefer schedules when the business accepts the cadence. Do not poll every minute “to be safe” without measuring cost and rate limits — see API rate limits in n8n when the rail is n8n.

Silent failure modes (the real comparison)

Trigger	Silent failure mode	What operators see	Detection
Webhook	Subscription deleted, URL rotated, vendor disabled events	Zero executions; dashboards look “fine”	Heartbeat: expect N events/day or synthetic ping
Webhook	Receiver up but auth/HMAC wrong	Vendor retries then gives up	Alert on 4xx rate at the edge
Schedule	Workflow deactivated or cron mis-set	Nothing runs; no error	Dead-man: alert if no success in 2× interval
Schedule	Runs green, query wrong	Empty success forever	Metric: items processed > 0 over window, or reconcile count
Poll (Zapier/Make)	Interval too slow / filter wrong	“Missing” records blamed on CRM	Dual-count source vs destination daily

Webhooks fail by absence of traffic. Schedules fail by absence of a run or by empty success. Those are different monitors. One Slack channel for “any error” catches neither.

For overnight posture and who gets woken, pair this with when automation fails overnight once that spoke is live — severity belongs next to silence detection.

Hybrid pattern: webhook plus reconciliation cron

This is the pattern we ship for lead and order paths:

1. Webhook workflow handles the event quickly; responds early; applies idempotency.
2. Reconciliation schedule (hourly or daily) lists source records updated since last watermark and upserts anything missing in the destination.
3. Diff report posts to ops when the cron creates or repairs rows — so you learn webhook gaps instead of ignoring them.
4. Shared schema validators so both paths reject the same bad shapes.

Layer	Owns
Webhook	Latency and happy-path volume
Cron	Completeness and catch-up
Idempotency key	Safe overlap when both fire
Heartbeat	Proof the webhook path is alive

Hybrid costs one extra workflow. It buys sleep.

What if the vendor has no webhooks?

Then you poll or schedule — honestly:

• Document the maximum acceptable lag with the business owner
• Set poll/schedule interval inside that lag (not “as fast as the plan allows”)
• Store a watermark (cursor, updated_at, or last id)
• Handle pagination explicitly
• Alert on zero-item success streaks that are abnormal for that source
• Add a daily full reconcile if the poll window can skip

Do not pretend a 15-minute poll is a webhook. Rename the SLA in the runbook.

How often should I poll?

Start from business lag, not from tool defaults:

1. Ask: “If this is late by X minutes, what breaks?”
2. Set interval ≤ X / 2 for safety margin when the API allows.
3. Cap interval by rate limits and billable poll cost.
4. Prefer fewer, richer batch jobs over chatty empty polls.

In n8n, Schedule Trigger plus a well-keyed query beats a webhook fantasy on a vendor that only lists records.

Zapier polling intervals and cost

Zapier’s own pricing docs describe polling time as plan-dependent (how often Zapier checks for new data on polling triggers). As of Zapier’s published plan table, free-tier polling is coarser than paid tiers, and higher plans advertise tighter intervals plus customized polling on paid seats. Treat any specific minute count as plan- and date-specific — verify on zapier.com/pricing for your workspace before you promise SLAs.

Cost angle operators miss:

• Instant (webhook) triggers avoid the poll cadence problem when the app supports them
• Polling Zaps can still consume tasks when actions run; empty polls are not “free complexity” even when task rules exclude some trigger checks — complexity and rate limits remain
• Upgrading a plan only for faster polls is sometimes rational; rebuilding on a push-capable rail is sometimes cheaper over a year

Make and n8n have different meters. Compare failure modes first, invoices second.

Detecting a dead webhook subscription

Checklist we use after go-live:

• Baseline: expected events/day (even a rough band)
• Alert if count = 0 for N hours during business window
• Synthetic event weekly in staging or a canary record in prod
• Log vendor delivery failures if the platform exposes them
• On credential or URL change, re-verify the subscription in the vendor UI
• Document who can re-create the webhook without guessing

A webhook that has been quiet for three days is not “stable.” It is unproven.

Can schedule triggers pile up in n8n?

Yes, under load or long-running executions. If a schedule fires while the previous run still holds work, you can overlap writes unless you:

• Set workflow concurrency / queue settings appropriate to your hosting mode
• Make the job idempotent
• Use a lock row or “run token” in your backend
• Prefer “skip if running” patterns where available

Overlapping crons that both “catch up” the same window are a classic duplicate-send source. Design for overlap; do not assume serial perfection.

When email / IMAP is a bad trigger

Email-as-trigger looks flexible and fails dirty:

Problem	Why it hurts
Parsing HTML/plain variants	One vendor footer change breaks extraction
Duplicate delivers / threading	Harder idempotency than an event id
Latency and mailbox auth	OAuth expiry looks like “no mail”
Security	Untrusted content in automation context

Use email triggers for low-risk notify paths. For money or CRM truth, prefer API webhooks or scheduled API pulls with a schema contract.

Trigger choice worksheet

1. Does the vendor document webhooks or events?
2. Max acceptable lag?
3. What does silence look like for this trigger?
4. Who gets the heartbeat alert?
5. Is reconciliation cron in scope for v1?
6. Idempotency key defined?

If (5) is “later” on a revenue path, you are accepting silent gaps.

FAQ

What if the vendor has no webhooks?

Use a schedule or poll with an explicit lag SLA, a watermark, pagination, and a reconcile job. Do not market it as real-time. Document the maximum delay the business accepted.

How often should I poll?

Set the interval from business lag and rate limits, not from the fastest plan toggle. Start coarser, measure missed-event rate, then tighten. Faster polls without watermarks just fail faster.

How do Zapier polling intervals affect cost?

Intervals are plan-dependent per Zapier’s pricing docs — verify your tier. Tighter polls can unlock faster detection but do not remove the need for reconciliation, and billable actions still meter when work runs. Instant triggers avoid poll cadence when the app supports them.

How do I detect a dead webhook subscription?

Alert on unexpected zero traffic, run a periodic synthetic event, and re-check the vendor subscription after any URL or credential change. Error workflows alone will not fire if no delivery attempt reaches you.

Can schedule triggers pile up in n8n?

Yes when a previous execution is still running. Use concurrency controls, idempotency, and locks so overlapping ticks cannot double-apply. Assume overlap will happen under load.

When is email/IMAP a bad trigger?

When the message body is your schema and the side effect is irreversible. Prefer API events or scheduled pulls for CRM and finance; keep mail for notifications and human-in-the-loop queues.

CTA

Choose the trigger you can prove is alive — then add the other as a safety net when money moves.

Read the handbook, then use automation or book a call.