n8n Workflow Not Triggering? The Checklist I Run

If an n8n workflow won't fire, it's almost never a bug in n8n. It's one of a small set of setup issues. Two questions catch most of them: is the workflow Active, and are you calling the Production URL rather than the Test URL? Confirm both and you've solved the majority of cases in under a minute. Everything below is the rest of the order I go in when those two don't do it.

I debug other people's n8n setups often enough to have a fixed routine, and I run it top to bottom regardless of how the workflow looks. The goal is to answer one question fast: did the trigger fire at all? Once you know that, you're either chasing a trigger problem or a logic problem, and those live in completely different places.

Quick answer

• Never fires, no execution logged. The trigger didn't run. Check Active, then the URL, method, and credentials.
• Fires but errors out. The trigger is fine. A downstream node is failing, and the Executions log names it.
• Worked yesterday, silent today. Almost always a swapped-in Test URL or an expired credential.
• Works locally, dead from the internet. A reverse proxy or a missing WEBHOOK_URL on self-hosted.
• Runs manually, never on schedule. Not Active, or a timezone or cron expression you didn't mean.

The fast triage checklist

Work down this list and stop the moment it fires. Order matters: the cheap checks are first.

1. The workflow is toggled Active (top-right).
2. The caller uses the Production webhook URL, not the Test URL.
3. The HTTP method matches (a POST caller hitting a GET webhook fails).
4. Any required auth header is present and correct.
5. The trigger event actually happened in the source system.
6. No trigger filter or condition is silently excluding your event.
7. The trigger node's credentials are valid and not expired.
8. For schedules, the timezone and expression are what you think they are.
9. On self-hosted, the process and workers are actually running.
10. The Executions tab confirms whether it fired at all.

Match your symptom to the first thing to check

If you only have thirty seconds, find your row.

Why is the workflow not Active?

This is the most common cause by a wide margin, so it's worth its own beat. A Webhook node only listens on its Production URL while the workflow is Active, and a Schedule trigger only runs while it's Active. If the toggle is off, the endpoint returns a 404 and the cron never fires. Flip it on and try again.

One trap: editing a workflow does not always re-register its webhook. If you changed the path, the method, or the auth on a Webhook node, toggle the workflow off and back on so n8n re-registers the endpoint. I've watched people test against a path that no longer exists because the old registration was still cached.

Test URL versus Production URL

Every n8n webhook has two URLs and they behave differently. The Test URL listens only while the editor is open and you've clicked Listen for test event, so it's built for development. The Production URL listens whenever the workflow is Active. If you pasted the Test URL into GoHighLevel, a form, or another app, it worked during setup and then went silent the moment you closed the tab.

The two paths differ by one segment: /webhook-test/ for the Test URL and /webhook/ for Production. Swap that in and most "it worked in the demo" problems disappear. This exact mistake has its own section in my GoHighLevel and n8n integration guide because GoHighLevel outbound webhooks are where I see it most.

Test a production webhook with curl

When a real integration says it's sending but n8n shows nothing, take the integration out of the picture and call the endpoint yourself. curl tells you the truth in one line.

curl -i -X POST \
  https://n8n.yourdomain.com/webhook/lead-intake \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -d '{"event":"test","email":"you@example.com"}'

Read the status line at the top of the response:

• 200 and an execution shows up: the webhook is healthy, so the problem is in whatever was supposed to call it.
• 404: the workflow is inactive or the path is wrong.
• 405: method mismatch. Your Webhook node expects a different verb than you sent. Match the node's HTTP Method setting.
• 403 or 401: the node has Authentication turned on and your header is missing or wrong. Either send the right credential or, if you meant it to be open, set Authentication to None on the node.

Why does my scheduled workflow never run?

A Schedule (Cron) trigger fails quietly in two ways, and both look identical from the outside: nothing happens at the time you expected.

The first is that the workflow is not Active. A manual Execute Workflow bypasses the schedule entirely, which is exactly why manual runs succeed while the scheduled ones don't. Activate it.

The second is timezone. n8n evaluates the schedule in its configured timezone, not yours and not the caller's. If you set 0 9 * * 1-5 expecting 9am weekdays and the server runs in UTC, it fires at what feels like the wrong hour. On self-hosted, set GENERIC_TIMEZONE and confirm it:

export GENERIC_TIMEZONE=America/New_York
export TZ=America/New_York

Then sanity-check the expression itself. A cron like 0 0 * * * is midnight daily, not hourly. If you meant every hour, that's 0 * * * *. When in doubt, switch the Schedule node to the plain interval mode ("every X hours") while you confirm it fires, then move back to cron once you trust it.

Polling and app triggers fire on their own clock

Triggers like Gmail, Google Sheets, Airtable, or an RSS feed don't get pushed events. They poll on an interval, so "it didn't fire immediately" is often just the interval doing its job. Check the node's polling setting before assuming it's broken, and remember that a very short interval on a busy account can hit provider rate limits and skip cycles.

Polling triggers also stop dead when their credentials expire or a token is revoked. This is the classic "worked for three weeks, then nothing" pattern. Re-authenticate the credential and run it again. If it only works right after you re-auth and dies overnight, the OAuth refresh token is being rejected upstream, which is a provider-side consent or scope problem, not an n8n one.

"Never fires" versus "active but silently failing"

These feel the same and are completely different problems. A workflow can be Active, receive the event, start an execution, and then die on the second node without you ever knowing. That is not a trigger problem. The tell is whether an execution exists at all.

An IF or Filter node right after the trigger, or a condition on the trigger itself, can also discard the exact event you're testing. From the outside that looks like the trigger ignoring you. The Executions tab settles it: if you see a run that stopped early, a filter dropped the event, and the trigger is doing its job.

Let the Executions tab decide, and turn on saving

The Executions list is the fork in the road, so make sure it's actually recording what you need. By default n8n may not save successful production executions, which leaves you blind on the exact runs you want to inspect. Turn on saving in the workflow's Settings:

• Save successful production executions: On, at least while debugging.
• Save failed production executions: On, always.
• Save manual executions: On.

Once saving is on, the log answers the only question that matters:

• No execution at all means the trigger never fired. Your fix is up in steps 1 through 9.
• An execution that errored means the trigger works and a downstream node is the problem. The log highlights the exact node with its input and output.

Knowing which side of that line you're on saves an hour of looking in the wrong place.

Self-hosted: is anything actually running?

On n8n Cloud the platform keeps the process alive. On self-hosted it's on you, and a dead process shows up as every webhook returning 404 and every schedule missing. Confirm the container or service is up:

docker ps --filter "name=n8n"
docker logs n8n --tail 50

If you run queue mode, this gets sharper. In queue mode the main instance registers webhooks and hands execution to worker processes over Redis. If your workers aren't running, webhooks can still return 200 while nothing ever executes, because the job is queued and never picked up. Check that at least one worker is alive and connected to the same Redis, and watch the worker logs while you fire a test event. A main instance with zero healthy workers is the single most confusing self-hosted failure I get called in for, precisely because the webhook looks fine.

Webhooks behind a reverse proxy need WEBHOOK_URL

If n8n sits behind Nginx, Caddy, Traefik, or a Cloudflare tunnel, it can build its webhook URLs from the internal host it sees rather than your public domain. The endpoint then works when you call it locally and 404s from the internet, or the URL shown in the editor points somewhere the outside world can't reach.

The fix is to tell n8n its real public address explicitly:

export WEBHOOK_URL=https://n8n.yourdomain.com/
export N8N_HOST=n8n.yourdomain.com
export N8N_PROTOCOL=https
export N8N_PORT=443

Restart after setting these so webhooks re-register against the correct base, then copy a fresh Production URL from the editor. Also make sure the proxy forwards the full path and doesn't strip a prefix, and that it passes X-Forwarded-Proto so n8n knows the request came in over HTTPS.

Build it so it can't fail quietly

Every fix above is reactive. The better move is to make silent failure impossible in the first place, and n8n gives you the hook for it: the Error Trigger node.

Create one small workflow that starts with an Error Trigger and ends in a Slack or Telegram message. Then open each real workflow's Settings and set its Error Workflow to that one. Now any failed run pings you with the workflow name and the failing node instead of vanishing. Here's the shape of a Telegram alert payload from that error workflow:

{
  "chat_id": "YOUR_CHAT_ID",
  "text": "n8n failure in \"{{$json.workflow.name}}\" at node \"{{$json.execution.lastNodeExecuted}}\": {{$json.execution.error.message}}"
}

Wiring in alerting like this is exactly why a workflow can run untouched for months. When I built hands-free TikTok Shop order processing, the point wasn't just connecting the APIs, it was making sure a bad order pinged a human instead of silently stalling fulfillment.

If you've been through the whole checklist and it still won't fire, or you'd rather not maintain this yourself, that reliability work is the core of the n8n automation I build for clients: triggers that fire, error handling that alerts, and integrations that hold up when a token expires at 2am.