Ory Kratos self‑service login error alerts produce excessive noise during brute‑force attempts

Goal: configure Ory Kratos self‑service login alerts so that genuine credential‑stuffing attacks trigger notifications while routine low‑volume errors do not flood the alert channel.

Current metrics expose kratos_selfservice_flow_error_total labeled by flow type and strategy, but each failed attempt increments the counter individually. Operators must decide whether to rely on threshold‑based rules with a for: duration, apply Alertmanager inhibition, or request built‑in collapsing of consecutive errors from the same client IP.

Uncertainty remains around the best label set for inhibition rules and whether version‑specific metric changes will break existing rules.

Should Ory Kratos add an automatic collapsing mechanism for repeated errors from the same IP?
What label combination (e.g., flow_type, strategy, client_ip) should Alertmanager use for effective inhibition without silencing distinct attack vectors?
Is a static error‑per‑minute threshold sufficient, or should teams adopt histogram‑based latency metrics for more nuanced detection?