Best practice for monitoring client Zaps for silent failures (not errors — missing runs)?

Hi ​@zaxxs 

I think the bigger question is this: How do you know when a Zap should have run, unless it runs on a schedule?

e.g. Depending on the business, volume on weekends may be expected to be lower volume than weekday

e.g. Volume on holidays may be expected to be lower than non-holidays

e.g. Volume after business hours may be expected to be lower than during business hours

False positives can be noise vs signal.

You can create your own logging with Zapier Tables & logic with Zaps: 
https://zapier.com/apps/zapier-tables/integrations#triggers-and-actions

The pattern that has worked for me is a heartbeat table. Every client Zap gets one extra final step that upserts a row in a Zapier Table: zap name, client, timestamp of the run, plus a column for expected cadence (hourly, daily, weekly). Then one scheduled watchdog Zap runs each morning, compares last-run against the expected cadence for each row, and only alerts when something is overdue. That answers the noise vs signal problem Troy raised, because the expected interval lives with each zap instead of one global rule, so a weekend-quiet zap just gets a longer window.

Two things worth adding on top: the Zapier Manager app has triggers for Zap turned off and app connection errors, which catches the auto-disable and auth-expiry cases instantly. And since the heartbeat table already exists, a monthly client digest built from it (X runs, 0 missed windows) turns the same data into the health report you mentioned. Clients renew a lot easier when they can see the runs.

Hey ​@zaxxs 👋 Did any of the suggestions here help to point you in the right direction, or are you still looking for help on this?

Hi ​@zaxxs just checking — did any of these suggestions do the trick for you?

A final-step heartbeat still misses the exact failure you are worried about: if the trigger never fires, the heartbeat step never runs. I would use two signals. Keep the per-Zap success timestamp, then add an independent watchdog that knows the expected source cadence or checks a source-side count. For critical flows, run a small synthetic event on a schedule and verify that its correlation ID reaches the destination within an SLA. Alert only when both the expected window is missed and the source actually had activity, which cuts false positives on quiet weekends. The client report can show expected events, observed runs, completed destinations, and the oldest unacknowledged correlation ID. That proves delivery rather than just proving that a Zap was enabled.

Silent failures are the hard ones because Zapier's own alerting 
only fires on errors - a Zap that simply never ran looks identical 
to a quiet day.

Four things that cause them, worth knowing which you're chasing:

1. Trigger dedupe. Zapier tracks which records it has already 
seen. If a record is updated rather than created, or gets deleted 
and recreated with the same ID, the trigger skips it. No error, no 
run.

2. Silent webhook unsubscribe. Some apps drop their webhook 
subscription on reauth, plan change, or admin action. The Zap 
stays on, the app just stops calling it.

3. Filters. A Zap stopped by a Filter is recorded as "filtered", 
not "errored". Perfectly normal - until a mapping change means 
everything gets filtered and nobody notices for a week.

4. Polling gaps. On polling triggers, records created and deleted 
inside one polling window never appear at all.

For monitoring, the two that work in practice:

Dead man's switch. Add a final step to the Zap that pings a 
Healthchecks.io or Cronitor URL on success. Both are free at this 
scale. You tell it "expect a ping every 6 hours" and it alerts you 
when one doesn't arrive. This catches the missing-run case 
directly, which nothing inside Zapier does. One check per client 
Zap, all visible on one dashboard.

Daily reconciliation. Stronger, and worth it for anything 
handling money or bookings. A scheduled Zap counts records created 
in the source since midnight, counts what landed in the 
destination, and alerts if they disagree. It catches partial 
failures too - the 9 of 10 records case that no per-run monitoring 
will ever see.

If you want run-level visibility, log every successful run to a 
Zapier Table or Airtable with the Zap name and timestamp, then run 
a scheduled Zap that flags anything with no entry in its expected 
window. More setup, but it gives you a single view across clients 
rather than checking each Zap's history.

One thing worth doing regardless: for any Zap with a Filter, add a 
path or a fallback that logs when the filter blocks something 
unexpected. That's the failure that hides longest, because the Zap 
genuinely is working - it's just working on nothing.

Which apps are the triggers on? Silent unsubscribes are much more 
common on some than others.