Calculate how many alerts Alertmanager can process and route per minute.
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.
required_instances = ceil(alerts_per_second / alerts_per_second_per_instance)
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.
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.
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.
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.