Alertmanager route tester — see which receiver an alert hits before it pages anyone.

Paste your route tree (or a full alertmanager.yml — only its route block is read) and a sample alert's labels into this online Alertmanager route tester. It reproduces Alertmanager's routing walk in your browser and shows which receiver or receivers the alert would reach, the exact route-path breadcrumb from the root down to the matched node, whether a continue: true caused multiple receivers to fire, and the effective group_by after inheritance. It is a dry-run of dispatch without sending a single notification, so you can find which receiver an alert matches in Alertmanager before it pages anyone.

amtool config routes test resolves your alertmanager.yml route tree against a set of label matchers and prints the receivers an alert would hit, mirroring how the running Alertmanager dispatches. This page is a browser-based amtool routes test online: it does the same routing-tree walk client-side, so you can test Alertmanager routing without installing amtool or pointing it at a live config. Paste the tree, paste the labels, and read off the matched receivers and path.

Almost always it is route order, an un-anchored regex, or a missing continue. Within a matched route, siblings are evaluated top to bottom and only the first match is taken — so a broad rule placed above a specific one silently shadows it. match_re and =~ patterns are fully anchored, so env=~"staging" never matches staging-eu. Use this Alertmanager route debugger to walk the tree against the exact labels and see which node actually matched, which makes the answer to "why is my Alertmanager alert going to the wrong receiver" obvious.

By default, once an alert matches a route in a sibling list, Alertmanager stops scanning the rest of that list. Setting continue: true on a matched route tells Alertmanager to keep evaluating the later siblings, so the alert can land in more than one receiver — the usual way teams mirror every critical alert to an audit or paging receiver while still routing it to the owning team. As a continue route tester, this tool tags each receiver a continue: true produces so you can see exactly which matches came from falling through.

Yes — but only when continue: true is set on a matched route. Without it, the first matching sibling wins and the scan stops, so an alert reaches exactly one receiver per route list. With continue: true, the alert keeps descending through later siblings and can fan out to several receivers. This Alertmanager continue true routing tester shows every receiver in the order they fire, so you can confirm the fan-out is what you intended.

You do not need a running Alertmanager, and you do not need amtool. This is a free online Alertmanager route tester with no install: everything runs 100% client-side inside your browser tab. Paste your route tree and alert labels to test your Alertmanager routing config and simulate Alertmanager alert routing in the browser. Nothing is uploaded and there is no signup, so you can safely paste internal receiver names and private team labels.

The Prometheus routing tree editor visualises the tree but still leaves you to reason about match vs match_re vs matchers, first-match ordering, and inheritance in your head — so it can look right while an alert routes somewhere else. If the routing tree editor is not matching the routes you expect, use this as an alternative: test Alertmanager matchers against labels online and the tester walks the real semantics and highlights the matched path, rather than just drawing the tree.

Every alert enters the root route, which is the catch-all. Within a matched route, child routes are evaluated top to bottom, and the alert descends into the first child whose matchers all hold — for example the first node that requires a severity="critical" label. It keeps descending through that subtree; if a matched route has no matching child, that route is the terminal match and its receiver fires. The rule people get wrong is order plus first-match: only the first matching sibling is taken unless continue: true is set.