Most n8n workflows that stop working have a trigger, credential, or data problem rather than a bug in n8n. The most common causes are using the test webhook URL instead of the production one, a workflow that isn't activated, a self-hosted instance that generates the wrong webhook address, expired connections to apps like Google or Slack, and expressions that break when incoming data changes shape. The execution history usually shows exactly which node failed and why.
Typical symptoms | Webhook never triggers, runs fail at a node, schedules don't run, duplicated actions, silent failures |
Most common causes | Test vs production webhook URLs, inactive workflows, self-hosting URL settings, expired credentials, broken data mapping |
How we fix it | Review execution history, fix triggers and credentials, correct data mapping, add error handling and alerts |
Turnaround | Same-day diagnosis; most fixes in 24–48 hours |
Price | Live Debug from $20; fixed-price quote for the full fix |
Signs Your n8n Workflow Has This Problem
The webhook works while testing but never triggers in real use
Webhook URLs in your self-hosted n8n show localhost:5678
Executions fail with authorization or credential errors
A node that used to work now errors on missing or undefined fields
Scheduled workflows run at the wrong time or not at all
The same record is created multiple times
Failures happen without anyone being notified
Why n8n Workflows Stop Working
1. Test webhook URL used in production
n8n gives every webhook node a test URL and a production URL. The test URL only listens while you're actively testing in the editor. External apps configured with the test URL, or pointing at a workflow that isn't activated, never trigger it.
2. Wrong webhook address on self-hosted instances
When n8n runs behind a domain, reverse proxy, or Docker, it needs to know its public address. Without that setting, it displays and registers webhook URLs with localhost, which external services can't reach.
3. Expired or revoked credentials
Connections to Google, Microsoft, Slack, CRMs, and other apps can expire, lose permissions, or be revoked when passwords or app settings change, so nodes fail with authorization errors.
4. Data mapping that breaks when data changes
Expressions refer to specific fields and node names. Renaming a node, an app changing its response format, or empty values from a form cause errors or silently wrong results. n8n also runs many nodes once per incoming item, which creates duplicates when lists aren't handled deliberately.
5. Schedules, timeouts, and resources
Schedule triggers follow the instance's time zone setting. Large files or long runs on small self-hosted servers can hit memory limits or timeouts and stop executions partway through.
How We Diagnose the Broken Workflow
Review execution history. Find failed runs, the failing node, and the exact error and input data.
Check triggers. Confirm the workflow is active and external apps use the production webhook URL.
Verify instance settings. For self-hosted n8n, check the public URL, time zone, and reverse proxy configuration.
Test credentials. Reconnect and test each app connection and its permissions.
Trace data between nodes. Compare real incoming data with what expressions expect, including empty and list values.
Check resources. Review memory, execution time, and data sizes on self-hosted servers.
How We Fix It
Root cause | Fix |
Webhook not triggering | Activate the workflow and switch external apps to the production webhook URL |
Localhost webhook URLs | Set the public webhook URL and proxy headers correctly on the self-hosted instance |
Credential errors | Reconnect apps with the right permissions and use service accounts where appropriate |
Broken data mapping | Make expressions resilient to missing fields, handle lists deliberately, and validate input |
Duplicate actions | Add deduplication checks before creating records |
Silent failures | Set up an error workflow that alerts you and logs failed data for replay |
We test the workflow with real data from your apps and replay failed runs so no leads or records are lost.
Example Fix
Situation: A consulting firm used self-hosted n8n to send website form leads to its CRM and Slack. After moving the server to a new domain, leads stopped arriving for a week without anyone noticing.
Cause: The instance's public webhook URL was never updated, so n8n registered webhook addresses using localhost, and the form tool was still using an old test URL. There was no error workflow to raise an alert.
Fix: Set the correct public URL behind the reverse proxy, updated the form tool to the production webhook, added a duplicate-lead check, created an error workflow that posts failures to Slack, and replayed the missed leads.
Result: Leads flowed into the CRM again, missed leads from the outage were recovered, and future failures triggered an immediate alert.
How to Keep It From Happening Again
Always configure an error workflow so failures notify someone immediately.
Use production webhook URLs in every external app once a workflow goes live.
Test with real sample data including empty fields and multiple items.
What You Get
Root cause explained in plain language
Working, activated workflow tested with real data
Error alerts and failed-run logging
Missed data replayed where possible
Frequently Asked Questions
Why does my n8n webhook work in testing but not in production?
The external app is probably using the test webhook URL, which only listens during manual testing, or the workflow isn't activated. Use the production URL with an active workflow.
Why does my self-hosted n8n show localhost in webhook URLs?
The instance doesn't know its public address. Setting the webhook URL environment setting for your domain fixes the generated URLs.
Why does my n8n workflow create duplicate records?
Many nodes run once for each incoming item, and retries can repeat actions. Handling lists deliberately and checking for existing records prevents duplicates.
How do I get notified when an n8n workflow fails?
Create an error workflow and assign it in the workflow settings. It can send alerts to email, Slack, or other tools with details of the failure.
Can you fix workflows on n8n Cloud and self-hosted n8n?
Yes. We work with both, including Docker and reverse proxy setups for self-hosted instances.
Related Problems
OpenAI API 429 rate limit errors
Google OAuth login not working
Shopify API integration broken
CrewAI multi-agent workflow failing
Docker container exits immediately
Get Your Automations Running Again
Share the failed execution or what stopped working. Get a diagnosis and a fixed price.