Your agent said it worked.
Something should check.

How you wire it in

A URL for the first question. A few lines of code for the second.

https://silentfailapp.com/api/ping/YOUR_MONITOR_TOKEN

pip install silentfail-sdk

from silentfail import Supervisor, Claim

supervisor = Supervisor.start(
    api_key=os.environ["SILENTFAIL_API_KEY"],
    monitor_id="cmu0480ko0007ssi0f1zz7d60",
)

# ... your job runs, and files invoice INV-4471 ...

supervisor.check(
    claim=Claim(status="success", reference="INV-4471"),
    evidence=lambda: ledger.find(invoice_no="INV-4471"),
)

Zapier app·n8n node·API reference

How supervision works

You write the rule in English. A person approves it. Then every run is checked against it.

No model decides whether you are woken up. A model writes the checks once, at setup, and you read them before anything is judged by them. An alert names the rule, the version you approved and the check that failed. See what it catches.

Three questions, three rungs

01 · Deadline

Did it run?

The job reports in when it finishes, and if the report does not arrive in time you get an email. Every monitoring tool does this and so do we. For most scheduled work it is the whole answer, and it is what most people come here for.

Every monitor, from the free plan up.

02 · Drift

Did it run when it normally does?

A nightly job that has quietly moved to 04:00. A five-minute job now taking twenty. Nothing is down, so nothing alerts, and the interval you typed in six months ago stopped describing this workflow a while ago.

Automatic mode learns the shape from the monitor's own history.

03 · Supervision

Did the work actually happen?

The run finished. It reported success. The invoice went in with the wrong total, or the account was created without its permissions, or the record was never written at all. There is no error to catch and nothing goes red.

Supervision judges each run against a rule you approved.

Zapier and n8n

Pick the monitor by name, not by pasting a URL.

A ping URL works in anything that can make an HTTP request and needs no account, no headers and no payload. If you live in Zapier or n8n there is a proper app for each, and it already knows what your monitors are called.

A ping URL does one thing to one monitor. An API key can list and ping everything on your account, which is what buys the dropdown of real names. Both are written up in the API reference.

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

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. 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. There is no OAuth and we hold no credential of yours for any other service. The one place a connection exists is our Zapier app, and it points the other way: an API key of ours that can list the monitors on your Silent Fail account and ping them. It grants nothing on the Zapier side and cannot read a workflow. Use a ping URL instead and there is no connection at all.

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.

What is supervisor mode, and does a model decide whether I get alerted?

No model ever decides. You describe what a successful run leaves behind in plain English, and a model translates that into a small set of structured checks, once, at setup. You read those checks in the same plain English and approve them before anything is judged by them. From then on every run is evaluated by deterministic code against the version you approved, so the same input always gives the same verdict and an alert can name the rule and the version that fired it. The model is a translator at setup time and is never consulted again.

Does supervision send you my data?

No. Supervision runs inside your own process through the SDK, so your code gathers the evidence and the checks run next to it. What reaches us is a verdict and a reason token: that check three failed because a value did not match. Not the value, not the invoice number, not the record. The format we accept has no field a customer value would fit in, and a report carrying one is refused rather than quietly stored. If you want a comparison without either side holding the thing being compared, rules can match on fingerprints.

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.