Question 1

What trigger types exist in n8n and how do you choose between them?

Accepted Answer

Do not open with a list — open with the selection criterion, then give examples. "I reduce it to one question: who announces the event? Nobody, the time has simply come — Schedule Trigger An external system announces it — a Webhook or the service's own trigger node A person starts it — Manual Trigger or Form Trigger Another workflow calls it — Execute Sub-workflow Trigger The real decision underneath is polling versus push. Push always wins: it is faster and wastes no requests. I only fall back to polling when the service has no webhook support — and then I always store a cursor of the last processed record, because otherwise one failed run means lost data."

Question 2

What do you do to make a polling-based workflow reliable?

Accepted Answer

This question checks whether you have thought about data loss. "I watch three things. First, the cursor. I do not write "the last hour" style queries — I store the ID or timestamp of the last processed record (in a Data Table, a sheet or a database) and resume from it. Then even if the workflow is down for two hours, it picks up everything left over when it comes back. Second, idempotency. What happens if the same record arrives twice? I make the write an upsert where I can, or check processed IDs — because retries and re-runs are normal. Third, the interval. Polling too often burns the API rate limit; polling too rarely adds latency. I derive it from what the process actually needs — and the interval must never be shorter than the run time, or executions overlap."

Question 3

How would you explain the difference between webhooks and polling to a non-technical manager?

Accepted Answer

This measures communication. Use an analogy, then tie it to the business. "Polling is like walking to the mailbox every five minutes. You go whether or not there is post. A webhook is the postman ringing the bell — you are told when something arrives. There are two business-side differences. First, speed: with a webhook the reaction is in seconds; with polling you wait, on average, half the interval. Second, cost: polling generates empty requests, and some services charge per request. In exchange, a webhook has a condition: our system must be reachable from outside, and if a message is lost the service may not resend it. So for critical processes we run a once-a-day 'what did we miss?' reconciliation alongside the webhook."

Trigger	When it fires	Typical use
Manual Trigger	When you press "Execute workflow"	Building and testing; one-off data migrations
Schedule Trigger	On an interval or cron expression	Daily reports, hourly syncs, monitoring
Webhook	When an HTTP request hits the URL it exposes	Receiving events from systems with no dedicated trigger node; using n8n as an API
App trigger (Gmail, Telegram, ...)	When an event happens in the service	A new email, a new message, a new row
n8n Form Trigger	When a form n8n hosts is submitted	Internal requests and simple intake forms — no separate site needed
Execute Sub-workflow Trigger	When another workflow calls it	A reusable module; a tool for an AI agent
Error Trigger	When a workflow it is attached to fails	Centralised failure alerting

Trigger types: which one to choose when

📚 Sources and documentation