Skip to main content
The Prometheus Operator exposes an AlertmanagerConfig CRD to register Alertmanager routes and receivers from Kubernetes. This guide shows how to create AlertmanagerConfig objects, ensure Alertmanager discovers them, and how to configure the Helm chart so the Alertmanager picks them up.
AlertmanagerConfig objects defined in Kubernetes follow the Prometheus Operator CRD schema and are mapped to Alertmanager configuration. They are not automatically discovered unless Alertmanager’s alertmanagerConfigSelector (and optionally alertmanagerConfigNamespaceSelector) are configured to match your labels.

Basic AlertmanagerConfig example

This is a minimal AlertmanagerConfig CRD that routes grouped alerts to a webhook receiver:
Key parts:
  • metadata.labels — used to match this object to Alertmanager instances (via alertmanagerConfigSelector).
  • spec.route — route behavior (grouping and timing).
  • spec.receivers — one or more receivers (here: webhook).

Why Alertmanager might not pick up your AlertmanagerConfig

When installed via the kube-prometheus-stack Helm chart, the Alertmanager StatefulSet/Deployment includes two fields in its spec:
By default these are empty, meaning Alertmanager will not match any AlertmanagerConfig objects. You must set alertmanagerConfigSelector (and optionally alertmanagerConfigNamespaceSelector) in the chart values so Alertmanager can discover AlertmanagerConfig objects by label.
If you do not configure a selector in the Helm chart values, Alertmanager will ignore AlertmanagerConfig objects even if they exist in the cluster.

Important syntax differences: alertmanager.yml vs AlertmanagerConfig CRD

When converting an alertmanager.yml (standalone Alertmanager config) to an AlertmanagerConfig CRD, note two common differences:
  • Property naming: standalone alertmanager.yml uses snake_case (e.g., group_wait), while the CRD uses camelCase (e.g., groupWait).
  • Label matchers: in alertmanager.yml you can write job: kubernetes. In the CRD matchers must be objects with name and value.
Comparison: Example pair: alertmanager.yml
AlertmanagerConfig CRD (equivalent)

Configure the Helm chart so Alertmanager finds AlertmanagerConfig objects

  1. Retrieve the default values for the kube-prometheus-stack chart:
  1. Edit values.yaml and set alertmanagerConfigSelector to match the labels you will use on AlertmanagerConfig objects. For example, to match resource: prometheus:
You can choose any label key/value pair; just use the same one on your AlertmanagerConfig objects.
  1. Upgrade the Helm release using the modified values file:
After the upgrade, the Alertmanager resource in the cluster should include the selector configuration:

Create and apply an AlertmanagerConfig

Create a file alert.yaml with the same example CRD (note metadata.labels matches the Helm selector):
Apply it:
Verify the resource exists:

Verify the Alertmanager configuration in the UI

Port-forward to the Alertmanager service and inspect the configuration via the status page:
  1. Find the Alertmanager service (commonly alertmanager-operated):
  1. Port-forward to 9093:
  1. Open http://localhost:9093/ in your browser and inspect the “Status -> Configuration” page. You should see your webhook receiver and routing as part of the Alertmanager configuration generated from your AlertmanagerConfig CRD.

Troubleshooting tips

  • If you see no AlertmanagerConfig objects in the Alertmanager UI but they exist in Kubernetes, re-check that:
    • The Helm chart alertmanagerConfigSelector matches the labels on your AlertmanagerConfig objects.
    • If you used namespace selectors, ensure alertmanagerConfigNamespaceSelector is set appropriately.
  • Use kubectl get alertmanagers.monitoring.coreos.com -o yaml to inspect the Alertmanager CRD instance spec and verify selectors.
  • Review the operator logs (Prometheus Operator) for errors about parsing AlertmanagerConfig objects.
Useful references:

Watch Video

Practice Lab