Find the automation that stopped working weeks ago
A dead automation and a quiet week produce exactly the same evidence: nothing. That’s why the failure you should worry about is the one that never sends you an error.
Think about a smoke alarm with a flat battery. It doesn’t beep to tell you it’s dead. It behaves precisely the way it behaves when there’s no fire, which is to say silently, and the two situations are indistinguishable from the kitchen.
Automations fail the same way. The alerts you set up, if you set any up, fire when something goes wrong during a run. They can’t fire when there was no run, because nothing happened, and nothing happening is also what a normal Tuesday looks like when there was nothing to do.
So the invoices didn’t go out. The lead didn’t get added. The backup script didn’t run. Three weeks later somebody asks a question and you go looking, and the answer has been sitting in a run history nobody opens.
It’s a fifteen minute check and you only need to do it properly once, because the last step makes the next one automatic.
Before you start
Fifteen minutes and login access to wherever your automations live. Zapier, Make, n8n, GitHub Actions, a cron job on a server, a scheduled task in your accounting software. All of them keep a history, and that’s the only thing this guide needs.
Write down what’s supposed to be running
Before you open anything, list what you believe is automated, and next to each one write how often it should run and what you’d see if it did.
That second column is the important one. “Daily” and “an email in my inbox each morning” are different kinds of knowledge, and the second is what lets you spot an absence.
Include the boring ones. Backups, invoice reminders, lead routing, the script that syncs two systems, the thing a contractor set up in 2024 that everyone assumes is still going.
Open the run history on each one
Every automation platform has this, usually called History, Runs, Logs or Executions.
For each item on your list, find the last successful run and read the date. Not the last run. The last successful one.
Compare it against the expected frequency you wrote down. A daily job whose last success was three weeks ago is dead and has been dead for three weeks. That’s the whole check, and it usually takes about a minute per automation.
Look for the failures that don’t look like failures
Some states aren’t errors and won’t be in an error report. These are the ones that hide.
- Filtered.
- A run that hit a filter and stopped is recorded as filtered, not failed. That’s correct behaviour, right up until a changed field means everything gets filtered and the automation quietly does nothing for a fortnight.
- Skipped by the trigger.
- Platforms track which records they’ve already seen. A record that gets updated rather than created, or deleted and recreated, can be passed over. No error, no run.
- Expired authentication.
- A token expires and the connection to the other app dies. Whether you get told depends on a notification setting you probably never opened.
- A dropped webhook.
- Some apps stop calling your automation after a reauth or a plan change. Your side stays switched on and waits, politely, forever.
- A renamed field.
- The app on the other end changes its data structure, your mapping points at something that no longer exists, and the run stops going through.
Read the history with those in mind. A wall of green is not the same as a wall of work done.
Turn on what your platform already offers
Most platforms will email you when a run errors, and this is usually off or pointed at somebody who left.
Turn it on and point it somewhere you actually read. It’s a two minute job and it catches the loud half of the problem.
Be clear about what you’ve just bought, though. This covers runs that failed. It does nothing at all about runs that never happened, which is the half this guide is about.
Build the check that catches silence
For the automations that genuinely matter, you want an alert on absence rather than on error.
The pattern is the same everywhere and it’s simpler than it sounds. The automation reports in when it finishes, and a second thing complains if the report doesn’t arrive.
- Have the job write a timestamp somewhere at the end of a successful run: a row in a sheet, a line in a file, a ping to a monitoring service
- Have something check that timestamp on a schedule, and tell you if it’s older than it should be
If you’d rather not build it, dead man’s switch monitoring services do exactly this and most have a free tier for a handful of checks. The concept is what matters: something has to be watching for nothing.
Do this for the two or three automations where silence actually costs you money. Not all of them.
Break one on purpose
Don’t finish believing the monitoring works. Make it prove it.
Pick the automation you just wired a silence check onto, and switch it off. Then wait for the window to elapse and confirm you get told.
You’ll usually learn one of three things. The alert arrives and you’re done. Or it doesn’t, and you’ve found out now instead of in November. Or it arrives somewhere you don’t look, which is the same as it not arriving.
Switch the automation back on. Write down what you tested and when.
A boundary worth knowing about
This finds automations that stopped. It says nothing about automations that are still running and doing the wrong thing.
A job that fires perfectly every day while writing to the wrong field, or emailing the wrong list, has a spotless run history. Silence monitoring is blind to it by design, because from the outside it looks like success. Catching that is a different job, closer to reading the output than watching the schedule.
The other edge is that the checker can die too. A monitor that’s meant to complain about silence, and which has itself gone quiet, reports exactly the same nothing as a healthy system. Use a hosted service for the outermost check where you can, so the thing watching isn’t sitting on the same machine as the thing being watched.
If you have staff
Every automation needs a name attached to it. Not who built it, who notices when it stops. Those are frequently different people and the second one is the one that matters.
Check the ones built by people who have left. They’re the most likely to be running on an expired connection or a personal account nobody can access, and the least likely to have been looked at since handover.
The short version
- List what should be running, how often, and what you’d see if it did
- Open each run history and read the date of the last successful run
- Watch for filtered, skipped, expired auth, dropped webhooks and renamed fields. None of those are errors
- Turn on the platform’s error notifications and point them at somebody who reads them
- For the two or three that matter, have the job report in and have something complain when it doesn’t
- Switch one off deliberately and confirm you get told
Sources
- Monitoring client Zaps for silent failures, Zapier Community — the core problem stated by the people who hit it: error alerting fires on errors, and a run that never happened looks like a quiet day
- Zapier monitoring and detecting automation failures, Lowcode Agency — the silent failure modes, including expired authentication, dropped webhook subscriptions and changed field mappings
Written August 2026. The failure modes here are properties of how scheduled automation works rather than of any one product, so they should age well. Menu names will not.
Prints to PDF from your browser — colours and all.