Alertmanager Capacity Calculator
Estimate Alertmanager throughput capacity and the processing overhead added by grouping and routing rules.
Inputs
Rate of alerts received from all Prometheus instances.
Number of route matchers Alertmanager evaluates for each alert.
Average time to evaluate one routing rule's label matchers against an alert.
Number of distinct alert groups formed by the `group_by` labels — more groups means more independent notification pipelines.
Max Sustainable Throughput
4,000alerts/sec
Estimated Capacity Utilization
0.4%
Routing Time per Alert
0.1250ms
Avg. Alerts per Group
0.075
Step by step
Routing time per alert: rules × match time
25 × 5µs
= 125.0µs (0.1250ms)
Total routing CPU load per second
15/s × 0.1250ms
= 1.88ms of work per second
Max sustainable throughput (50% budget)
500ms ÷ 0.1250ms
= 4000 alerts/sec
How it works
Every incoming alert is evaluated against Alertmanager's routing tree, costing roughly routing_rules × avg_match_time per alert. Multiplying by incoming alert rate gives total routing CPU load. This calculator estimates a conservative sustainable throughput ceiling by assuming routing overhead should consume no more than half of each second's CPU budget, leaving headroom for grouping, deduplication, silencing and notification dispatch — the other major cost centers in Alertmanager.
Formula
required_instances = ceil(alerts_per_second / alerts_per_second_per_instance)
- alerts_per_second
- Peak alert throughput (alerts/sec)
- alerts_per_second_per_instance
- Processing capacity per Alertmanager instance
Frequently Asked Questions
Does routing rule count matter more than alert volume?
Both matter multiplicatively — total load is alerts_per_second × rules × match_time, so a large routing tree evaluated against high alert volume compounds quickly; simplifying an overly deep routing tree helps as much as reducing alert volume itself.
What else besides routing consumes Alertmanager capacity?
Grouping (batching alerts sharing group_by labels), deduplication against already-firing alerts, silence matching, inhibition rule evaluation, and notification dispatch (webhook/email/Slack calls) all add load beyond pure routing — this calculator only models the routing-match component.
How does group-by cardinality affect notification volume?
Higher group cardinality means more independent notification pipelines, each with its own group_wait/group_interval timers — this generally means more total notifications sent (since each group notifies independently) but each individual notification is smaller/more specific.
Should I run Alertmanager in HA mode for capacity, or just for redundancy?
Alertmanager's clustering (gossip protocol) is primarily for deduplication/HA correctness across replicas, not horizontal scaling of routing throughput — a single well-resourced Alertmanager can typically handle very high alert rates before routing becomes the bottleneck.