Calculate how often alerts fire based on thresholds and metric volatility.
Raw formula: alerts_per_day = conditions_met_per_day / evaluation_interval × 86400 describes evaluation cadence, but real alert firing rate is gated by Prometheus's `for:` clause — a condition must stay true continuously for at least `for:` duration before the alert transitions from Pending to Firing. This calculator applies that gate: conditions that resolve faster than `for:` never actually fire, which is what keeps flapping metrics from generating alert storms.
alerts_per_day = active_alerts × firings_per_alert_per_day
Prometheus's `for:` clause requires the condition to remain continuously true for a minimum duration before transitioning to Firing — brief blips that self-resolve within that window never fire, which is a deliberate anti-flapping mechanism.
Set it long enough to filter out transient noise (a single slow request, a brief GC pause) but short enough that genuine incidents still page promptly — 1-5 minutes is common for latency/error-rate alerts, longer for capacity-trend alerts.
Yes — this calculator estimates rule firings, not notifications sent. Alertmanager's `group_by`, `group_wait`, and `repeat_interval` settings further batch and deduplicate firings into fewer actual notifications to responders.
Rapid flapping around a threshold is exactly what `for:` is meant to dampen — if you're still seeing frequent alerts despite a reasonable `for:` duration, consider adding hysteresis (different thresholds for firing vs. resolving) to the underlying PromQL expression.