Dead-man's switch for automations

Get an email when your automation stops running.

n8n workflows, Make scenarios and Zaps fail silently. They stop firing and nobody finds out for three days, usually from an angry customer. Silent Fail is a dead-man's switch: if the ping stops, you hear about it.

The entire integration

curl -fsS https://silentfailapp.com/api/ping/YOUR_MONITOR_TOKEN

01

Create a monitor

Name it, say how often it should run, set a grace period. We default that to twice your interval so day one is not a false-alarm parade.

02

Drop in the ping URL

Add an HTTP request node at the end of your workflow pointing at your unique URL. GET or POST, whichever your tool makes easy.

03

Forget about it

Every ping resets the clock. Miss the window and you get one email. When pings resume you get one all-clear. Never two.

Three states, no ambiguity

Up
Pinged inside its window. Nothing to do.
Down
Missed the deadline. One email sent, and only one.
Awaiting first ping
Created, but the first ping has not landed yet.

Pricing

Free

$0

3 monitors

Enough to feel useful. Too few to run an agency on.

Solo

$9/mo

25 monitors

For one person running a lot of automations.

Pro

$29/mo

Unlimited monitors

Room for an agency running automations across client accounts.

Questions people actually ask

What happens if Silent Fail itself goes down?
Then alerts are not being evaluated, and pretending otherwise would make this whole product dishonest. Every run of the checker is recorded, so the dashboard shows a warning when the last run is more than five minutes old, and the same signal is exposed at /api/health as JSON. Point an external uptime check at that endpoint and you are monitoring the monitor, which is the only arrangement that closes the loop. A monitoring tool that claims it cannot fail is the one you should not trust.
Does this need access to my workflow or its data?
No. There is no OAuth, no platform connection and no read access to anything. Your workflow makes one HTTP request to a URL when it finishes, and that request needs no body, so there is nothing in it for us to read. We record the time it arrived, the HTTP method, the source IP and the user agent, which is what lets you confirm the wiring works. We never see what your automation does or what it moves.
What if my schedule is irregular?
Set the expected interval to the longest gap that is still normal and let the grace period absorb the variance; it defaults to twice the interval, which tolerates a lot. For a job that runs once a day at no fixed time, use a daily schedule with a deadline late enough to cover the spread. Being straight about the limit: if a workflow genuinely runs at unpredictable intervals with no upper bound, a deadline-based check is the wrong tool, because there is no deadline to set.
How many emails will I get for one outage?
Two. One when the deadline passes and one when pings resume. The checker runs every minute while a monitor is down and stays silent for all of those runs after the first: the delivered alert is recorded, and that record is what suppresses the rest. The all-clear clears it, so the next outage can alert again. Ten monitors failing means ten emails, but one monitor failing for a week is still one email.

We are just an HTTP endpoint. Works with n8n, Make, Zapier, cron, or anything that can make a request.

We would like to set optional cookies to understand how the site is used. They are off unless you agree, and the site works exactly the same either way. What this covers

Silent Fail, get an email when your automation stops running