{"id":13509587,"url":"https://github.com/prometheus/alertmanager","last_synced_at":"2025-05-12T18:17:32.961Z","repository":{"id":9546586,"uuid":"11452538","full_name":"prometheus/alertmanager","owner":"prometheus","description":"Prometheus Alertmanager","archived":false,"fork":false,"pushed_at":"2025-05-05T15:03:55.000Z","size":43005,"stargazers_count":6979,"open_issues_count":688,"forks_count":2215,"subscribers_count":177,"default_branch":"main","last_synced_at":"2025-05-12T18:17:14.017Z","etag":null,"topics":["alertmanager","deduplication","email","hacktoberfest","monitoring","notifications","opsgenie","pagerduty","slack"],"latest_commit_sha":null,"homepage":"https://prometheus.io","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/prometheus.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2013-07-16T15:06:31.000Z","updated_at":"2025-05-12T13:32:44.000Z","dependencies_parsed_at":"2023-02-16T13:16:15.455Z","dependency_job_id":"e5af35ba-bfba-489a-b395-929c424b0312","html_url":"https://github.com/prometheus/alertmanager","commit_stats":{"total_commits":2473,"total_committers":376,"mean_commits":6.577127659574468,"dds":0.7788111605337646,"last_synced_commit":"27b6eb7ce02680c84b9a06503edbddc9213f586d"},"previous_names":["prometheus/alert_manager"],"tags_count":79,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/prometheus%2Falertmanager","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/prometheus%2Falertmanager/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/prometheus%2Falertmanager/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/prometheus%2Falertmanager/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/prometheus","download_url":"https://codeload.github.com/prometheus/alertmanager/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":253795162,"owners_count":21965488,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["alertmanager","deduplication","email","hacktoberfest","monitoring","notifications","opsgenie","pagerduty","slack"],"created_at":"2024-08-01T02:01:09.976Z","updated_at":"2025-05-12T18:17:32.940Z","avatar_url":"https://github.com/prometheus.png","language":"Go","readme":"# Alertmanager [![CircleCI](https://circleci.com/gh/prometheus/alertmanager/tree/main.svg?style=shield)][circleci]\n\n[![Docker Repository on Quay](https://quay.io/repository/prometheus/alertmanager/status \"Docker Repository on Quay\")][quay]\n[![Docker Pulls](https://img.shields.io/docker/pulls/prom/alertmanager.svg?maxAge=604800)][hub]\n\nThe Alertmanager handles alerts sent by client applications such as the Prometheus server. It takes care of deduplicating, grouping, and routing them to the correct [receiver integrations](https://prometheus.io/docs/alerting/latest/configuration/#receiver) such as email, PagerDuty, OpsGenie, or many other [mechanisms](https://prometheus.io/docs/operating/integrations/#alertmanager-webhook-receiver) thanks to the webhook receiver. It also takes care of silencing and inhibition of alerts.\n\n* [Documentation](http://prometheus.io/docs/alerting/alertmanager/)\n\n## Install\n\nThere are various ways of installing Alertmanager.\n\n### Precompiled binaries\n\nPrecompiled binaries for released versions are available in the\n[*download* section](https://prometheus.io/download/)\non [prometheus.io](https://prometheus.io). Using the latest production release binary\nis the recommended way of installing Alertmanager.\n\n### Docker images\n\nDocker images are available on [Quay.io](https://quay.io/repository/prometheus/alertmanager) or [Docker Hub](https://hub.docker.com/r/prom/alertmanager/).\n\nYou can launch an Alertmanager container for trying it out with\n\n    $ docker run --name alertmanager -d -p 127.0.0.1:9093:9093 quay.io/prometheus/alertmanager\n\nAlertmanager will now be reachable at http://localhost:9093/.\n\n### Compiling the binary\n\nYou can either `go get` it:\n\n```\n$ GO15VENDOREXPERIMENT=1 go get github.com/prometheus/alertmanager/cmd/...\n# cd $GOPATH/src/github.com/prometheus/alertmanager\n$ alertmanager --config.file=\u003cyour_file\u003e\n```\n\nOr clone the repository and build manually:\n\n```\n$ mkdir -p $GOPATH/src/github.com/prometheus\n$ cd $GOPATH/src/github.com/prometheus\n$ git clone https://github.com/prometheus/alertmanager.git\n$ cd alertmanager\n$ make build\n$ ./alertmanager --config.file=\u003cyour_file\u003e\n```\n\nYou can also build just one of the binaries in this repo by passing a name to the build function:\n```\n$ make build BINARIES=amtool\n```\n\n## Example\n\nThis is an example configuration that should cover most relevant aspects of the new YAML configuration format. The full documentation of the configuration can be found [here](https://prometheus.io/docs/alerting/configuration/).\n\n```yaml\nglobal:\n  # The smarthost and SMTP sender used for mail notifications.\n  smtp_smarthost: 'localhost:25'\n  smtp_from: 'alertmanager@example.org'\n\n# The root route on which each incoming alert enters.\nroute:\n  # The root route must not have any matchers as it is the entry point for\n  # all alerts. It needs to have a receiver configured so alerts that do not\n  # match any of the sub-routes are sent to someone.\n  receiver: 'team-X-mails'\n\n  # The labels by which incoming alerts are grouped together. For example,\n  # multiple alerts coming in for cluster=A and alertname=LatencyHigh would\n  # be batched into a single group.\n  #\n  # To aggregate by all possible labels use '...' as the sole label name.\n  # This effectively disables aggregation entirely, passing through all\n  # alerts as-is. This is unlikely to be what you want, unless you have\n  # a very low alert volume or your upstream notification system performs\n  # its own grouping. Example: group_by: [...]\n  group_by: ['alertname', 'cluster']\n\n  # When a new group of alerts is created by an incoming alert, wait at\n  # least 'group_wait' to send the initial notification.\n  # This way ensures that you get multiple alerts for the same group that start\n  # firing shortly after another are batched together on the first\n  # notification.\n  group_wait: 30s\n\n  # When the first notification was sent, wait 'group_interval' to send a batch\n  # of new alerts that started firing for that group.\n  group_interval: 5m\n\n  # If an alert has successfully been sent, wait 'repeat_interval' to\n  # resend them.\n  repeat_interval: 3h\n\n  # All the above attributes are inherited by all child routes and can\n  # overwritten on each.\n\n  # The child route trees.\n  routes:\n  # This route performs a regular expression match on alert labels to\n  # catch alerts that are related to a list of services.\n  - matchers:\n    - service=~\"^(foo1|foo2|baz)$\"\n    receiver: team-X-mails\n\n    # The service has a sub-route for critical alerts, any alerts\n    # that do not match, i.e. severity != critical, fall-back to the\n    # parent node and are sent to 'team-X-mails'\n    routes:\n    - matchers:\n      - severity=\"critical\"\n      receiver: team-X-pager\n\n  - matchers:\n    - service=\"files\"\n    receiver: team-Y-mails\n\n    routes:\n    - matchers:\n      - severity=\"critical\"\n      receiver: team-Y-pager\n\n  # This route handles all alerts coming from a database service. If there's\n  # no team to handle it, it defaults to the DB team.\n  - matchers:\n    - service=\"database\"\n\n    receiver: team-DB-pager\n    # Also group alerts by affected database.\n    group_by: [alertname, cluster, database]\n\n    routes:\n    - matchers:\n      - owner=\"team-X\"\n      receiver: team-X-pager\n\n    - matchers:\n      - owner=\"team-Y\"\n      receiver: team-Y-pager\n\n\n# Inhibition rules allow to mute a set of alerts given that another alert is\n# firing.\n# We use this to mute any warning-level notifications if the same alert is\n# already critical.\ninhibit_rules:\n- source_matchers:\n    - severity=\"critical\"\n  target_matchers:\n    - severity=\"warning\"\n  # Apply inhibition if the alertname is the same.\n  # CAUTION: \n  #   If all label names listed in `equal` are missing \n  #   from both the source and target alerts,\n  #   the inhibition rule will apply!\n  equal: ['alertname']\n\n\nreceivers:\n- name: 'team-X-mails'\n  email_configs:\n  - to: 'team-X+alerts@example.org, team-Y+alerts@example.org'\n\n- name: 'team-X-pager'\n  email_configs:\n  - to: 'team-X+alerts-critical@example.org'\n  pagerduty_configs:\n  - routing_key: \u003cteam-X-key\u003e\n\n- name: 'team-Y-mails'\n  email_configs:\n  - to: 'team-Y+alerts@example.org'\n\n- name: 'team-Y-pager'\n  pagerduty_configs:\n  - routing_key: \u003cteam-Y-key\u003e\n\n- name: 'team-DB-pager'\n  pagerduty_configs:\n  - routing_key: \u003cteam-DB-key\u003e\n```\n\n## API\n\nThe current Alertmanager API is version 2. This API is fully generated via the\n[OpenAPI project](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md)\nand [Go Swagger](https://github.com/go-swagger/go-swagger/) with the exception\nof the HTTP handlers themselves. The API specification can be found in\n[api/v2/openapi.yaml](api/v2/openapi.yaml). A HTML rendered version can be\naccessed [here](http://petstore.swagger.io/?url=https://raw.githubusercontent.com/prometheus/alertmanager/main/api/v2/openapi.yaml).\nClients can be easily generated via any OpenAPI generator for all major languages.\n\nAPIv2 is accessed via the `/api/v2` prefix. APIv1 was deprecated in `0.16.0` and is removed as of version `0.27.0`.\nThe v2 `/status` endpoint would be `/api/v2/status`. If `--web.route-prefix` is set then API routes are\nprefixed with that as well, so `--web.route-prefix=/alertmanager/` would\nrelate to `/alertmanager/api/v2/status`.\n\n## amtool\n\n`amtool` is a cli tool for interacting with the Alertmanager API. It is bundled with all releases of Alertmanager.\n\n### Install\n\nAlternatively you can install with:\n```\n$ go install github.com/prometheus/alertmanager/cmd/amtool@latest\n```\n\n### Examples\n\nView all currently firing alerts:\n```\n$ amtool alert\nAlertname        Starts At                Summary\nTest_Alert       2017-08-02 18:30:18 UTC  This is a testing alert!\nTest_Alert       2017-08-02 18:30:18 UTC  This is a testing alert!\nCheck_Foo_Fails  2017-08-02 18:30:18 UTC  This is a testing alert!\nCheck_Foo_Fails  2017-08-02 18:30:18 UTC  This is a testing alert!\n```\n\nView all currently firing alerts with extended output:\n```\n$ amtool -o extended alert\nLabels                                        Annotations                                                    Starts At                Ends At                  Generator URL\nalertname=\"Test_Alert\" instance=\"node0\"       link=\"https://example.com\" summary=\"This is a testing alert!\"  2017-08-02 18:31:24 UTC  0001-01-01 00:00:00 UTC  http://my.testing.script.local\nalertname=\"Test_Alert\" instance=\"node1\"       link=\"https://example.com\" summary=\"This is a testing alert!\"  2017-08-02 18:31:24 UTC  0001-01-01 00:00:00 UTC  http://my.testing.script.local\nalertname=\"Check_Foo_Fails\" instance=\"node0\"  link=\"https://example.com\" summary=\"This is a testing alert!\"  2017-08-02 18:31:24 UTC  0001-01-01 00:00:00 UTC  http://my.testing.script.local\nalertname=\"Check_Foo_Fails\" instance=\"node1\"  link=\"https://example.com\" summary=\"This is a testing alert!\"  2017-08-02 18:31:24 UTC  0001-01-01 00:00:00 UTC  http://my.testing.script.local\n```\n\nIn addition to viewing alerts, you can use the rich query syntax provided by Alertmanager:\n```\n$ amtool -o extended alert query alertname=\"Test_Alert\"\nLabels                                   Annotations                                                    Starts At                Ends At                  Generator URL\nalertname=\"Test_Alert\" instance=\"node0\"  link=\"https://example.com\" summary=\"This is a testing alert!\"  2017-08-02 18:31:24 UTC  0001-01-01 00:00:00 UTC  http://my.testing.script.local\nalertname=\"Test_Alert\" instance=\"node1\"  link=\"https://example.com\" summary=\"This is a testing alert!\"  2017-08-02 18:31:24 UTC  0001-01-01 00:00:00 UTC  http://my.testing.script.local\n\n$ amtool -o extended alert query instance=~\".+1\"\nLabels                                        Annotations                                                    Starts At                Ends At                  Generator URL\nalertname=\"Test_Alert\" instance=\"node1\"       link=\"https://example.com\" summary=\"This is a testing alert!\"  2017-08-02 18:31:24 UTC  0001-01-01 00:00:00 UTC  http://my.testing.script.local\nalertname=\"Check_Foo_Fails\" instance=\"node1\"  link=\"https://example.com\" summary=\"This is a testing alert!\"  2017-08-02 18:31:24 UTC  0001-01-01 00:00:00 UTC  http://my.testing.script.local\n\n$ amtool -o extended alert query alertname=~\"Test.*\" instance=~\".+1\"\nLabels                                   Annotations                                                    Starts At                Ends At                  Generator URL\nalertname=\"Test_Alert\" instance=\"node1\"  link=\"https://example.com\" summary=\"This is a testing alert!\"  2017-08-02 18:31:24 UTC  0001-01-01 00:00:00 UTC  http://my.testing.script.local\n```\n\nSilence an alert:\n```\n$ amtool silence add alertname=Test_Alert\nb3ede22e-ca14-4aa0-932c-ca2f3445f926\n\n$ amtool silence add alertname=\"Test_Alert\" instance=~\".+0\"\ne48cb58a-0b17-49ba-b734-3585139b1d25\n```\n\nView silences:\n```\n$ amtool silence query\nID                                    Matchers              Ends At                  Created By  Comment\nb3ede22e-ca14-4aa0-932c-ca2f3445f926  alertname=Test_Alert  2017-08-02 19:54:50 UTC  kellel\n\n$ amtool silence query instance=~\".+0\"\nID                                    Matchers                            Ends At                  Created By  Comment\ne48cb58a-0b17-49ba-b734-3585139b1d25  alertname=Test_Alert instance=~.+0  2017-08-02 22:41:39 UTC  kellel\n```\n\nExpire a silence:\n```\n$ amtool silence expire b3ede22e-ca14-4aa0-932c-ca2f3445f926\n```\n\nExpire all silences matching a query:\n```\n$ amtool silence query instance=~\".+0\"\nID                                    Matchers                            Ends At                  Created By  Comment\ne48cb58a-0b17-49ba-b734-3585139b1d25  alertname=Test_Alert instance=~.+0  2017-08-02 22:41:39 UTC  kellel\n\n$ amtool silence expire $(amtool silence query -q instance=~\".+0\")\n\n$ amtool silence query instance=~\".+0\"\n\n```\n\nExpire all silences:\n```\n$ amtool silence expire $(amtool silence query -q)\n```\n\nTry out how a template works. Let's say you have this in your configuration file:\n```\ntemplates:\n  - '/foo/bar/*.tmpl'\n```\n\nThen you can test out how a template would look like with example by using this command:\n```\namtool template render --template.glob='/foo/bar/*.tmpl' --template.text='{{ template \"slack.default.markdown.v1\" . }}'\n```\n\n### Configuration\n\n`amtool` allows a configuration file to specify some options for convenience. The default configuration file paths are `$HOME/.config/amtool/config.yml` or `/etc/amtool/config.yml`\n\nAn example configuration file might look like the following:\n\n```\n# Define the path that `amtool` can find your `alertmanager` instance\nalertmanager.url: \"http://localhost:9093\"\n\n# Override the default author. (unset defaults to your username)\nauthor: me@example.com\n\n# Force amtool to give you an error if you don't include a comment on a silence\ncomment_required: true\n\n# Set a default output format. (unset defaults to simple)\noutput: extended\n\n# Set a default receiver\nreceiver: team-X-pager\n```\n\n### Routes\n\n`amtool` allows you to visualize the routes of your configuration in form of text tree view.\nAlso you can use it to test the routing by passing it label set of an alert\nand it prints out all receivers the alert would match ordered and separated by `,`.\n(If you use `--verify.receivers` amtool returns error code 1 on mismatch)\n\nExample of usage:\n```\n# View routing tree of remote Alertmanager\n$ amtool config routes --alertmanager.url=http://localhost:9090\n\n# Test if alert matches expected receiver\n$ amtool config routes test --config.file=doc/examples/simple.yml --tree --verify.receivers=team-X-pager service=database owner=team-X\n```\n\n## High Availability\n\nAlertmanager's high availability is in production use at many companies and is enabled by default.\n\n\u003e Important: Both UDP and TCP are needed in alertmanager 0.15 and higher for the cluster to work.\n\u003e  - If you are using a firewall, make sure to whitelist the clustering port for both protocols.\n\u003e  - If you are running in a container, make sure to expose the clustering port for both protocols.\n\nTo create a highly available cluster of the Alertmanager the instances need to\nbe configured to communicate with each other. This is configured using the\n`--cluster.*` flags.\n\n- `--cluster.listen-address` string: cluster listen address (default \"0.0.0.0:9094\"; empty string disables HA mode)\n- `--cluster.advertise-address` string: cluster advertise address\n- `--cluster.peer` value: initial peers (repeat flag for each additional peer)\n- `--cluster.peer-timeout` value: peer timeout period (default \"15s\")\n- `--cluster.gossip-interval` value: cluster message propagation speed\n  (default \"200ms\")\n- `--cluster.pushpull-interval` value: lower values will increase\n  convergence speeds at expense of bandwidth (default \"1m0s\")\n- `--cluster.settle-timeout` value: maximum time to wait for cluster\n  connections to settle before evaluating notifications.\n- `--cluster.tcp-timeout` value: timeout value for tcp connections, reads and writes (default \"10s\")\n- `--cluster.probe-timeout` value: time to wait for ack before marking node unhealthy\n  (default \"500ms\")\n- `--cluster.probe-interval` value: interval between random node probes (default \"1s\")\n- `--cluster.reconnect-interval` value: interval between attempting to reconnect to lost peers (default \"10s\")\n- `--cluster.reconnect-timeout` value: length of time to attempt to reconnect to a lost peer (default: \"6h0m0s\")\n- `--cluster.label` value: the label is an optional string to include on each packet and stream. It uniquely identifies the cluster and prevents cross-communication issues when sending gossip messages (default:\"\")\n\nThe chosen port in the `cluster.listen-address` flag is the port that needs to be\nspecified in the `cluster.peer` flag of the other peers.\n\nThe `cluster.advertise-address` flag is required if the instance doesn't have\nan IP address that is part of [RFC 6890](https://tools.ietf.org/html/rfc6890)\nwith a default route.\n\nTo start a cluster of three peers on your local machine use [`goreman`](https://github.com/mattn/goreman) and the\nProcfile within this repository.\n\n\tgoreman start\n\nTo point your Prometheus 1.4, or later, instance to multiple Alertmanagers, configure them\nin your `prometheus.yml` configuration file, for example:\n\n```yaml\nalerting:\n  alertmanagers:\n  - static_configs:\n    - targets:\n      - alertmanager1:9093\n      - alertmanager2:9093\n      - alertmanager3:9093\n```\n\n\u003e Important: Do not load balance traffic between Prometheus and its Alertmanagers, but instead point Prometheus to a list of all Alertmanagers. The Alertmanager implementation expects all alerts to be sent to all Alertmanagers to ensure high availability.\n\n### Turn off high availability\n\nIf running Alertmanager in high availability mode is not desired, setting `--cluster.listen-address=` prevents Alertmanager from listening to incoming peer requests.\n\n## Contributing\n\nCheck the [Prometheus contributing page](https://github.com/prometheus/prometheus/blob/main/CONTRIBUTING.md).\n\nTo contribute to the user interface, refer to [ui/app/CONTRIBUTING.md](ui/app/CONTRIBUTING.md).\n\n## Architecture\n\n![](doc/arch.svg)\n\n## License\n\nApache License 2.0, see [LICENSE](https://github.com/prometheus/alertmanager/blob/main/LICENSE).\n\n[hub]: https://hub.docker.com/r/prom/alertmanager/\n[circleci]: https://circleci.com/gh/prometheus/alertmanager\n[quay]: https://quay.io/repository/prometheus/alertmanager\n","funding_links":[],"categories":["9. Processing and Analyze and Act","Go","monitoring","Application Recommendation","Repos","APM Monitoring"],"sub_categories":["Alerts","🛠️ DevOps","Alerting"],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fprometheus%2Falertmanager","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fprometheus%2Falertmanager","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fprometheus%2Falertmanager/lists"}