An Alertmanager configuration builder that assembles a complete alertmanager.yml from a short
form: global settings, a route tree, receiver definitions for email, Slack and PagerDuty,
and optional inhibition rules. Alertmanager sits downstream of Prometheus and turns raw firing
alerts into grouped, de-duplicated, correctly-routed notifications.
How it works
Alertmanager’s config has four main sections. global holds defaults — the resolve_timeout and,
for email, the SMTP smarthost and from address that every email receiver inherits. The route
block is a tree: the root route names a default receiver and the labels to group_by, plus timing
(group_wait before the first notification, group_interval between batched updates, and
repeat_interval before re-notifying about an unchanged alert). receivers define the integrations
— a Slack receiver carries an api_url webhook and channel; a PagerDuty receiver carries a
routing_key for Events API v2; an email receiver carries a to address. Finally inhibit_rules
mute alerts: a source_match of severity: critical can silence a target_match of
severity: warning when they share labels listed in equal.
This builder maps each form field to the right key and renders correctly-indented YAML you can paste straight into a deployment.
Inhibition example
A classic rule mutes warnings while a critical alert is active for the same target:
inhibit_rules:
- source_match:
severity: critical
target_match:
severity: warning
equal: [alertname, instance]Notes
Run amtool check-config alertmanager.yml before shipping, and keep webhook URLs and PagerDuty keys
out of version control — inject them at deploy time. Grouping is the highest-leverage setting: a tight
group_by plus a sane repeat_interval is the difference between one useful page and a hundred.