Why Your n8n Workflow Works in Testing But Breaks in Production

It's Almost Always One of Three Things

If your n8n workflow runs fine locally or in a test environment and then breaks in production, there's a short list of causes.

Credentials got wiped on container restart. Webhook URL changed on redeploy. Environment variables didn't survive.

Each one looks different when it breaks. Each one has a different fix. Here's how to tell which you're dealing with.

Reason 1: Credentials Wiped on Container Restart

This is the most common one. Hits people specifically on Railway and Render free tier.

What's happening: Railway and Render's free tier puts containers to sleep after inactivity (usually 15 minutes). When the container wakes back up, it starts fresh from the Docker image. If your n8n data (credentials, workflow configs, execution history) is stored inside the container rather than in a persistent mounted volume, it gets wiped on every restart.

The symptom is specific. You open n8n after it's been idle for a few hours. All your workflows are there, they look fine. But when you test them, credentials show "not connected" or return 401 errors. You reconnect everything, it works again. Then the next morning it's broken again.

One company we helped was running a 14-node lead scoring workflow on Railway free tier. Credentials were wiping every 6 to 8 hours because their n8n instance was going to sleep between overnight batches. It looked like an n8n bug. It was a storage issue.

The fix: mount a persistent volume and point N8N_USER_FOLDER at it.

On Railway:

1. Go to your service settings
2. Add a Volume, mount path: /home/node/.n8n
3. Set env var: N8N_USER_FOLDER=/home/node/.n8n

On Render:

1. Add a Disk in your service settings (1GB is enough)
2. Mount it at /opt/render/project/.n8n
3. Set: N8N_USER_FOLDER=/opt/render/project/.n8n

Once the data directory is on a persistent volume, it survives restarts. Every credential, every workflow config, stays put.

One more thing: if you're using n8n's encryption for credentials (which you should be), make sure N8N_ENCRYPTION_KEY is set as an env var explicitly. If this value changes or isn't set, n8n can't decrypt stored credentials and they'll all show as broken even though they exist.

Reason 2: Webhook URLs Changed on Redeploy

This one is sneaky because there's no obvious error on either side.

When you redeploy n8n (new image, updated env vars, whatever), n8n can generate different webhook URLs depending on how it's configured. Any external service that was calling your old webhook URL (Stripe, a form tool, your CRM) is now sending requests to a dead endpoint.

The symptom: incoming webhooks just stop working. The external service fires the event, nothing appears in n8n's execution log, no error in either place. It looks like the external service stopped sending, but it didn't.

Check this first: go to your n8n webhook trigger node and look at the "Production URL" shown. Then check what URL you have registered in the external service. If they don't match, that's your problem.

Three ways to fix it:

Option A: Set WEBHOOK_URL explicitly. Add the env var WEBHOOK_URL=https://your-n8n-domain.com/ to your deployment config. This makes n8n use that base URL for all webhook URLs instead of trying to auto-detect it from the request. Quick fix, 5 minutes.

Option B: Use a custom domain. Instead of using Railway or Render's generated subdomain, set up a custom domain for your n8n instance. Webhook URLs are then based on a domain you control, which doesn't change on redeploy.

Option C: Webhook relay service. Something like Hookdeck or Svix sits between external services and your n8n instance. You register one stable URL with external services, the relay forwards to your n8n wherever it lives. Adds a small amount of latency but solves the unstable URL problem permanently.

Option A is usually the right quick fix. Option B is the right long-term setup.

Reason 3: Environment Variables Not Persisting

Less common, but causes confusing failures that look like code problems.

If your workflow uses environment variables to store API keys, database URLs, or other config, those need to be explicitly set in your deployment platform's settings. Your local .env file doesn't follow the workflow to production.

The symptom: the workflow runs, it reaches a certain step, that step returns 401, null, or connection refused. The node itself isn't broken. It just can't authenticate because it's looking for an env var that doesn't exist in production.

To check: in n8n, look at any credentials or expressions using {{ $env.SOME_KEY }}. Go to your deployment platform (Railway Variables tab, Render Environment tab, or your Docker Compose file) and verify every variable referenced in your workflows is actually set there.

The mistake is building locally with a .env file, then deploying and only setting a few obvious variables, missing the ones you reference in node expressions.

Using the Execution Log to Diagnose

When something breaks and you're not sure which of these three it is, start in the Executions tab.

Go to your failing workflow, click Executions. If there are recent executions, click one and look at what step failed and what error it shows. 401 or 403 errors point to credentials or missing env vars. "Cannot read property of undefined" or empty values often mean env vars aren't set. If the execution never started at all, the webhook URL is probably wrong.

If there are zero executions even though events should be coming in, the external service is sending to the wrong URL.

The execution log catches most problems clearly if you know to look there first.

The Setup That Prevents All of This

For a production n8n instance that stays running reliably:

• Persistent volume for N8N_USER_FOLDER (mandatory, set this before anything else)
• Custom domain with WEBHOOK_URL set explicitly
• N8N_ENCRYPTION_KEY set as a fixed env var and backed up somewhere safe
• All credentials stored in n8n's credential store, not hardcoded in workflow expressions
• A monitoring step at the start of important workflows that sends a Slack or email alert if the workflow hasn't run in X hours

The last one catches silent failures. Workflows break for reasons beyond these three (API changes, rate limits, data format changes). A simple heartbeat check that fires when a workflow goes quiet for too long has caught more issues than active monitoring for us.

---

If you want us to build this for you, book a free workflow audit at airtective.com