Automation failure diagnosis in order: from did it run to who was told

How to use this order

Work through the steps in order and stop at the first one that explains what you see. Each step names the question, what to look at and the guide that goes deeper. Change nothing on a live automation while diagnosing, and do not replay runs to see what happens: replay can repeat steps that already succeeded. This is an authored process map, not a vendor procedure, and it does not claim to cover every failure.

Steps one to three: did it run, what arrived, what was sent

Step 1, did it run? Look at the run history or executions list for the time in question. No run means a trigger problem; a failed run means read its error. For n8n webhooks, check the production executions, not the editor. Step 2, what did it receive? Compare the trigger data with the source record, remembering that test samples may differ from live data, and that polling and instant triggers behave differently. Step 3, what did it send? Compare the data the action sent with what the destination needed, using the field-mapping guide for dropped or reshaped values.

• Step 1: run history, and the n8n production-executions guide.
• Step 2: the trigger's data, polling or instant, test versus live.
• Step 3: the action's inputs and the destination's required fields.

Steps four to six: what the destination holds, repeated or lost, who was told

Step 4, what does the destination hold? Count records for one source event: zero, one or several. Several points to the duplicate guide. Step 5, was something repeated or lost? Check for retries, replays and overlapping windows, and read the webhook and polling guides for senders that retry and jobs that ask since the last run. Step 6, who was told? For each failure, find who received an alert, how late and whether it would have been acted on; the failure-alerts guide and the platform guides for Zapier, Make and Airtable show the documented defaults.

• Step 4: counts per source event, then the duplicate guide.
• Step 5: retries, replays, overlaps, handled keys.
• Step 6: alert recipients, delays and suppressions.

Step seven: decide what to buy, if anything

If the cause is one Zap, one scenario or one automation, the matching one-off outcome repairs it on a copy and proves it with synthetic data. If nobody is told when things fail, the alerts outcome hooks up to five automations to a shared place and two named people. If you would rather someone watched named automations weekly, the standing service does that and prepares corrected copies for you to switch on, with no response-time promise. Many problems need none of these: the guides above are written to be useful on their own.