AlertManager's Receiver Architecture
Prometheus AlertManager routes alerts through a configuration file (alertmanager.yml) that defines receivers and routing rules. Each receiver specifies a destination: a Slack webhook URL, a PagerDuty routing key, an OpsGenie API key, or a generic webhook URL.
To notify both Slack and Teams from one alert, AlertManager supports grouping multiple receivers into a receiver list. You define a Slack receiver, a Teams receiver (via webhook_configs), and combine them. This works — but creates a maintenance pattern that compounds over time.
Every new messaging destination requires a new receiver block in alertmanager.yml. Every URL rotation requires an alertmanager.yml change, a config reload (amtool reload or a pod restart in Kubernetes), and validation. For teams running multiple AlertManager instances (production, staging, regional clusters), the config change must be propagated everywhere.
The receiver list also grows with organizational complexity: post-M&A environments add Teams for the acquired entity alongside existing Slack. Expanding to Webex for a NOC team adds another receiver. Each addition is a configuration change in a file that lives in version control and requires deployment.
Consolidating to a Single Webhook Receiver
SyncRivo is not an alert receiver: it does not accept AlertManager webhooks, and messages posted by bots or apps are not relayed across its bridges. Alert delivery stays in AlertManager's own receivers — keep your Slack receiver and your Teams receiver, and manage the routing tree in alertmanager.yml.
To keep that configuration manageable:
- Group the Slack and Teams receivers you need into a small number of named receivers per audience (on-call, management, security).
- Keep webhook URLs in a secrets manager and template them into alertmanager.yml so URL rotation does not require hand edits.
- Reload AlertManager config after changes: run amtool reload or restart the AlertManager pod.
- Route by AlertManager's label fields: severity, alertname, cluster, env.
Where SyncRivo helps is the human conversation after the alert fires: bridge the Slack channel your SREs use with the Teams channel your managers use, so the incident discussion reaches both platforms in real time.
Routing AlertManager Labels to the Right Audience
AlertManager labels are the routing primitives. AlertManager route matchers can match on any label:
severity: critical: Route to Slack #oncall for the on-call engineer and Teams #engineering for management visibility. Critical alerts are always dual-platform.
severity: warning: Route to Slack #alerts for the engineering team. Warning-level alerts are pre-critical monitoring signals — engineering needs them, management does not.
env: production: Production alerts always route to both platforms. Staging and development environment alerts route to Slack only.
team: security: Security-labeled alerts route to Slack #security and Teams for the CISO or security leadership channel.
alertname: Watchdog: The AlertManager heartbeat alert — route to a dedicated Slack channel for monitoring the monitoring system. Not a real alert, should not reach Teams.
Resolved alerts: With send_resolved: true, AlertManager sends a resolution notification when an alert clears. Resolution notifications go to the same receivers as the original alert, so SREs in Slack and managers in Teams both see the resolution without manual follow-up.
Works with Grafana, Thanos, and Mimir
Prometheus AlertManager is commonly used as the alerting layer for Grafana, Thanos (long-term storage), and Grafana Mimir. AlertManager's receiver configuration does not depend on the upstream metric storage layer — the alertmanager.yml configuration is the same whether your metrics come from single-cluster Prometheus or a Thanos query layer spanning multiple clusters.
For the full AlertManager configuration reference, label-based routing examples, and multi-cluster setup patterns, see the Prometheus AlertManager in Slack & Teams integration guide.
Ready to connect your messaging platforms?
