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?

The pattern that works best for me is to invert it: instead of watching for failures, watch for the absence of success. Every Zap that matters ends with a step that writes a timestamped row to one shared last run table (Zapier Tables or a Sheet, one row per Zap, updated in place). Then a single scheduled Zap runs each morning, reads that table, and flags anything whose last run is older than its own expected interval.

That handles the volume question Troy raised, because the threshold is per Zap instead of global. A nightly billing Zap gets a 26 hour window. A lead form Zap that normally fires a few times a week gets several days. Quiet weekends stop generating false positives, because the expectation is set per automation rather than by overall traffic.

The other half is auth. Most of the silent failures I have run into trace back to an expired connection rather than broken logic, so it helps to keep a short list of the fragile ones (anything OAuth with a short token life) and re-check those on a schedule instead of waiting for the trigger to go quiet.

For the client side, a weekly digest built from that same table covers it: Zap name, last run, run count for the week. It is cheap to build because the data already exists, and it turns is everything still running into something you can answer without logging in.