Liveness

The failure every request-driven metric misses is the system that stops producing requests entirely — zero errors, because zero traffic. Liveness is the dead-man’s switch: the only signal that fires on the absence of traffic.

Set an expectation

Set an expectation per system under AI Estate → AI Systems → (a system):

Mode	Meaning
continuous	Should be producing runs steadily
scheduled	Should run within a recurring window
sporadic	Runs irregularly — never silence-alerted
on_demand	Driven by a human — never silence-alerted (the default for assistants)

Five detectors run against it: silence, missed_schedule, volume_collapse, stall and hard_fail_cliff. Findings arrive as ai_system_liveness alerts and surface in usage alerts.

Learned, not guessed

Brutor can learn the cadence from history rather than making you guess: the window is sized from the p95 inter-run gap, not the median, so a system with occasional long gaps is not paged every time one occurs. If there is too little history the API returns confident: false and refuses to accept a learned value.

Three states, kept distinct

Three states are shown distinctly, and the distinction matters: silent (it used to run and has stopped), never run (it has never started), and never checked (nobody has set an expectation). Only the first is an incident.

Related

• The run ledger — the traffic record liveness is computed from
• Autonomy & response — what can fire automatically on a liveness finding
• Health — where liveness lands as one of the five components