Alertmanager
prometheus.io- Category
- Developer Tools
- Rank
- No. 836Tools index
- Pricing
- Open Source
- Type
- TOOL
- Use case
- Deployment & Operations
- Builder
- prometheus
- GitHub
- 8.7k stars
- Latest release
- v0.34.2
- Date
About
Alert routing & silencing. The Prometheus project's alert handler — deduplicates, groups, and routes alerts to email, Slack, PagerDuty, and more, with silences and inhibition.
What it does
Alertmanager sits between a monitoring system and the people who respond to it. Client applications, most often Prometheus itself, push alerts to its HTTP API; it folds near-duplicate firings from the same incident into a single notification, decides which channel each group reaches through a label-matching tree, can temporarily mute alerts on request, and can hold back a whole class of lower-priority alerts while a more serious, related one is already firing. A companion command-line client lets operators query active alerts and manage those mutes without opening the web interface.
Why it's ranked here
Alertmanager is the default choice here, not one alternative among several: it is the alert handler the rest of the Prometheus ecosystem is built to talk to, released under the Apache license, with a high-availability design that states its own tradeoff plainly rather than hiding it, choosing a duplicate notification over a missed page during a network split. The codebase backs that up with real engineering care: an internal lifecycle type with an explicit teardown stack, built to run both as a standalone binary and embedded inside tests.
What's good
The routing tree does real work: nodes can attach arbitrary labels that flow into notification templates, and matching rules inherit down the tree so a team-wide default only needs to change in one place. Templates run on the standard Go template engine with built-in helpers for JSON encoding, timezone conversion, and duration formatting, so receivers get well-formed messages without a separate templating layer bolted on. Clustering uses a gossip protocol with no leader election, so any surviving instance keeps serving alert state and history if the others go down.
Tradeoffs
The high-availability design is explicit about what it does not guarantee: peers replicate state over a best-effort, eventually-consistent gossip layer with no quorum or leader, so a network split during an incident can produce the same page twice rather than risk losing it, and that tradeoff cannot be switched off. The routing configuration format still carries an older matching syntax alongside the newer one meant to replace it, so real configuration files often mix both styles. Outbound email notifications default to requiring an encrypted connection, worth checking before pointing the tool at an internal mail relay that does not support one.
How to use it well
Point it at whatever already emits alerts over its HTTP API, most naturally a Prometheus server, and spend the setup time on the routing tree rather than the receiver list: get grouping and inheritance right first, then layer in rules that quiet the noise a major outage produces. Running more than one instance is worth doing early, since the cluster flags are meant to be set from the start rather than bolted on later, and every instance should get traffic directly rather than sitting behind a load balancer. It is a router and notifier only; it does not evaluate metrics or generate alerts itself.
Technical notes+
Written in Go (module github.com/prometheus/alertmanager per go.mod) and built around a companion amtool CLI documented in README.md. cmd/alertmanager/main.go wires flags via kingpin and hands off to the app package; app/app.go implements an embeddable App type with New/Start/Stop and a LIFO cleanup stack registered through onStop, explicitly built so tests and other binaries can run Alertmanager in-process instead of shelling out to the compiled binary. The HTTP API (v2) is generated by go-swagger from an OpenAPI spec, visible in the generated boilerplate of api/v2/restapi/server.go, which also exposes unix-socket, HTTP, and TLS listener configuration. Config reload behavior (SIGHUP or POST /-/reload) and the global receiver settings (SMTP, Slack, PagerDuty, OpsGenie, VictorOps, WeChat, Telegram, Webex, Mattermost, RocketChat) are documented in docs/configuration.md; core alerting concepts (grouping, inhibition, silences, per-alertname limits) are in docs/alertmanager.md; the gossip-based HA design (Hashicorp memberlist, peer-position-based notification stagger, notification-log dedup, fail-open on partition) is in docs/high_availability.md; and the Go text/template notification system, including its Data/Alert/KV structures and built-in functions, is in docs/notifications.md.
Observed
- License
- Apache License 2.0, per license headers in source files.
- Language
- Implemented in Go; module path github.com/prometheus/alertmanager.
- Interfaces
- Ships a companion CLI, amtool, alongside the alertmanager binary.
- Interfaces
- Interfaces: HTTP API (v2, OpenAPI/go-swagger generated), YAML configuration file, web UI for silences, and a CLI.
- Packaging
- Distributed as precompiled binaries and Docker images, in addition to building from source.
- Config reload
- Configuration can be reloaded without a restart, via SIGHUP or an HTTP POST to /-/reload.
- Clustering
- High-availability clustering uses a gossip protocol (Hashicorp memberlist) with no leader election or quorum requirement.
- Templating
- Notification templates use Go's text/template system with a documented set of built-in functions.
- SMTP
- SMTP notifications require an encrypted connection to the mail server by default.
Read from README.md, go.mod, cmd/alertmanager/main.go, app/app.go, api/v2/restapi/server.go, docs/configuration.md, docs/alertmanager.md, docs/high_availability.md, docs/notifications.md.
Tags
Tech Stack
Media

Comments (0)
No comments yet
Editorially curated, with community endorsements as a secondary signal. Corrections welcome.