2026-10-24
Zapier Zap stopped running with no error? How to get alerted
A Zap can be turned off, held, or simply stop triggering without an error on the last run. Add a Webhooks by Zapier POST at the end so the missing call is the alert.
Zapier has a history page, and it is honest about the runs it has. It cannot show you a run that never started. When a Zap stops triggering, the history stays on the last success, the Zap editor still says the steps are configured, and nothing in that last run is an error. The alert you want is the one that fires because a call you expected did not happen.
Ways a Zap stops without a red row
Zapier's help article Zap is not running lists the cases where Zapier itself turns a Zap off. One of them is errors, and the threshold is specific: Zapier turns the Zap off if it errors 95% of the time and has run more than 20 times in the past 7 days. On Team plans the account owner gets an email and a 24-hour grace period before that happens. Enterprise gets a 72-hour grace period, and can override the ratio per Zap. If you are not on one of those plans, do not assume an email arrives before the switch flips. And this whole path requires errors. A Zap that never runs does not have an error ratio.
The same article describes stops that are not errors at all. If the Zap uses a feature your current plan does not include, multi-step Zaps are the example they give, Zapier holds the actions. The Zap can still look on. If you hit the task limit for the billing cycle, actions across the account are held until you upgrade or the cycle resets. Held runs are waiting. They are not failures, and they do not execute the later steps. Editing a trigger or an action also turns a Zap off until you turn it back on. A disconnected account tends to hold runs rather than mark them failed.
Then there is the quiet case. The Zap is on, the plan is fine, the last run succeeded, and the trigger simply has not seen anything new. For a 'new row' trigger that is a normal Tuesday. For a Schedule trigger that is supposed to run every weekday at 08:00, it is an outage, and Zapier will not file an error about a fire that did not happen. Safely halted is a third status worth knowing: a search that found nothing stops the Zap on purpose, does not count as an error, and will not turn the Zap off. If your heartbeat is after that search, a halt skips it.
Ping from the last step
Add Webhooks by Zapier as the last action, after the steps that do the work. Choose POST. The URL is the monitor's ping URL. Payload type is Json. You do not need a data field for the heartbeat to count. If the Zap has numbers worth keeping, send the fields the ping API actually stores.
App: Webhooks by Zapier
Action event: POST
URL: https://nightshiftwatchdog.com/ping/YOUR_TOKEN
Payload type: Json
Data:
tokens: (optional number)
cost_usd: (optional number)
duration_ms: (optional integer)
Wrap the request in a Code step only if you must build nested JSON.
Otherwise the Data fields above are enough.Test the step once from the editor so you know the URL is right. A 200 with ok set to true means the monitor accepted it. A 404 means the token is wrong. A 400 means a field was not a number. Unknown JSON keys are ignored, so a stray label will not fail the step, and it will also not be charted. Put the real URL in a Zapier secret or a Storage value if you duplicate Zaps. The token is a credential.
This step runs only if the Zap gets that far. That is the point. If the Zap is off, the webhook never leaves. If the trigger does not fire, the webhook never leaves. If Zapier holds the action because of a task limit or a plan that does not include multi-step Zaps or this webhook action, the webhook never leaves. Check the Zap's status after you add the step. A held webhook is itself the outage, and the monitor is what says so, because the ping does not arrive.
Schedule the monitor to the cadence you actually expect
A heartbeat is a statement about frequency. It is a good fit for a Zap that should run on a clock: every hour, every weekday morning, every 15 minutes. Create the monitor with that interval, or the same 5-field cron, and a grace period long enough for Zapier's queue. The schedules page describes how grace is added after the next slot. A Zap that finishes at 08:04 should not be graded against 08:01.
It is a bad fit, used alone, for a Zap that should run only when the world produces an event. No new leads today looks exactly like a dead trigger: no ping. If that ambiguity matters, add a second, tiny Zap whose only job is a schedule and this webhook. The business Zap can stay event-driven. The schedule Zap is the proof that the account can still run something. If you would rather not spend a task on that, accept that the event Zap's silence means 'nothing happened or the trigger died' and investigate both.
Do not point a five-minute monitor at a daily Zap. You will get an alert every day, and then you will ignore it. Do not point a daily monitor at a Zap that must run hourly. You will find out tomorrow.
What a ping does not tell you
A success ping says the last step ran. It does not say the earlier steps did the right thing. A Filter that stops the Zap, or a search that safely halts it, will skip the webhook, and the monitor will treat that as a miss. If a filter skipping the run is normal, move the webhook before the filter, or add it on both the continue path and a path that means 'nothing to do, and that is fine.' Paths are a paid Zapier feature. If your plan holds them, you are back to a Zap that looks configured and does not run.
Autoreplay and a manual replay can POST twice. The monitor stays up. Two successes are not an incident unless you have also set a runs limit. On Pro and Team, a hard max of 1 run per hour catches a daily Zap that fires twice inside an hour, including a replay you did not mean to send. It also catches a replay you did mean to send. Leave the limit unset if double delivery is ordinary. The silence alert is the one that matches a Zap that stopped.
Zapier Manager can watch a Zap's on/off status, and it is worth having if you want that specific event. It still does not notice a Zap that stays on and stops triggering. The webhook at the end does, because the absence is the signal.
Nightshift Watchdog is a small monitor for that URL. Free covers 3 monitors and email when the ping goes missing and when it comes back. The docs show the same POST for cron, n8n, and GitHub Actions, if this Zap is not the only thing you need to hear from.