It works manually. It fails when active. Start with the production execution.

Choose the branch before debugging

Do not “fix” all three branches at once. Record one failing production timestamp, choose its branch, and preserve that example as the acceptance test.

1. Prove what version production can run

Record the workflow ID and the version currently published. Then compare it with the version that produced the successful manual run. Saving an edit is not the same evidence as publishing it.

• Workflow ID and instance or project name
• Last saved time and last published time
• The exact node or expression changed after the last publish
• For separate environments, the revision pulled into production and whether that remote workflow was separately published

This distinction also matters with n8n source control: n8n’s environment tutorial says a push contains the current saved workflow, not its published version, and publishing on the remote server remains a separate step.

2. Prove the production trigger path

For a Webhook node, copy the URL from the node panel rather than reconstructing it. n8n exposes separate test and production URLs: the test webhook is temporary, while the production webhook is registered when the workflow is published.

• Record the full URL with sensitive query values redacted.
• Record HTTP method, path, expected authentication type, and one timestamp.
• Confirm the caller uses the production URL, not /webhook-test/.
• Confirm the public hostname and reverse proxy resolve to this n8n instance.
• For schedules or polling triggers, record timezone and next expected fire time.

In queue-mode deployments with webhook processors, n8n documents different load-balancer paths: production webhook traffic goes to the webhook pool, while manual /webhook-test/* traffic goes to the main process. A routing error can therefore preserve manual tests while breaking production.

3. Capture the actual execution, not a fresh editor run

Open the Executions list and filter to the workflow and time of the external trigger. Save the execution ID, start time, status, duration, last node reached, and first error. If there is no matching execution, return to the trigger branch.

Execution history is only useful if the workflow settings preserve the needed data. Check those settings before generating another controlled example. Redact payload contents before sharing them.

Production evidence
execution_id:
started_at_utc:
status:
trigger_type:
last_node_reached:
first_error_code:
observable_downstream_state:

4. Compare shapes and identities, not secret values

Take one working manual run and one failing production run. At each node through the first divergence, compare key names, types, cardinality, headers, item linking, and expression results.

• Input shape: missing, renamed, null, array-versus-object, or differently nested fields
• Credential identity: credential name or internal ID, account or tenant, scopes, and expiry state
• Environment identity: host, region, timezone, variable names, node version, and n8n version
• Request behavior: method, URL, response status, timeout, retry, and rate-limit headers

Never paste passwords, API keys, OAuth tokens, encryption keys, raw authorization headers, or unrelated customer payloads into a public ticket or initial intake.

5. Check the production runtime boundary

Manual and production executions can have different concurrency and process paths. In regular self-hosted mode, n8n’s production concurrency control applies to webhook and trigger executions—not manual executions. In queue mode, the main or webhook process receives the request and a worker performs the execution.

• Look for queued, waiting, delayed, or cancelled executions.
• Check worker readiness and access to both the database and Redis.
• Confirm all workers share the intended encryption key and configuration.
• Check timeouts, memory pressure, restarts, and deployment timestamps.
• If binary data is involved, verify the configured storage mode is compatible with the deployment.

6. Trace the business outcome beyond n8n

Write the acceptance test as a state change a person or system can observe. “The HTTP Request node returned 200” is intermediate evidence. The contract might instead be “exactly one CRM record has status Qualified,” “one message arrived,” or “the booking appears once on the calendar.”

• Use one correlation or idempotency key across systems.
• Inspect the destination by a safe read-only query when possible.
• Check asynchronous callbacks, background jobs, and retry windows.
• Test duplicate delivery and partial-failure behavior.

7. Replay one controlled example

n8n can copy prior execution data into the current workflow for debugging on supported plans. Its execution list also offers retry with the currently saved workflow or with the original workflow. Use those options only after making downstream side effects safe.

1. Disable or sandbox irreversible side effects.
2. Reproduce the first divergence with the saved production data.
3. Make the smallest change that addresses the observed cause.
4. Publish the intended version.
5. Trigger through the real production path.
6. Verify both execution status and the downstream acceptance state.
7. Record rollback steps and one residual risk.

Official n8n references

The platform-specific behavior in this checklist is grounded in n8n’s current documentation. Feature availability can vary by plan and deployment type.

• Webhook test and production URLs ↗
• View and retry executions ↗
• Debug with previous execution data ↗
• Error workflows and error handling ↗
• Manage saved execution data ↗
• Queue mode and webhook processors ↗
• Production concurrency control ↗
• Source control and production environments ↗

Agent Rescue Desk is an independent technical service. It is not affiliated with, endorsed by, or sponsored by n8n.