What does the route block actually control?

route decides how firing alerts are grouped and how often they're (re-)notified: group_by lists the labels alerts are batched by so related alerts arrive in one notification, group_wait is how long to wait for more alerts to join the first batch, group_interval is how long to wait before sending a notification about new alerts added to an existing group, and repeat_interval is how long to wait before re-sending an already-notified alert that's still firing.

Can I add more than one receiver?

Yes, add as many as you need. Each receiver gets its own name and is toggled to exactly one type (Slack, PagerDuty, email, or Teams) with that integration's required fields; the first receiver you add becomes route.receiver, the default every alert falls back to unless you add custom sub-routes afterward.

What are inhibit_rules for?

An inhibit rule suppresses a set of alerts (matched by target_match) when another alert (matched by source_match) is already firing and they share the labels listed in equal, for example suppressing every 'high latency' alert for a node once a 'node down' alert is already firing for it, since the latency alert is just noise at that point.

Does this validate that my Slack/PagerDuty/email fields are correct?

It checks that each receiver type's required fields are filled in (e.g. a Slack receiver needs both an api_url and a channel), but it can't verify a webhook URL is live, a PagerDuty service key is valid, or an SMTP smarthost is reachable, since that requires actually contacting those services.

Alertmanager Config Generator - Build alertmanager.yml

Overview

Introduction

An alertmanager.yml file wires together how alerts get grouped, throttled, and routed to the right notification channel, and the receiver-specific fields for Slack, PagerDuty, email, and Teams are each shaped slightly differently under the hood.

This tool builds that file from a form: set the routing intervals, add a receiver per notification channel you use, and optionally add inhibit rules to quiet down alerts that are redundant once a more severe one is firing.

What Is Alertmanager Config Generator?

A visual builder for alertmanager.yml, Alertmanager's main configuration file, covering the top-level route, any number of receivers (Slack, PagerDuty, email, Teams), and inhibit_rules.

It mirrors Alertmanager's own structure: route decides grouping and timing, receivers decide where notifications go, and inhibit_rules decide when a firing alert should suppress another.

How Alertmanager Config Generator Works

The route block is emitted first with your group_by labels (if any) and the group_wait/group_interval/repeat_interval durations, plus a default receiver pointing at the first receiver you defined.

Each receiver becomes one entry under receivers, with its type-specific config block (slack_configs, pagerduty_configs, email_configs, or msteams_configs) populated from that receiver's fields. If you add inhibit rules, each one's source_match/target_match strings (comma-separated key=value pairs) are parsed into the nested YAML Alertmanager expects, along with an optional equal label list.

When To Use Alertmanager Config Generator

Use it when standing up Alertmanager for the first time and you need a starting alertmanager.yml with real receivers wired to your team's actual Slack channel, PagerDuty service, or on-call email.

It's also useful for quickly adding a new receiver or an inhibit rule to quiet a known-noisy alert pairing without re-deriving Alertmanager's nested YAML shape from memory.

Often used alongside Prometheus Config Generator and OpenTelemetry Collector Config Generator.

Features

Advantages

Covers all four of the most common receiver integrations (Slack, PagerDuty, email, Teams) with each one's specific required fields, instead of a generic webhook-only form.
Automatically sets the default route.receiver to your first defined receiver, so the output is a runnable config rather than a fragment missing the routing pointer.
Parses inhibit rule match fields from a simple comma-separated key=value syntax into Alertmanager's nested source_match/target_match YAML.

Limitations

Only models one flat route with no nested sub-routes (routes:); complex per-team or per-severity routing trees need manual edits after generating.
Doesn't validate that a webhook URL, service key, or SMTP smarthost is actually live or correctly credentialed.
Only supports one receiver config block per receiver type per receiver entry; an integration needing multiple config blocks under one receiver name needs manual merging.

Examples

A Slack receiver with a node-down inhibit rule

Input

route: group_wait 30s, group_interval 5m, repeat_interval 4h; receiver: name "slack-ops", type slack, api_url https://hooks.slack.com/services/T000/B000/XXXX, channel #ops-alerts; inhibit rule: source_match alertname=NodeDown, target_match alertname=HighLatency, equal node

Output

route:
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: "slack-ops"

receivers:
  - name: "slack-ops"
    slack_configs:
      - api_url: "https://hooks.slack.com/services/T000/B000/XXXX"
        channel: "#ops-alerts"

inhibit_rules:
  - source_match:
      alertname: "NodeDown"
    target_match:
      alertname: "HighLatency"
    equal: ["node"]

The default receiver is set automatically, and the inhibit rule suppresses HighLatency alerts on any node where NodeDown is already firing.

Best Practices & Notes

Best Practices

Group alerts by a label that identifies the underlying cause (e.g. alertname, cluster) rather than something highly unique like instance, so related alerts land in one notification instead of flooding the channel.
Add inhibit rules for any alert pair where one is a strict superset of the other's meaning (e.g. NodeDown implies every other alert on that node is noise) to cut real incident noise.
Keep repeat_interval long enough (hours, not minutes) for anything already routed to a human, so an unresolved incident doesn't keep re-paging on top of the original alert.

Developer Notes

The generator is a pure string-building function emitting fixed 2-space YAML with no YAML library dependency; receiver names are validated against /^[a-zA-Z0-9_-]+$/ and inhibit rule match fields are parsed from a 'key=value, key2=value2' string format into individual YAML mapping entries, with the equal list emitted as a YAML flow sequence when provided.

Alertmanager Config Generator Use Cases

Bootstrapping alertmanager.yml for a new Prometheus + Alertmanager deployment
Adding a new on-call notification channel (Slack, PagerDuty, email, or Teams) to an existing setup
Writing an inhibit rule to suppress a known-noisy alert once a more severe related alert is already firing

Common Mistakes

Forgetting that the first receiver you add becomes the default route.receiver, and being surprised later receivers aren't reached without adding sub-routes.
Writing inhibit rule match fields without the key=value shape this tool expects, which causes generation to fail with a clear error rather than emitting malformed YAML.
Setting repeat_interval too short, causing an already-acknowledged, still-firing alert to keep re-notifying on-call.

Tips

Use the Prometheus Config Generator first to make sure the alerting.alertmanagers block in prometheus.yml points at wherever this Alertmanager instance actually runs.
Start with one receiver and one inhibit rule, confirm notifications arrive correctly, then layer on more receivers rather than wiring everything at once.

Alertmanager Config Generator