Grafana's Contact Point Architecture
Grafana Alerting works through a layered system: alert rules evaluate metrics, alert groups organize rules, and contact points define where notifications go. Grafana ships with contact point integrations for Slack, Microsoft Teams, PagerDuty, OpsGenie, and others.
Each contact point is a single destination. To notify both Slack and Teams from one alert rule, you create two contact points and associate both with a notification policy. This works — but it has a maintenance cost that compounds with scale.
Every new destination (a new Slack channel, a new Teams team) requires a new contact point. Every change to a notification endpoint (a webhook URL rotation, a Slack channel rename) must be updated in the contact point configuration. For organizations with dozens of alert rules routing to multiple destinations, the contact point list grows into a management burden.
Grafana OnCall and Grafana's on-call routing features add additional complexity: escalation chains, override schedules, and silence rules all interact with contact points in ways that require careful coordination when multiple destinations are involved.
Where SyncRivo Fits Alongside Grafana Contact Points
SyncRivo does not receive Grafana webhooks or fan out alerts — messages posted by bots, apps, and webhooks are not relayed across platforms. Keep Grafana's native Slack and Microsoft Teams contact points for the alerts themselves. SyncRivo's role is the human side: it bridges the Slack channel and the Teams channel where responders and stakeholders discuss an alert, so the conversation happens in one place across both platforms.
Setup:
- In Grafana, go to Alerting → Contact points and create native Slack and Microsoft Teams contact points.
- In Grafana, edit your notification policies to route each alert group to the contact points for its audience.
- With SyncRivo, bridge the Slack #oncall discussion channel with the Teams #engineering channel. Your first channel bridge is typically live during onboarding, once your Slack and Teams admins approve the app.
- Because alert posts are not relayed, send alerts that both audiences need to both platforms through contact points, and let engineers and managers discuss them in the bridged channel.
Grafana OnCall and AlertManager
For organizations routing alerts through Prometheus AlertManager before they reach Grafana, use AlertManager's own Slack and Microsoft Teams receivers, or route through Grafana contact points.
For Grafana OnCall, use OnCall's native chat integrations for escalation notifications. SyncRivo is not a receiver or outbound webhook target in either setup; it bridges the human discussion that follows.
Alert Routing by Severity and Audience
These routes are configured with Grafana notification policies and native contact points:
Critical alert firing: Route to Slack #oncall for the on-call engineer who will respond, and Teams #engineering-leadership for the engineering manager who needs awareness without being the primary responder.
Warning alert firing: Route to Slack for the engineering team monitoring the service. Leadership visibility at warning level is usually noise — route only to Slack.
Alert resolved: Send resolution notifications to both platforms. Engineers in Slack and managers in Teams both see the resolution without a manual update or cross-platform status check.
Anomaly detected (machine learning-based alerts): Route to both Slack (for investigation) and Teams (for business stakeholders if the anomaly affects user-facing metrics). Anomaly alerts often have ambiguous severity at first — routing to both platforms ensures the right audience sees them early.
Data source alerting (database, infrastructure): Route based on the data source. Database latency alerts go to Slack #backend-eng. Infrastructure capacity alerts go to Slack #infra + Teams #engineering for capacity planning visibility.
For more on Grafana alerts in Slack and Teams, see the Grafana Alerts in Slack & Teams integration guide.
Ready to connect your messaging platforms?
