To fix a broken automation workflow, start with the run history: find the first failed run, open the step that errored, read the actual error message and the input data it received. Nine times out of ten the cause is one of five things: an expired connection, a changed field or form, bad or missing data, an API limit, or the workflow being switched off. Fix the cause, rerun the failed records, then add an error alert so you hear about the next failure before your client does.
I fix broken automations for agencies regularly, across Make, Zapier and n8n. This is the process I follow, in the order I follow it.
Step 1: Confirm what is actually broken
Before touching anything, write down:
- What should have happened. "New lead from the Facebook form should appear in GoHighLevel and ping Slack."
- What actually happened. "Lead is missing in GoHighLevel. No Slack ping."
- When it started. The last known good run is the most useful clue you have.
- What changed around then. New form fields, a CRM migration, a password change, a team member leaving, a plan downgrade.
"It stopped working on Tuesday, and on Monday we renamed the pipeline stages" solves a lot of cases on its own.
Step 2: Check if the workflow is even on
It sounds obvious, but check:
- Is the Zap, scenario or workflow turned on?
- Has the platform paused it after repeated errors? Some platforms switch workflows off automatically when they fail too often.
- Has your plan run out of tasks, operations or executions for the month?
- Is the trigger still pointing at the right form, sheet, list or pipeline?
Step 3: Read the run history
Every platform keeps a log. This is where real debugging happens.
Zapier not working
Open Zap history and filter for errors or halted runs. Click into a run to see each step's input and output. Look at the first step that shows an error, not the last. Zapier also shows when a run was filtered out, which explains many "it did not run" complaints: the filter did its job on data you did not expect.
Make.com scenario failing
Open the scenario's history and click a failed run to see the bubble on each module. Click the bubble with the error to see the input bundle and the error message. Also check incomplete executions if they are enabled on the scenario, because stored failed runs can often be resolved and retried from there. See Make.com error handling for setting this up properly.
n8n workflow errors
Open the executions list for the workflow, find the failed execution and open it. n8n shows which node failed and the data each node received. You can usually retry a failed execution from the list once the cause is fixed.
Step 4: Match the error to a cause
These are the causes I see most, and how to fix each.
Expired or broken connections
Errors mentioning authentication, unauthorized, invalid token or permission denied usually mean a connection needs reauthorizing. This happens after password changes, when the person who connected the app leaves, or when an app revokes old tokens. Reconnect using a company-owned account, not a personal one, so it does not happen again.
Changed fields or forms
Errors about missing fields, or data landing in the wrong place, often follow a change to a form, CRM custom field or sheet column. If someone renamed a column in Google Sheets or rebuilt a form, the mapping in the workflow may now point at nothing. Remap the fields and rerun a test.
Bad or missing data
A workflow that works for most records but fails for some is usually choking on specific data: an empty email, a phone number with letters, a date in the wrong format, a name with special characters. Look at the input of the failing run and compare it to a successful one. Add formatting steps and filters, or a fallback value for empty fields.
Rate limits and timeouts
Errors mentioning too many requests, rate limit or timeout mean the workflow hit an app's API limit or took too long. Fixes include adding delays between calls, processing in smaller batches, or splitting one long workflow into several. Check the app's current API documentation for its limits rather than guessing.
Duplicates and loops
If a workflow creates the same record twice, or triggers itself, add a search step before creating records, and make sure an update made by the workflow does not fire its own trigger again.
App changes
Sometimes a connected app changes its API or the automation platform updates a module. If a long-stable workflow breaks with an unfamiliar error and nothing changed on your side, check the platform's status page and community forum for others reporting the same issue.
Step 5: Fix, then test with real data
- Make the smallest change that fixes the cause.
- Run the workflow once with a test record that matches the failing case.
- Check every system it writes to, not just the last step.
- Run it with a normal record to make sure you did not break the common case.
Step 6: Recover the records you missed
Fixing the workflow does not fix the leads, tasks or messages that failed while it was broken. Use the run history to list every failed run since the problem started, then:
- Replay or rerun the failed runs if the platform supports it and the data is still valid
- Or export the source records (form entries, CRM contacts) and run them through again
- Check for duplicates after recovery, especially if some runs partly succeeded
For lead workflows, also tell the sales team which leads were delayed so they can follow up personally.
Step 7: Stop it happening again
A broken automation fix is not finished until you will know about the next failure. Add:
- An error route or error workflow that posts to Slack or email with the workflow name, the failing step and the record involved
- Retries on steps that call unreliable APIs
- Validation at the start, so bad data is caught before it causes a half-finished run
- An owner, so someone actually reads the alert
- A note in your documentation describing what broke and how it was fixed
My live builds all include error handling. The Client Wins Slack bot, for example, has separate live and test channels and its own error routes, so testing never spams the real channel and failures are visible. If you want to check your whole setup, use my automation audit checklist.
When to rebuild a broken automation workflow instead of patching
Sometimes the right fix is a rebuild. Consider it when:
- The workflow is so large that nobody can follow it
- It has been patched many times and still fails
- It was built around a process that has since changed
- It runs on a personal account or a tool you are leaving
Rebuilding a fragile workflow with clear structure, error handling and documentation often takes less time than the next three emergency fixes.
How I fix broken automations
If you would rather hand it over, Automation Rescue is my fixed-price fix: I audit one broken or half-built workflow, fix it and test it against real data, add error handling and give you a written handover of what broke and what changed, within 48 hours. It covers Make, Zapier, n8n and GoHighLevel. You can see examples of how I structure workflows on the work page.
Not sure if it is a quick fix or a rebuild? Send me a screen recording of the problem and I will record a free 15-minute Loom teardown.
FAQ
Why did my Zapier Zap stop working?
Common causes are an expired app connection, a changed form or field, a filter blocking runs, running out of tasks, or Zapier turning the Zap off after repeated errors. Zap history shows which step failed and why.
Why is my Make.com scenario failing?
Usually an expired connection, a changed field mapping, unexpected data, an API rate limit or a timeout. Open the scenario history, click the failed run and read the error on the module that failed.
How do I debug n8n workflow errors?
Open the workflow's executions list, open the failed execution and check which node failed and what data it received. Fix the cause, then retry the execution.
How do I stop automations failing silently?
Add an error route or error workflow that sends a Slack or email alert with the workflow name and failed record, and give each workflow a named owner who responds to those alerts.