n8n Workflow Not Running? Troubleshooting Common Automation Errors

You built an n8n workflow, clicked Execute workflow in the editor, and every node turned green. Then a real form submission arrives, or the scheduled time passes, and nothing happens. The Executions list is empty, or it shows a failure at a node that worked perfectly five minutes earlier. Sometimes the workflow runs, but it runs an older version of your logic, or it fires at 2 p.m. when you expected 9 a.m.

These symptoms usually trace back to a few causes: unpublished changes, the wrong webhook URL, a timezone mismatch, a failing credential, or an instance that can’t receive the request. This guide covers each in the order we’d check it, based on n8n’s current documentation.

Quick diagnostic checklist

• Is the workflow published, and does the Publish button show that there are no unpublished changes?
• Is the sending app using the production webhook URL (/webhook/), not the test URL (/webhook-test/)?
• Does the Executions tab for this workflow show any runs at all, including failed ones?
• Are failed and successful production executions set to be saved in the workflow settings?
• Is the workflow timezone (or the instance timezone) the one you intend for the Schedule Trigger?
• Do the credentials used by the failing node still connect when you open and test them?
• Self-hosted: does the webhook URL shown in the editor match your public domain, and are workers running if you use queue mode?

Common causes of an n8n workflow not running

1. The workflow, or your latest change, isn’t published

Current versions of n8n separate editing from production. Edits autosave as drafts, but production executions use only the published version. Publishing is what switches on production webhook and form URLs, schedules, and app event triggers. A workflow that was never published responds only to manual runs, and a published workflow with later edits keeps running the old logic until you publish again. The Publish button’s state shows whether there are pending changes or errors blocking a republish. Older self-hosted releases use an Active toggle instead, with the same effect.

2. The external app is calling the test webhook URL

The Webhook node has two URLs. The test URL only listens after you select Listen for test event (or run the workflow manually), and the incoming data appears on the canvas. The production URL registers when you publish the workflow, and its data does not appear on the canvas; you see it in the Executions list instead. Pasting the test URL into a form tool during setup works while the editor is listening, then silently stops. The HTTP method matters too: by default the node accepts one method, so a GET webhook won’t accept your form’s POST unless you change it or enable Allow Multiple HTTP Methods in the node settings.

3. The schedule runs in a different timezone, or hasn’t picked up your change

The Schedule Trigger uses the workflow’s Timezone setting, which falls back to the instance timezone. According to n8n’s workflow settings documentation, if neither is configured, n8n defaults to the New York timezone. The Schedule Trigger common-issues page also notes that interval changes and variables in the trigger are evaluated only when you publish, and the interval counts from the publish time. Changing “every 1 hour” to “every 2 hours” does nothing until you publish a new version, and the next run is two hours after that publish.

4. Credentials expired or lost their permissions

A workflow that ran for a week and then stopped often points to authentication. n8n’s Google credential documentation describes one specific case: for a Google Cloud OAuth app with Publishing status set to Testing and user type External, consent and tokens expire after seven days. Elsewhere, keys get revoked and scopes change. Look for 401 or 403 responses in the failing node’s output.

5. The trigger itself fails, so no normal execution is created

If a trigger node can’t start (say, it can’t register its webhook with the external service), there may be no execution to inspect. n8n’s error-handling documentation shows that an error workflow then receives a trigger object with a WorkflowActivationError instead of execution details. An empty Executions list is a strong hint to look here.

6. Pinned data hid a real problem during testing

n8n’s execution types documentation states that production executions ignore pinned data. If a node only worked against pinned sample data, the real payload, with different field names or nesting, can make it fail.

7. Self-hosted infrastructure problems

Behind a reverse proxy, n8n builds webhook URLs from its protocol, host, and port settings unless you tell it the public address. The reverse-proxy guide says to set the webhook URL manually, to set N8N_PROXY_HOPS to 1, and to forward the X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Proto headers. The variable is N8N_WEBHOOK_URL in current releases; the older WEBHOOK_URL is deprecated from n8n 2.35.0 but you’ll still see it in many setups. If the editor shows http://localhost:5678/webhook/..., external apps have an address they can’t reach. In queue mode, the main instance receives triggers but workers run executions through Redis, so executions pile up if no worker is healthy. Separately, production runs beyond a concurrency limit wait in a queue, which can make a busy workflow look stalled.

Step-by-step troubleshooting

1. Confirm the publish state. Open the workflow and look at the Publish button. If it says there are unpublished changes, the production run is using an older version. Publish, then retest with a real event, not the editor button.
2. Open the workflow’s Executions tab. If you see failed runs, open the latest and find the first red node; the error message there is more useful than anything downstream. If you see nothing, open the workflow settings and make sure Save failed production executions and Save successful production executions aren’t turned off. If they are, the workflow may be running without leaving a trace.
3. Test the production webhook directly. Copy the production URL from the Webhook node and send a request with a test payload using curl or the HTTP Request node, matching the node’s HTTP method. For example: curl -X POST https://your-n8n.example.com/webhook/lead-intake -H "Content-Type: application/json" -d '{"email":"test@example.com"}'. If this creates an execution but the real app doesn’t, the problem is the URL or method configured in the sending app.
4. Compare the URL in the sending app. Look for webhook-test, a wrong domain, localhost, or an old path from a duplicated workflow.
5. Check the schedule’s timezone. Compare actual start times in the Executions list with the Timezone in workflow settings. A consistent offset of several hours means a timezone mismatch. Publish again after any change.
6. Re-test the credential. Open the credential used by the failing node and reconnect or re-authorize it. For Google OAuth apps in Testing status, either reconnect regularly or move the app out of Testing where your organization’s policies allow it.
7. Replay with real data. Load the failed execution’s data into the editor (the “debug in editor” feature, which depends on your plan or edition; on the free self-hosted edition it requires registering the instance) and run the failing node against the real payload. Unpin any pinned data first so you see actual behavior. Use a test record or a copy of your destination sheet or CRM pipeline, not live customer records.
8. Self-hosted: check the environment. Confirm the webhook URL variable and proxy headers, read container logs for activation errors, and in queue mode confirm a worker is running.

Platform-specific guidance: node settings that change failure behavior

Every node has a Settings tab. Per n8n’s node documentation, Retry On Fail reruns a failed node, which suits temporary issues like rate limits. On Error offers Stop Workflow, Continue (moves on using the last valid data), and Continue (using error output), which sends error details down a separate branch. Use Continue with care: it can make a workflow “succeed” while quietly skipping records.

For alerting, create a workflow that starts with the Error Trigger node and select it under Error Workflow in each production workflow’s settings. It doesn’t need publishing, but it only runs when an automatic execution fails, so test it with a controlled failure in a published workflow.

Code example: validate required fields before they reach your CRM

Many “not running” reports are really “ran, then failed on bad input.” A Code node after the Webhook node can flag incomplete submissions before the CRM step. This uses the default Run Once for All Items mode:

// Required fields for a lead submission. Adjust to match your form.
const required = ['email', 'firstName', 'service'];
const emailPattern = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

return $input.all().map((item) => {
  // The Webhook node places the request payload under "body".
  const data = item.json.body ?? item.json;
  const errors = [];

  for (const field of required) {
    const value = data[field];
    if (value === undefined || value === null || String(value).trim() === '') {
      errors.push(`Missing field: ${field}`);
    }
  }

  if (data.email && !emailPattern.test(String(data.email).trim())) {
    errors.push('Email address format looks invalid');
  }

  return {
    json: {
      ...data,
      email: data.email ? String(data.email).trim().toLowerCase() : '',
      isValid: errors.length === 0,
      validationErrors: errors,
      receivedAt: new Date().toISOString(),
    },
  };
});

Follow it with an If node on isValid: valid items go to the CRM, invalid ones to a review sheet, or to a Stop And Error node if they should trigger your error workflow.

How to confirm the issue is fixed

• Trigger the workflow from the real source (live form, app event, or scheduled time), not the editor.
• Confirm a new execution appears with the expected status and that each node received the expected data.
• Check that the CRM contact, sheet row, or email actually exists with the right values.
• For schedules, watch at least two consecutive runs to confirm both the time and the interval.
• Deliberately cause one failure with a test record and confirm your error workflow sends an alert.

Common mistakes to avoid

• Testing only with Execute workflow and assuming production will behave the same. Manual runs use pinned data and don’t respect concurrency limits.
• Editing a published workflow and forgetting to publish again.
• Leaving two published copies of a duplicated workflow listening to the same event.
• Turning off saved executions and then having nothing to debug.
• Pasting API keys directly into Code or HTTP Request nodes instead of using n8n credentials.

Prevention and monitoring

• Attach one shared error workflow to every production workflow and send alerts where a person will see them.
• Describe each published version so you know what changed and can roll back quickly.
• Set the timezone explicitly on every scheduled workflow.
• Track which credentials each workflow depends on and when they need renewal.
• Self-hosted: monitor the container, database, and Redis, and keep enough execution history for troubleshooting.
• Review the Executions list weekly for new error patterns.

Related reading: CRM data not syncing between applications and our n8n vs Make vs Zapier comparison. When a workflow needs deeper changes than a settings fix, Modern Streamline offers n8n workflow development and troubleshooting.

FAQ

Why does my n8n workflow work when I click Execute but not automatically?

Manual runs use the current draft, can use pinned data, and listen on the test webhook URL. Automatic runs use only the published version, ignore pinned data, and listen on the production URL. Publish your latest changes and make sure the sending app uses the production URL.

Why does my Schedule Trigger run at the wrong time?

The workflow or instance timezone differs from yours; if neither is set, n8n uses the New York timezone. Set the timezone in workflow settings and publish again.

Why don’t I see any executions for my workflow?

Either the trigger never fired (unpublished workflow, wrong URL, trigger activation error) or saving production executions is turned off in the workflow settings. Check both before changing any logic.

Does my error workflow need to be published?

No. A workflow that starts with the Error Trigger doesn’t need publishing, but it only runs when an automatic execution fails, so you can’t test it with a manual run.

Sources

• n8n Docs: Save and publish workflows
• n8n Docs: Webhook node
• n8n Docs: Webhook node common issues
• n8n Docs: Schedule Trigger common issues
• n8n Docs: Configure workflow settings
• n8n Docs: Handle errors gracefully
• n8n Docs: Error Trigger node
• n8n Docs: Work with nodes (node settings)
• n8n Docs: Types of executions
• n8n Docs: Code node
• n8n Docs: Google OAuth2 single service credentials
• n8n Docs: Configure webhook URLs with reverse proxy
• n8n Docs: Enable queue mode
• n8n Docs: Understand concurrency