Feature request: native config auto-reload support, similar to Prometheus `auto-reload-config`

[yosshi825]

Proposal

Alertmanager supports runtime reload via SIGHUP or POST /-/reload, but it does not appear to support automatic reload when the config file is updated on disk.

This is particularly inconvenient in Kubernetes environments where Alertmanager configuration is managed via ConfigMap or Secret. Even when a mounted file is updated automatically, Alertmanager does not pick up the change on its own, so users still need an external reloader sidecar just to detect the file change and call /-/reload.

It would be very helpful if Alertmanager had a native auto-reload mechanism similar to Prometheus --enable-feature=auto-reload-config.

Reference: https://prometheus.io/docs/prometheus/latest/feature_flags/#auto-reload-config

Current behavior

1. Start Alertmanager with a config file:

alertmanager --config.file=/etc/alertmanager/alertmanager.yml --web.listen-address=:9093

2. Update /etc/alertmanager/alertmanager.yml on disk.
3. Alertmanager does not reload the updated config automatically.
4. Manually trigger a reload:

curl -X POST http://localhost:9093/-/reload

5. Only after step 4 is the updated config applied.

Expected behavior

Alertmanager optionally supports automatic reload when --config.file changes on disk, similar to Prometheus --enable-feature=auto-reload-config.

This would be especially useful for Kubernetes deployments where configuration is managed via ConfigMap or Secret and updated through mounted files.

Environment

• Alertmanager version: v0.32.0

[mihir-dixit2k27]

Hi, I'd like to work on this. Before diving in, I wanted to outline my approach and check if it's the right direction.

My plan is to add a --config.auto-reload-interval flag (disabled by default) that, when set, starts a background goroutine polling a SHA256 checksum of the config file. On change, it triggers the existing reload path — the same one used by SIGHUP and POST /-/reload — so no new reload logic would be needed.

I'd go with checksum polling rather than fsnotify since Kubernetes updates ConfigMap/Secret mounts via atomic symlink swaps, which breaks file-level watchers after the first update. This is the same reason Prometheus chose polling for their equivalent feature.

A couple of open questions before I start:

• Would you prefer this as a standalone --config.auto-reload-interval flag or integrated into the existing --enable-feature mechanism?
• Any concerns about the polling approach specifically for Alertmanager's use case?

Happy to adjust based on your feedback @siavashs @yosshi825 . Thanks!

[ultrotter]

@mihir-dixit2k27 sounds good thank you!! I think --config.auto-reload-interval can work since besides enabling it we also set how often to check?

[yosshi825]

@mihir-dixit2k27
Thanks for checking.

I’d prefer a standalone --config.auto-reload-interval flag. Since it takes a duration value, it seems like a better fit than --enable-feature.
I also don’t have concerns about the polling approach for Alertmanager, as long as it reuses the existing reload path.

Thanks for working on this.