If you run anything business-critical through Zapier webhooks, you've probably had the moment: a zap that looked fine in the dashboard, that had been quietly not firing for two days. Here's a simple health check you can build yourself in about twenty minutes, and the point at which it stops being enough.
The basic pattern: a dead man's switch
The core idea is old and reliable. Instead of asking "did my zap run correctly," ask "has my zap checked in recently."
- Write a heartbeat. At the end of your critical zap, add a final step that writes a timestamp somewhere durable: a row in a Google Sheet, a key in Airtable, a record in your own database. It doesn't matter what the zap actually did upstream; this step just proves the zap reached its last action.
- Poll the heartbeat. A second, independent zap (or a simple cron job, or an n8n schedule trigger, whatever you already have running) checks that timestamp every 15 or 30 minutes.
- Alert on staleness, not on error. If the timestamp hasn't moved in longer than your zap's expected interval, say double the normal gap, fire a Slack message or an email. You're not catching an error. You're catching silence.
This catches the most obvious failure mode: a zap that stops triggering entirely, because a connected account's token expired, a filter got misconfigured, or the upstream service changed its webhook payload shape.
Where it breaks down
The dead man's switch only tells you the zap is still executing. It says nothing about whether each individual run did anything useful. That's the gap that actually causes the most damage, because it's invisible even to this fix.
Concretely: your webhook-triggered zap runs at 9am, 10am, 11am, every hour, checking in on schedule. But three of those runs processed zero records because the incoming payload's field names changed slightly and your filter step silently excluded everything. The heartbeat updates right on schedule. The zap is "healthy." It's also doing nothing.
Catching that requires a different kind of check: not "did the zap run," but "did the zap's output match what it normally produces." That means tracking volume per run, not just liveness, and comparing it against a baseline instead of a fixed rule, since a genuinely quiet Sunday and a broken filter look identical from a single data point.
When the DIY version stops scaling
The heartbeat-and-poll pattern works fine for one or two critical zaps. It gets unwieldy fast once you're running a dozen workflows across Zapier, Make, and n8n, each needing its own heartbeat step, its own polling job, its own alerting logic, and its own baseline for what "normal volume" even looks like.
At that point, a tool like OpsVeritas can help. It sits outside your workflows and watches for silent failures at scale: zero-output runs, silent stalls, volume drops against a rolling baseline, so your team isn't rebuilding health checks in every zap by hand.
