How to Monitor Zapier Automations
Zapier turns Zaps off after repeated errors, and a Zap that simply stops triggering never errors at all.
Monitoring a Zap means detecting two separate things: runs that error, which Zapier already tells you about, and a Zap that stops running at all, which Zapier does not.
The second is the one that costs money. A Zap with no runs produces no errors, no notifications and no entries in Zap history, because nothing happened to record.
Understand Zapier's own run statuses first
Zapier assigns every run a status, and they do not all behave the same way. Getting this wrong leads people to build monitoring for the wrong failure.
| Status | What it means | Turns the Zap off? |
|---|---|---|
| Errored | The run failed | Yes, if it repeats |
| Safely halted | Stopped on purpose, usually a search found nothing | No |
| Handled error | A step failed but a custom error handler ran | No |
| On hold | Disconnected app, task limit, or flood protection | No, but nothing runs |
| Scheduled | Errored, and Autoreplay will retry it | No |
On hold deserves attention. A Zap on hold because you hit your task limit is not off and not erroring. It is just not doing anything, and it will stay that way until somebody looks.
The ping: add an HTTP step as the last action
Zapier has a built-in Webhooks by Zapier action. Add it as the final step of the Zap so it only fires when every preceding step succeeded.
Note that this costs one task per run on paid plans. For a Zap firing a few hundred times a month that is negligible; for a high-volume Zap it is worth checking against your plan before enabling it.
If the task cost matters, put the ping behind a Filter so it only fires on the first run of each hour, and set your monitor interval accordingly.
Choosing the interval, which is the hard part
Zaps that run on a schedule are easy. Set the monitor interval to match the schedule and add grace for Zapier's own polling variance, which on polling triggers can be up to 15 minutes on lower-tier plans.
Zaps triggered by events are harder, because a quiet Tuesday and a broken Zap look identical. The workable approach is to set the interval to your longest genuinely normal gap, measured from Zap history rather than guessed, and accept that you will not detect a break during a genuinely quiet period.
For a lead-capture Zap that normally fires eight to forty times a business day, a four-hour interval during business hours catches a real break well before anyone notices manually.
Catching the Zap being turned off
This is the failure mode that Zapier's own notifications handle worst, because the email announcing it goes to the Zap owner. In an agency or a team, that is frequently someone who left.
A heartbeat catches it as a side effect: a Zap that is off does not run, so no ping arrives, so the monitor alerts. That is the strongest argument for putting the ping in even on Zaps you consider low risk.
Use an error handler path as well, not instead
Zapier's Paths and error handler features let you route a failing step somewhere else. Sending an explicit failure ping there gives you an immediate alert rather than waiting out the interval.
Be aware that a Handled error does not count toward Zapier turning the Zap off. That is usually what you want, and it also means a Zap can fail every single run indefinitely while appearing healthy in the Zapier UI. The explicit failure ping is what closes that.
Related guides
The same pattern applies to Make.com scenarios and n8n workflows. Background on the technique is in heartbeat monitoring.