First decide which failure you have
No execution exists: the trigger did not reach n8n, the wrong URL was called, the workflow was not published, or the trigger's conditions were not met.
An execution failed: n8n started the run and recorded an error. The execution details should identify the node and input that failed.
The execution says success but the job is incomplete: the automation finished from n8n's point of view, but the intended outcome—such as a CRM record, invoice, notification, or updated row—did not happen correctly. This requires checking the downstream result, not just the green execution status.
Seven checks, in order
Confirm the exact trigger
Write down what should start the workflow: a production webhook request, a schedule, a form submission, a new record, or another event. Reproduce that exact event once. Do not start by changing downstream nodes.
Use the production webhook URL
n8n provides separate test and production webhook URLs. The test URL listens during testing. The production URL is registered when the workflow is published. If the external app still calls the test URL, an active-looking workflow can receive nothing in normal operation.
Find the run in Executions
Open the Executions view and filter by workflow, status, and start time. If no execution appears after the reproduced event, stay on the trigger side. If one appears, open it and follow the data node by node.
Inspect the first wrong value
Compare each node's input with its output. Stop at the first missing, empty, malformed, or unexpected value. Later nodes often fail only because an earlier mapping changed.
Verify credentials and permissions
A token may still exist while no longer having access to the workspace, folder, table, object, or action the workflow needs. Re-check the connection and the target resource without exposing the credential itself.
Check the real downstream result
Look at the destination system. Confirm the exact record, message, invoice, file, or status change that should have been created. Check for duplicates and partially written data, not only for complete absence.
Retest with saved execution data
After the smallest safe fix, retry the failed execution with the currently saved workflow when appropriate. Test the normal path, a missing-field case, and a duplicate or retry case before calling the repair complete.
What not to change first
Do not rebuild the entire workflow because one node failed. Do not rotate every credential without evidence. Do not switch platforms before reproducing the problem. Large changes destroy the evidence that tells you where the failure began and can create new failure paths.
What a maintainable repair includes
- A reproducible description of the original failure.
- The smallest change that corrects that failure.
- A test of the expected path and at least one failure or retry path.
- A check in the destination system, not only in n8n.
- A short handoff explaining what changed and how to verify it later.
Technical sources
- n8n Webhook documentation for test versus production URLs and published workflow behavior.
- n8n Executions documentation for filtering, inspecting, and retrying executions.