Silent Fail

Frequently looked up

Q1What happens if Silent Fail itself goes down?

The dashboard shows a warning when the last check run is more than five minutes old, and the same signal is exposed at /api/health as JSON. External uptime checks can be pointed at that endpoint to monitor the monitor itself.

Q2What 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. For unpredictable intervals with no upper bound, deadline-based checking is not the right tool.

Q3Does supervision send you my data?

No. Supervision runs inside your own process through the SDK. Only a verdict and a reason token reach Silent Fail: never the actual values, invoice numbers, or records. The format has no field a customer value would fit in.

Q4What 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.

Q5How 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.