Threshold rules: hysteresis and sustained breach #54

New issue

Closed

opened 2026-10-31 08:12:20 +00:00 by Gilles · 0 comments

Gilles commented

2026-10-31 08:12:20 +00:00

Owner

A metric oscillating around its threshold flips the report between ok and warn every hour (garion swap_pct vs >= 95: 90-100 % every night, several 1-report warn episodes).

Two optional params on metric_threshold rules, both unset by default (unchanged behaviour):

recover: back to ok only once the value crosses this second limit (e.g. warn >= 95, recover < 85);
for_count: the breach must hold for N consecutive reports of the stream before the level is raised.

Applied the same way in thresholds.apply (report status / badges) and in _on_metric_threshold (events). The metric keeps its raw value and gets a pending marker while a breach isn't confirmed yet.

A metric oscillating around its threshold flips the report between ok and warn every hour (garion `swap_pct` vs `>= 95`: 90-100 % every night, several 1-report warn episodes). Two optional params on `metric_threshold` rules, both unset by default (unchanged behaviour): - `recover`: back to ok only once the value crosses this second limit (e.g. warn >= 95, recover < 85); - `for_count`: the breach must hold for N consecutive reports of the stream before the level is raised. Applied the same way in `thresholds.apply` (report status / badges) and in `_on_metric_threshold` (events). The metric keeps its raw value and gets a pending marker while a breach isn't confirmed yet.

Gilles added the

feature

label

2026-10-31 08:12:20 +00:00

Gilles referenced this issue from a pull request that will close it,

2026-10-31 08:21:19 +00:00

feature: threshold rules with hysteresis and sustained breach #56

Gilles referenced this issue from a commit

2026-10-31 08:21:21 +00:00

feature: threshold rules with hysteresis and sustained breach

Gilles closed this issue

2026-10-31 08:33:35 +00:00