AlertmanagerFailedReload

Alertmanager tried to load a new configuration file, rejected it, and is still running the previous one.


Severity	critical
Source	Alertmanager’s own `/metrics` (0.25+)
Key metric	`alertmanager_config_last_reload_successful` (1 = last reload worked, 0 = failed)

What it means

Whenever the config file changes and a reload is triggered (SIGHUP, POST /-/reload, or a config-reloader sidecar), Alertmanager parses and validates it. If validation fails, the gauge drops to 0 and the old config stays active. The alert fires when that state persists rather than clearing on the next successful reload.

Nothing is broken yet, which is exactly the danger: the routes, receivers or inhibition rules you just shipped are not live, and the next restart of the pod may fail to start at all because the bad file is still on disk.

Common causes

YAML indentation or type errors (a string where a list is expected, tabs instead of spaces).
A receiver referenced in route that does not exist, or a duplicate receiver name.
Template files listed under templates: that are missing or fail to parse.
Secret files (*_file fields such as api_key_file) that are not mounted in the container.
Deprecated or unknown fields after an upgrade, for example old match/match_re mixed with invalid matchers syntax.
With prometheus-operator, a broken AlertmanagerConfig resource merged into the generated config.

First checks

Confirm which instances are affected:

alertmanager_config_last_reload_successful == 0

Read the actual error from the logs:

kubectl -n monitoring logs <alertmanager-pod> -c alertmanager | grep -i "loading configuration"

Validate the file that is on disk, not the one in your repo:
```
kubectl -n monitoring exec <alertmanager-pod> -c alertmanager -- \
  amtool check-config /etc/alertmanager/config_out/alertmanager.env.yaml
```
Adjust the path to wherever your deployment mounts the config. Locally, amtool check-config alertmanager.yml does the same.
If you use the operator, check the reloader sidecar logs and the status of your AlertmanagerConfig objects.

Fixing it

Correct the error reported by amtool check-config, redeploy, and trigger a reload (curl -X POST http://<alertmanager>:9093/-/reload). Confirm the gauge returns to 1 on every replica. Add amtool check-config to CI so a bad file never reaches the cluster.

AlertmanagerConfigInconsistent: replicas that reloaded and replicas that did not end up with different configs.
AlertmanagerClusterCrashlooping: the same bad file can stop pods from starting after a restart.
AlertmanagerFailedToSendAlerts: receiver fixes you expected to be live may not be.