Alertmanager Capacity Calculator
Calculate how many alerts Alertmanager can process and route per minute.
About Alertmanager Capacity Calculator
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
Worked example
With the default values below, Alertmanager Capacity Calculator returns Max Sustainable Throughput of 4,000. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Incoming Alertsaccepts 0–1,000,000 alerts/sec
- 15 alerts/sec
- Routing Tree Rulesaccepts 1–10,000 rules
- 25 rules
- Avg. Match Time per Ruleaccepts 0.1–10,000 µs
- 5 µs
- Group-By Label Cardinalityaccepts 1–10,000,000 groups
- 200 groups
Results
- Max Sustainable Throughput
- 4,000 alerts/sec
- Estimated Capacity Utilization
- 0.4%
- Routing Time per Alert
- 0.1250 ms
- Avg. Alerts per Group
- 0.075
Step by step
- 1Routing time per alert: rules × match time= 125.0µs (0.1250ms)
- 2Total routing CPU load per second= 1.88ms of work per second
- 3Max sustainable throughput (50% budget)= 4000 alerts/sec
Assumptions and limits
- The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 4 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
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.