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

Question

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?

Tasadduq Burney · Answer

To reduce alert noise from Ory Kratos self-service login errors, you must move away from individual counter increments and implement rate-based thresholding with Alertmanager inhibition. Because Kratos increments kratos_selfservice_flow_error_total for every failure, a static threshold on the raw counter will always fire during a brute-force attempt.

Strategy for Effective Alerting
Ory Kratos does not currently provide a built-in 'collapsing' mechanism for errors from the same IP. This logic should reside in your observability layer (Prometheus/Alertmanager). Relying on histogram-based latency metrics is ineffective for this use case, as they measure performance rather than the frequency of credential stuffing attempts.

Implementation Steps

Use Rate-Based Queries: Instead of alerting on the total count, calculate the rate of errors over a sliding window. This filters out one-off typos and low-volume noise.
    rate(kratos_selfservice_flow_error_total[5m]) > 5
  
  Apply Duration Requirements: Use the for: clause in your alerting rule to ensure the alert only triggers if the error rate remains high (e.g., for 5-10 minutes), preventing notifications from transient spikes.
  Configure Alertmanager Inhibition: If you have a WAF or a global rate-limiter firing, use inhibition rules to silence Kratos error alerts when a higher-level block is active.

Recommended Label Combinations
To avoid silencing distinct attack vectors, your inhibition rules must be specific. Do not use client_ip as a primary label in Prometheus if you have high cardinality, which can degrade your metrics server.

Label Group
      Purpose

flow_type
      Distishes between login, password reset, and registration failures.

strategy
      Identifies the auth method (e.g., password, webauthn).

alertname
      Used in inhibition to silence 'warning' alerts when 'critical' blocks are active.

Assumptions and Uncertainty
This solution assumes you are using Prometheus and Alertmanager. There is uncertainty regarding potential version-specific label changes in future Kratos releases; you should verify the /metrics endpoint of your specific version to ensure flow_type and strategy labels remain present.

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

1 answer

Strategy for Effective Alerting

Implementation Steps

Recommended Label Combinations

Assumptions and Uncertainty

Your perspective belongs here.

0 question comments

Label Group	Purpose
`flow_type`	Distishes between login, password reset, and registration failures.
`strategy`	Identifies the auth method (e.g., password, webauthn).
`alertname`	Used in inhibition to silence 'warning' alerts when 'critical' blocks are active.