Automation Not Working? A Step-by-Step Troubleshooting Checklist
Trace a failed automation from trigger to saved output. Check credentials, input shape, limits, duplicates, and alerts before retrying a live action.
When an automation fails, identify the last successful step before changing settings or rerunning the whole process. A missing trigger, an expired connection, and a saved result hidden by caching are different problems. A short execution record helps you fix the right one without creating duplicate actions.
First, stop repeated actions
If the workflow can send messages, publish posts, or change records, pause automatic retries while you investigate. Record the time, trigger input, execution ID, and returned error. Redact credentials and personal data before sharing logs with anyone.
A retry is safe only when you know what the previous attempt did. A timeout can occur after a destination accepted the change but before the caller received confirmation. Repeating the same action may create a second post or message.
Check the trigger
Did the starting event reach the workflow? Confirm the workflow is enabled, the schedule uses the intended timezone, and the connected source is the right account. For a webhook, verify the configured destination and whether the source recorded a delivery attempt.
If no execution exists, investigate the trigger before examining the AI prompt. If an execution exists, open that specific run. Do not diagnose from an unrelated successful run earlier in the day.
Inspect credentials and permissions
A connection can authenticate successfully while lacking permission for the requested action. Read access does not imply publishing access. Check the connected account, the exposed tools, and the action’s required capability. For WordPress, compare the actual saved post status with the requested one.
When a tool disappears, refresh its definitions according to the client’s documented process. Avoid creating multiple duplicate connections before understanding whether the problem is discovery, authorization, or the server itself.
Validate the input at each boundary
| Symptom | Check | Possible repair |
|---|---|---|
| Required field missing | Actual input keys and empty values | Validate before the action; route incomplete input to review |
| Wrong record updated | Record ID mapping | Use the verified destination ID, not a similar title |
| AI output cannot be read | Output shape and required fields | Require a clear format and validate it before use |
| Intermittent failure | Limits, service availability, and request size | Reduce load and follow documented retry behavior |
Inspect what was actually passed, not what the diagram suggests should have been passed. A renamed field can break an otherwise unchanged workflow.
Check the destination before declaring failure
Retrieve the record by its returned identifier. Is it present, complete, and in the correct status? If the database record is correct but the public page looks old, inspect caching and the template. If no destination identifier was returned, search carefully for a matching action before retrying.
For our WordPress process, the read-first publishing guide separates connection checks, saved status, and rendered-page checks. Those are three distinct forms of evidence.
Add a failure route and document the repair
After fixing the problem, test the ordinary input and the case that failed. Add an alert with the workflow name, run identifier, and failed stage, keeping sensitive content out of the alert. Decide who owns the queue and when they inspect it.
n8n provides execution inspection and error workflows; its error-handling documentation describes an Error Trigger workflow for responding to execution failures. Other platforms have their own recovery mechanisms.
Write the cause, repair, and prevention in a short log. Your next step is to trace one failed execution from trigger to destination and identify the first boundary where the expected data disappears.
Frequently asked questions
Should I reconnect everything first?
No. Preserve evidence and isolate the failing stage. Reconnecting can hide the cause and introduce additional changes.
Can I retry after a timeout?
First check whether the destination accepted the action. Use a duplicate-prevention identifier or other documented protection where available.
Why did the test work but the live workflow fail?
Live inputs may be larger, missing fields, duplicated, or outside the test account’s permissions. Compare the exact inputs and credentials, not just the diagram.