How to tell when a Zap stops running

Zapier's reporting is organised around tasks, which is the right unit for it: task history, error emails and the counters on your dashboard all describe work that happened, accurately and in detail. “Has this Zap run today?” is answerable there whenever you go and look. What a deadline adds is an answer to that question between visits.

A Zap can stop producing tasks for reasons that are nobody's error:

• The Zap is off. Somebody switched it off to test something and it was never switched back on, or it was paused automatically after repeated errors.
• A polling trigger stops seeing new items because a filter, a permission or a renamed field means it never matches again. The polling is working correctly and finding nothing, which is not an error.
• An instant trigger's upstream service stops sending. Nothing arrives, so nothing runs.
• The account has reached its task limit for the billing period, so runs are held rather than executed.

In all four the Zap is configured correctly and Zapier is doing what it should. The distinction that matters is between ran and failed and did not run, and it is the second one a deadline is good at catching.

Zap error emails tell you about tasks that errored, which is the failure most automations actually have and the reason they are worth keeping on. They are about tasks that ran.

Task history answers the question precisely, whenever you go and look. Detection time is therefore your own checking habit, which is fine for the Zaps you open often.

A second Zap watching the first shares an account with the Zap it is watching, along with its task limits and its on-off state. That makes it convenient and it makes it dependent.

Silent Fail adds one thing to that: an expectation held outside your Zapier account. Something that knows this Zap reports every hour, and says so when an hour passes without a report. It sits alongside the error emails rather than replacing them. Different failure, different tool.

Have the Zap call a URL as its final action. Each call resets a timer that lives outside Zapier. If the timer expires, no call arrived, and you get an email. The reason the Zap went quiet does not matter, which is the point: off, unmatched, out of tasks or upstream silence all look identical from outside, and all of them are things you want to know.

Add a Webhooks by Zapier action as the last step of the Zap, choose the GET action, and set the URL to the ping URL for that monitor:

Each monitor has an expected interval and a grace period; the deadline is the last ping plus both. Grace defaults to twice the interval, because a Zap that polls a few minutes later than usual is perfectly normal, and an alert on normal behaviour is an alert you will learn to ignore.

After the deadline you get one email for that outage, not one per check. The checker runs every minute and records the alert the first time, so the rest stay quiet. When pings resume you get one all-clear, and only then can the monitor alert again: two emails per outage, one at each end.

For a Zap you expect once a day at a particular time, the deadline is wall-clock in your account's timezone, so it keeps meaning the same hour to you through daylight-saving changes.