Alert Frequency Calculator
Calculate how many times per day an alert rule fires based on how often its condition is true and the evaluation interval.
Inputs
How many distinct times per day the alert's underlying condition transitions to true (not counting repeats while still true).
How often the alerting rule is evaluated.
Average time the condition remains true once triggered, before resolving (affects repeat firings if not deduplicated).
Minimum time the condition must stay true before the alert actually fires (Prometheus `for:` clause).
Actual Alert Firings per Day
20.0alerts/day
Evaluations While Condition Is True
3
Rule Evaluations per Day
2,880
Step by step
Does condition duration clear the for: threshold?
90s vs. for: 60s
= Yes — fires every time
Actual alert firings per day
20 (all occurrences fire)
= 20.0 firings/day
Rule evaluations per day (evaluation cadence)
86400 ÷ 30s
= 2880 evaluations/day
How it works
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.
Formula
alerts_per_day = active_alerts × firings_per_alert_per_day
- active_alerts
- Number of configured alert rules that fire
- firings_per_alert_per_day
- Average firings per alert rule per day
Frequently Asked Questions
Why doesn't every true condition generate an alert?
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.
How should I choose a `for:` duration?
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.
Does Alertmanager grouping reduce the effective alert count further?
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.
What if my condition flaps rapidly around the threshold?
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.