Why Is My n8n Workflow Not Triggering?

Start by separating "not triggered" from "triggered and failed"

These look identical from the outside but are different problems. A workflow that never receives an event is an ingress problem. A workflow that receives the event and then errors is an execution problem.

• Open the workflow's execution history. Is there an execution at the expected time?
• If yes, the trigger worked. Diagnose the first failed or unexpected node.
• If no, stay focused on the trigger path. Do not troubleshoot downstream nodes yet.

The seven checks that solve most trigger failures

1. Confirm the workflow is active.
   Webhook production URLs and many trigger nodes depend on an activated workflow. A workflow can behave correctly in the editor while its production listener is not active.
2. Confirm the caller is using the production URL.
   n8n exposes separate test and production webhook URLs. The test URL is intended for development and listening sessions. Your external service should be configured with the production URL when the workflow is active.
3. Confirm the public URL is actually public.
   From a device or network outside your server, verify that the hostname resolves and HTTPS reaches the n8n endpoint. If n8n sits behind Cloudflare, Nginx, Traefik, a tunnel, or another reverse proxy, the browser reaching the editor does not automatically prove webhook routing is correct.
4. Check the generated webhook URL.
   Self-hosted n8n behind a reverse proxy may need an explicit public webhook URL so n8n generates external URLs using the correct scheme and hostname. A common symptom is n8n showing an internal hostname, HTTP instead of HTTPS, or the wrong port.
5. Check method, path, and authentication.
   A POST sent to a GET webhook, a changed path, a stale secret, or basic/header authentication mismatch can make the workflow appear dead even when the endpoint is reachable.
6. Check whether the external service actually sent the event.
   Inspect its delivery log, webhook history, API response, or test-event screen. This is often faster than staring at n8n. You need evidence of an outbound request and the HTTP status n8n returned.
7. Check infrastructure logs only after the application-level checks.
   If there is no execution and the sender shows delivery failures, inspect reverse-proxy, tunnel, firewall, DNS, TLS, and container logs. Work from the outside inward.

If test webhooks work but production webhooks do not

This is one of the highest-value clues. It means the workflow logic is probably not your first problem. Test mode temporarily registers a listener while you are developing. Production depends on the activated workflow and the stable production endpoint.

For self-hosted n8n, inspect the URL n8n thinks it owns

If the editor is reachable at a public HTTPS address but n8n displays webhook URLs with an internal host, localhost, a container port, or HTTP, fix the public URL configuration rather than hard-coding every integration around the symptom. The exact configuration depends on how you host and proxy n8n.

Schedule trigger not firing?

For scheduled workflows, the equivalent questions are different:

• Is the workflow active?
• Is the timezone what you think it is?
• Was the schedule changed but not reactivated?
• Is the instance running continuously at the scheduled time?
• Did an execution occur but fail immediately afterward?

In containerized or low-cost hosting, also verify the host is not sleeping, restarting, being recreated without persistence, or losing time-sensitive configuration.

Build observability before you trust the workflow

A production workflow should not require a person to periodically open n8n and wonder whether it ran. At minimum, decide how you will know about:

• trigger failures or missing expected events;
• node errors;
• authentication expiration;
• API rate limits and timeouts;
• partial completion, where an early step succeeded but a later action failed;
• repeated retries that create duplicate downstream actions.

n8n supports error workflows and node-level retry behavior. Those are useful building blocks, but the business control still has to be designed: who is notified, what they can safely retry, what state must be checked first, and when automation should stop.

When to stop troubleshooting node by node

If fixing the webhook immediately exposes an OAuth problem, then a schema problem, then duplicate handling, then an unmonitored failure path, you are no longer dealing with a single broken node. You are dealing with a system that reached the edge of its prototype architecture.

That is usually the right moment to map the whole path: event source → authentication → n8n ingress → workflow logic → AI/API calls → downstream actions → confirmation → monitoring.