Guides / Monitoring guides

Zapier: get notified when a Zap stops running

Updated · 5 min read

When Zapier turns a Zap off or holds its runs, what error emails cover, and how to add a heartbeat that alerts on silence.

Zapier emails you when a Zap errors, and it's usually right to. The harder case is a Zap that stops running without erroring. It was turned off, its runs are on hold, or its trigger stopped seeing new data. You find out weeks later when someone asks why the leads stopped arriving. This guide covers what Zapier reports on its own, the cases it can't report, and how to add a heartbeat that alerts you when a Zap goes quiet.

Why a Zap stops running

From Zapier's own help center, the main reasons are:

  • Too many errors. Zapier automatically turns off a Zap that errors 95% of the time and has run more than 20 times in the past 7 days. On Team and Enterprise plans, the account owner gets an email and a grace period first: 24 hours on Team, 72 hours on Enterprise. An Error ratio override setting in the Zap's advanced settings can keep a Zap running despite errors.
  • Task limit reached. When the account hits its task limit for the billing cycle, Zapier holds the actions of every Zap. Nothing runs until the cycle resets or you upgrade, and then you can replay the held runs.
  • Premium features on an unsupported plan. Actions that use features your plan doesn't include are held. Zapier's examples are multi-step Zaps, Paths and premium apps. This often happens when a trial ends.
  • App access policies in Enterprise accounts can hold steps that use a restricted app.

And there are reasons Zapier can't see at all:

  • Someone switched the Zap off while editing it, or deleted the trigger's source (a form, a sheet, a webhook in another app).
  • The trigger app stopped producing new data. A polling trigger that finds nothing new simply doesn't start a run.
  • A Filter step stops every run because the incoming data changed shape.

What Zapier gives you

Zap history lists every run with a status. The statuses that matter for monitoring:

StatusMeaning
ErroredThe run hit an issue and didn't complete. Repeated errors can turn the Zap off.
Safely haltedThe run stopped on purpose, usually a search step with no results. Doesn't turn the Zap off.
On holdWaiting on a fix: disconnected app, task limit, plan change or flood protection. Can be replayed.
Handled errorA step errored but a custom error handler ran instead. Doesn't turn the Zap off.
ScheduledErrored, but Autoreplay will retry it automatically.

Error notification emails go to your account email. Under Settings → Notifications → My notification settings you can choose Immediately (the default), Immediately, then hourly summary, Hourly summary, or Never. Paid plans can add custom notification rules for specific Zaps. Note Zapier's documented limitation: no error email is sent when an error handler runs.

Zapier Manager is a built-in app with a New Zap Error trigger. You can use it to post errors to Slack.

All of these react to runs. If no run happens, because the Zap is off, held, or the trigger has nothing new, there's no errored run and no email.

Add a heartbeat to the Zap

The idea is to make the Zap prove it did its work. The last step pings an external URL. If pings stop arriving on schedule, you get an alert, whatever the reason.

Plan note: the ping is an extra action step. On Zapier's Free plan, multi-step Zaps are a paid feature, so a Zap with two actions will have its runs held. You need a plan with multi-step Zaps for this setup.

Step 1: create the monitor

In Flowhush, click New monitor:

  • Name: Zapier: Typeform → HubSpot
  • Expected every (seconds): how often the Zap normally runs. For a Schedule by Zapier Zap that runs daily, use 86400. For event-driven Zaps, use the longest gap you consider normal, e.g. 43200 for "at least one lead every 12 hours".
  • Grace period (seconds): slack for delays, e.g. 3600.

Copy the ping URL, https://flowhush.com/p/YOUR-MONITOR-UUID.

Step 2: add the webhook step

At the end of the Zap, add an action: Webhooks by Zapier → GET.

URL: https://flowhush.com/p/YOUR-MONITOR-UUID
Query String Params: (leave empty)

Test the step. Flowhush answers OK, and the monitor's Recent pings shows the request.

To also check the data the Zap produced (Pro plan output checks), use Webhooks by Zapier → POST instead:

URL: https://flowhush.com/p/YOUR-MONITOR-UUID
Payload Type: Json
Data:
  contact_id   | (map "Contact ID" from the HubSpot step)
  email        | (map "Email" from the trigger)

Zapier's docs note that if you leave Data empty, all fields from the previous step are sent. That's convenient, but map only what you want checked so you don't send personal data you don't need to.

On the monitor, turn on Body must be valid JSON and add contact_id under Required JSON keys. A run where HubSpot returned no contact now counts as a failure, even though Zapier shows it as a success.

Step 3: catch errors immediately (optional)

On paid Zapier plans you can add a custom error handler to a step: click the step's ⋯ menu → Add error handler. The Zap splits into a Success path and an Error path. On the Error path, add Webhooks by Zapier → POST:

URL: https://flowhush.com/p/YOUR-MONITOR-UUID/fail
Payload Type: Json
Data:
  error | (map "Error Message" from the step that errored)

This matters because Zapier doesn't email you when a handler runs. Without your own notification on the Error path, a handled error is silent. A /fail ping marks the monitor down immediately and sends one alert. The error message is stored with the ping (first 1 KB).

You can test both endpoints from a terminal:

curl -fsS -m 10 https://flowhush.com/p/YOUR-MONITOR-UUID
curl -fsS -m 10 -X POST -H 'Content-Type: application/json' \
  -d '{"error":"test from terminal"}' https://flowhush.com/p/YOUR-MONITOR-UUID/fail

Things that trip people up

  • Filters and paths. A run stopped by a Filter never reaches the last step, so it doesn't ping. That's often what you want, because "no qualifying leads for 12 hours" is worth knowing. If not, size the period for it. With Paths, put a ping at the end of each path that matters.
  • Polling delay. Polling triggers check for new data on an interval that depends on your plan. Add that to the grace period.
  • Autoreplay. Replayed runs ping when they finally succeed, which shows up as a recovery.
  • Flowhush periods are intervals, not schedules. A business-hours-only Zap will look late overnight unless the period covers the overnight gap.

The same setup in n8n or a script

If some of your automations live outside Zapier, the same monitor pattern applies. In n8n, add an HTTP Request node as the last step:

Method: POST
URL: https://flowhush.com/p/YOUR-MONITOR-UUID
Send Body: on
Body Content Type: JSON
Specify Body: Using JSON
JSON: {{ JSON.stringify($json) }}
Settings → Execute Once: on
Settings → Retry On Fail: on
Settings → On Error: Continue

From a script or a scheduled job, use curl with a short timeout so the ping can't hang the job: curl -fsS -m 10 --retry 3 https://flowhush.com/p/YOUR-MONITOR-UUID.

Summary

Keep Zapier's error emails on. They're the fastest signal for runs that error. Add a heartbeat step for the failure Zapier can't report: the Zap that stopped running. If you use error handlers, give them a /fail ping so handled errors aren't silent.

Flowhush's Free plan covers 5 Zaps (or any other workflows) with email, Slack, Discord or Telegram alerts.

Monitor your first workflows free

The Free plan includes 5 heartbeat monitors with alerts to email, Slack, Discord or Telegram. No credit card required.

Start free — 5 monitors   See setup snippets