Alertmanager Config Generator
Generate production-ready alertmanager.yml with receivers, routing trees, inhibition rules, silences, and templates for Slack, PagerDuty, Teams, and email.
Global Configuration
1global:2 resolve_timeout: 5m3 smtp_smarthost: 'smtp.example.com:587'4 smtp_from: 'alertmanager@example.com'5 smtp_auth_username: 'alertmanager@example.com'6 smtp_auth_password: 'password'7 smtp_require_tls: true89route:10 receiver: 'slack-general'11 group_by: ['alertname', 'cluster', 'service']12 group_wait: 30s13 group_interval: 5m14 repeat_interval: 4h15 routes:16 -17 receiver: 'pagerduty-critical'18 group_by: ['alertname', 'cluster']19 group_wait: 30s20 group_interval: 5m21 repeat_interval: 4h22 matchers:23 - severity='critical'24 -25 receiver: 'slack-warning'26 group_by: ['alertname', 'service']27 group_wait: 30s28 group_interval: 5m29 repeat_interval: 4h30 matchers:31 - severity='warning'3233receivers:34 - name: 'slack-receiver'35 slack_configs:36 - api_url: 'https://hooks.slack.com/services/...'37 channel: '#alerts'38 title: '{{ .GroupLabels.alertname }}'39 text: '{{ range .Alerts }}{{ .Annotations.description }}{{ end }}'40 - name: 'pagerduty-receiver'41 pagerduty_configs:42 - service_key: 'your-pagerduty-integration-key'43 severity: 'critical'44 description: '{{ .GroupLabels.alertname }}'4546inhibit_rules:47 - source_matchers:48 - severity='critical'49 target_matchers:50 - severity='warning'51 equal: ['alertname', 'instance']5253templates:54 - '/etc/alertmanager/templates/*.tmpl'5556# Template: /etc/alertmanager/templates/slack.tmpl57{{ define "slack.custom.title" }}58[{{ .Status | toUpper }}{{ if eq .Status "firing" }}:{{ .Alerts.Firing | len }}{{ end }}] {{ .GroupLabels.SortedPairs.Values | join " | " }}59{{ end }}6061{{ define "slack.custom.message" }}62{{ range .Alerts }}63*Alert:* {{ .Labels.alertname }}{{ if .Labels.severity }} - `{{ .Labels.severity }}`{{ end }}64*Description:* {{ .Annotations.description }}65*Details:*66{{ range .Labels.SortedPairs }} • *{{ .Name }}:* `{{ .Value }}`67{{ end }}{{ end }}68{{ end }}
What is this tool?
The Alertmanager Configuration Generator helps you build production-grade alertmanager.yml files for routing, grouping, and delivering Prometheus alerts. Alertmanager handles deduplication, grouping, inhibition, and silencing of alerts before sending notifications to email, Slack, PagerDuty, Microsoft Teams, and more.
Alertmanager sits between your Prometheus server and your notification channels. When Prometheus fires alerts, Alertmanager receives them, groups related alerts together, applies inhibition rules to suppress lower-severity alerts, checks for active silences, and routes notifications to the correct receivers based on your routing tree configuration.
How to Use This Tool
1. Global Configuration: Define SMTP settings, HTTP client options, and resolve_timeout that applies to all alert resolutions. These globals are inherited by all receivers unless overridden.
2. Route Tree: The routing tree determines which receiver handles each alert. The root route defines defaults, and child routes use matchers to split alerts by severity, team, service, or any label. Routes can be nested to create complex routing hierarchies.
3. Receivers: Each receiver defines one or more notification integrations. Configure Slack webhooks, PagerDuty service keys, email SMTP settings, Teams webhook URLs, or custom webhook endpoints. Multiple receivers can send the same alert to different channels.
4. Inhibition Rules: Inhibition rules suppress notifications for lower-severity alerts when a higher-severity alert is firing. For example, suppress warning alerts when a critical alert for the same service is already active, reducing alert noise during incidents.
5. Silences: Temporarily suppress notifications for specific alerts during maintenance windows or known outages. Silences use label matchers and have start/end timestamps with an optional comment and creator.
6. Templates: Customize notification text using Go template syntax. Reference alert labels, annotations, and group information to create informative, actionable notifications.
Best Practices
- Use hierarchical routing with matchers to direct alerts to the appropriate team and severity level instead of a single catch-all receiver.
- Configure group_by with meaningful labels like alertname, cluster, and service to reduce notification noise during cascading failures.
- Set repeat_interval to at least 4 hours to avoid alert fatigue from repeated notifications on persistent issues.
- Use inhibit_rules to suppress lower-severity alerts when critical alerts fire, reducing noise during incidents.
- Deploy Alertmanager in a cluster of 3 or more instances with mesh gossip protocol for high availability and automatic deduplication.
- Use templates to include runbook links and actionable context in every notification, reducing mean time to resolution.
- Store SMTP credentials and API keys in environment variables or secret managers, never in the alertmanager.yml file.
- Test your routing tree with amtool before deploying to production to catch misconfigurations early.
Common Mistakes
- Forgetting to set repeat_interval on the root route, causing alerts to re-notify every minute and creating alert fatigue.
- Using match instead of matchers in route configuration, which causes silent routing failures in newer Alertmanager versions.
- Not configuring group_wait, leading to individual alert notifications instead of grouped batches during cascading failures.
- Hardcoding API keys and passwords directly in alertmanager.yml instead of using environment variable substitution.
- Deploying a single Alertmanager instance without clustering, which creates a single point of failure for all alerting.
Security Notes
- Never commit alertmanager.yml with plaintext passwords or API keys. Use environment variable substitution with $SMTP_PASSWORD syntax.
- Enable TLS on the Alertmanager web UI and API endpoints when exposed to the network.
- Use basic authentication or reverse proxy auth to protect the Alertmanager API from unauthorized silence creation.
- Restrict network access to Alertmanager receivers (Slack webhooks, PagerDuty endpoints) using firewall rules.
- Run Alertmanager as a non-root user with read-only filesystem mounts where possible.
Production Tips
- Deploy Alertmanager in a 3-node cluster using the --cluster.peer flag for gossip-based membership and automatic deduplication.
- Use a dedicated Prometheus rule file to route alerts to Alertmanager with proper labels for routing decisions.
- Monitor Alertmanager itself with Prometheus metrics: alertmanager_notifications_total, alertmanager_cluster_members, and queue sizes.
- Configure external labels on Prometheus to enable cross-datacenter alert routing through a global Alertmanager federation.
- Use amtool to validate configuration, check routing trees, and manage silences from the command line.
- Set up a dead-man's switch alert (always firing) to verify your entire alerting pipeline is working end-to-end.
Frequently Asked Questions
What is Alertmanager and how does it relate to Prometheus?
How does the Alertmanager routing tree work?
What are Alertmanager inhibition rules?
How do I deploy Alertmanager in high availability?
Can I customize Alertmanager notification templates?
How do I create silences in Alertmanager?
What is the difference between group_wait and group_interval?
How does Alertmanager handle HA deduplication?
How We Keep Your Configs Safe & Valid
Built-in Error Checking
Every file is checked against official rules. We catch missing fields and bad syntax. YAML indentation errors are flagged right away. Kubernetes, Terraform, and Docker specs are all covered. API versions and labels are verified too. You get valid output every time you generate.
100% Private & Local
All tools run in your browser only. Your API keys never leave your machine. We do not use any tracking scripts. No data is sent to any server. Passwords and secrets stay on your device. Crypto operations use the Web Crypto API. Your privacy is fully protected at all times.
Secure Settings by Default
Configs use safe defaults out of the box. Containers run as non-root users. Root filesystems are set to read-only. Dangerous Linux capabilities are dropped. Network policies limit pod-to-pod traffic. TLS 1.3 is enabled for web servers. Security headers are added where needed.
Ready for CI/CD & Git
Output files are ready for your Git repo. Use them with ArgoCD, Flux, or GitHub Actions. Files use clear formatting and comments. Code review is easy for your team. Indentation and key order are consistent. Test in staging before going to production. Every file is clean and well-structured.
Infrastructure as Code
Store configs in Git alongside your code. Terraform modules include typed variables. Backend configs support remote state locking. Outputs work across multiple modules. Ansible playbooks use clear task steps. Chef and Puppet configs are also supported. Every file works with version control tools.
Monitoring & Tracing
Set up Prometheus with auto-discovery rules. Create Grafana dashboards with template variables. Add alerting rules with severity labels. Use OpenTelemetry for trace collection. Forward logs to Loki or Elasticsearch. Connect to Jaeger or Tempo for tracing. Monitor metrics, logs, and traces together.
Container & Docker Safety
Dockerfiles use multi-stage builds for small images. Base images are pinned to exact versions. Dev files are excluded from final images. Health checks are added for orchestrator use. Containers switch to non-root users. Docker Compose uses named volumes and networks. Resource limits are set in deploy configs.
Multiple Output Formats
Export as YAML, JSON, HCL, or TOML. Kubernetes uses YAML with proper separators. Terraform uses HCL with correct escaping. JSON output has consistent indentation. Copy to clipboard with one click. Preview output with syntax highlighting. Line numbers help you review quickly.