Alert with hysteresis, not on every sample

Constraints

1. 1Each series has its own state. One series firing says nothing about another.
2. 2A sample breaches when its value is strictly greater than the threshold.
3. 3An alert fires after breaches_to_fire consecutive breaches, and only when it is not already firing.
4. 4A firing alert clears after oks_to_clear consecutive non-breaching samples, and only when it is firing.
5. 5Either run resets the other's counter. One good sample in the middle of a breach run starts the breach count again from zero.
6. 6Report transitions only. A firing alert that keeps breaching produces no further events.
7. 7Process each series in at order, compared as text, whatever order the samples arrive in.
8. 8Samples with no series or no usable value are ignored. Return the events in order plus the series still firing at the end, sorted.

Worked example

The api series breaches at 09:01, 09:02 and 09:03. With two breaches required it fires at 09:02 — and produces nothing at 09:03, because it is already firing. The current implementation emits an event at all three, which is what turns one incident into a wall of identical pages. At 09:05 the value crosses again for a single sample, with good samples either side. That is a spike, not an incident: the breach counter reaches one, the next good sample resets it to zero, and nobody is woken. The db series is the same shape at the very start of the window. The clear is the mirror image and is the part people leave out. Clearing on the first good sample means a service oscillating around the threshold fires and clears repeatedly, and the resulting noise is why teams end up muting the alert that was supposed to protect them.

What this tests

An explicit state machine with two counters, and the understanding that an alert is a statement about a run of observations rather than about one. Reporting transitions rather than states is the same idea applied to the output.