How Firing Actually Works

min_severity: the floor an event watches

An event fires based on a check's confirmed severity — the post-debounce value, the same one the reporting functions show you, not the raw, unsmoothed one. This means an event automatically respects whatever consecutive-failure requirement a check's threshold has configured: if a check needs 3 consecutive breaching runs before its confirmed severity moves off ok (see Debounce in the Adding Your Own Checks book), an event watching that check doesn't fire on run 1 or run 2 either — it only ever sees what debounce actually confirms.

Severities rank, ascending: ok < info < warning < critical (unknown and not_evaluable both rank alongside ok, at the bottom). "Reaches the floor" means at or above that rank — an event with its floor set to warning fires on both a warning and a critical result.

Transition-only, not every qualifying run

This is the single most important rule to internalise: an event fires once when severity crosses into its floor, then stays silent on every subsequent run while the check remains at or above that floor. It fires again only after the check's severity drops back below the floor and later re-breaches.

Concretely, for an event with its floor set to warning, across a sequence of runs:

Run	Confirmed severity	Event fires?	Why
1	ok	No	Below the floor.
2	warning	Yes	Crossed into the floor — this is a transition.
3	warning	No	Still at or above the floor; no transition since run 2.
4	critical	No	Still at or above the floor (critical still satisfies a warning floor) — still no transition.
5	ok	No	Recovered below the floor. Firing doesn't happen on recovery, only on breach.
6	warning	Yes	A new transition — the check dropped below the floor at run 5 and crossed back in at run 6.

There's no "last fired" flag stored anywhere to make this work. Each time the evaluation engine logs a new evaluation for a check, it looks at that check's immediately preceding evaluation and asks two questions per active event: does the current result satisfy the floor, and did the previous result not satisfy it? Both true means fire. This is the same "durable history already is the state" idea the built-in WAL-rate baseline evaluator uses instead of an external state file — see Writing a Custom Evaluator.

A check's very first-ever evaluation is treated as "there was no previous breaching state," so if a brand-new check's first result already satisfies an event's floor, that event fires immediately on that first run.

Multiple events, and why per-event history matters

A check can have any number of events, each with its own independent floor. Firing is computed per event, not per check — a warning-floor event and a critical-floor event on the same check track their own transitions independently. In the table above, if there were also a critical-floor event, it would fire on run 4 (the transition into critical) and stay silent on runs 2 and 3 (never reached critical) — completely independent of the warning event's own run-2 firing.

Events are check-level only

Unlike thresholds (which support both a check-level default and per-suite overrides — see Overriding a Threshold Per Suite), an event has no suite scoping at all — it applies to a check regardless of which suite ran it. If the same check belongs to two suites with different threshold overrides, its confirmed-severity history is whichever suite happened to run most recently, and that's what transition detection compares against — a real, if edge-case, consequence of events being scoped to the check rather than to a specific suite.

Continue to Managing Events.