Triggers and Webhooks in n8n: How a Workflow Starts

A trigger answers the question “when should this workflow run”. It is always first and always singular: a workflow cannot begin at two entry points.

Trigger types

Webhook - n8n gives you a public URL and an execution starts when a request arrives there. This is the main way to react to outside events: payments, forms, API callbacks.

Schedule - runs on an interval or a cron expression. For reports, syncs and periodic checks.

Service triggers - ready-made blocks for specific systems: a new email, a new spreadsheet row, a chat message. Under the hood each is either a webhook or periodic polling - and the difference matters: polling learns about an event on the next check, not instantly.

Manual - the button in the editor. For debugging, not for production.

Test versus production URL - the main confusion

The webhook node has two different addresses, and most “why doesn’t it work” questions grow from that.

The test URL lives only while you have pressed listen in the editor. It waits for one request, shows you what arrived, then goes quiet. It is a debugging tool: a convenient way to see once what a service actually sends.

The production URL works continuously, but only on an activated workflow. Not activated, and the address returns an error.

The practical consequence: an integration wired to the test URL stops working the moment you close the editor. Moving to production means changing the address on the calling side, not just flipping the toggle.

Why the webhook never arrives

A checking order that closes nearly every case:

1. Is the workflow active? The most common cause.
2. Is it the right URL? Test instead of production is second.
3. Does n8n know its public address? Without WEBHOOK_URL the UI shows localhost - see installation.
4. Is there HTTPS? Many services refuse to send webhooks over http.
5. Do the methods match? The node expects POST while the service sends GET, and the request finds no handler.
6. Is the proxy cutting it? An aggressive timeout or body-size limit on the reverse proxy severs the request before n8n sees it.

If you are unsure whether n8n or the sender is at fault, hit the address with plain curl. The answer eliminates half the hypotheses immediately.

Responding to the caller

By default a webhook responds immediately without waiting for the workflow to finish. That is correct most of the time: the sender gets its acknowledgement and does not hang.

Sometimes you need to return the result - when you are building an API endpoint, for instance. Then the response mode switches to returning data from a chosen node, and a limitation appears that is worth remembering: the caller waits. If the workflow takes thirty seconds, the sender holds the connection for thirty seconds, and its own timeout may fire before your answer does.

The working rule: if processing is slow, answer “accepted” straight away and deliver the result separately - a callback, a message, a database write.

Schedules and timezones

A schedule is set by interval or cron expression. The trap is not the syntax but the timezone: n8n defaults to UTC, so “every day at 9:00” means 9am UTC, not yours. Set the timezone at install time - one variable that spares you a recurring puzzle.

The second detail: frequent schedules can overlap. If it runs every minute and the work takes two, you get parallel copies competing for the same data. Either leave headroom in the interval, or make the workflow safe to run concurrently.

Securing a public endpoint

A webhook is a public address on the internet. It will be found - scanners walk paths constantly.

The minimum set of measures:

• A secret in the request - a header or token you check in the very first node, ending the execution when it does not match.
• Signature verification, when the service provides it. Payment providers and GitHub do this, and it beats a token because it also proves the payload.
• Do nothing before validation. The check belongs ahead of any action that touches the outside world.

And separately: do not treat “a long random path” as security. It is not a secret, it is just an address; it leaks into logs, browser history and the settings of whatever service calls it.