Grafana contact points for Slack, Teams and PagerDuty: what they do and when you need them
A contact point is the destination that a Grafana-managed alert notification is sent to, such as a Slack channel, a Microsoft Teams channel, a PagerDuty service or a webhook. Notification policies decide which contact point receives each alert based on its labels, so the contact point defines where a message lands and the policy tree defines who gets it. If your self-hosted instance must notify the right people in chat, paging or ticketing, you need both pieces configured and tested together. Grafana-managed alerting includes these integrations directly, so you do not need a separate Prometheus Alertmanager just to reach Slack, Teams or PagerDuty.
The first decision is the purpose of each destination. Chat channels such as Slack and Microsoft Teams suit awareness: a team wants to see that a service degraded, discuss it and watch it recover, but nobody is obliged to act at 3 a.m. Paging tools such as PagerDuty and Opsgenie suit on-call: they escalate, acknowledge and resolve incidents against a schedule. Send low-severity alerts to chat and reserve paging for conditions that need a human now. Before relying on either path, confirm the exact fields each integration requires in the Grafana contact point form for your version, including the Slack webhook or bot settings, the Teams webhook, and the PagerDuty integration key for the target service.
Confirm three things for each integration before go-live: that the credentials are stored as secrets and not in plain-text dashboards, that the destination's own permissions let the Grafana service post or create incidents, and that a test notification reaches the channel or service you expect. Also check how each tool handles resolved notifications, since some integrations send a resolution message and others close an incident only when the alert clears. For details on the Grafana setup for each contact point type, the Grafana alerting documentation is the natural next read, and the routing and grouping choices covered in the notification policy section determine how much of this traffic each destination receives.
Which contact point fits which alert audience
This table compares the contact point types most teams use, what each needs from the receiving side, and the audience it suits. Read each row as a question: who needs to act on the alert, and how quickly. The main takeaway is that paging integrations belong to on-call responders, while chat and ticketing channels suit alerts that can wait for a person to pick them up.
| Contact point | Needs from the receiving side | Best audience | When it fits |
|---|---|---|---|
| Slack | Incoming webhook URL or Slack app token for the target channel | Owning team channel | Shared awareness and low-severity alerts that do not need immediate paging |
| Microsoft Teams | Incoming webhook URL for the target channel | Owning team channel | Teams-based organizations that want alerts in the same place as operational discussion |
| PagerDuty | Events API integration key for a service | On-call responders | Alerts that must wake someone and be acknowledged, escalated or tracked to resolution |
| Opsgenie | API integration key for a team or integration | On-call responders | Existing on-call schedules and escalation policies already built around Opsgenie |
| A monitored mailbox or distribution list address | Stakeholders and shared mailboxes | Summaries, owners who are not on call, or systems that route mail into ticketing | |
| Generic webhook | An HTTPS endpoint that accepts the alert payload, plus any auth header it requires | Automation and ticketing systems | Opening tickets, triggering runbooks or feeding an internal tool that is not a built-in contact point |
| Pager routing with Prometheus Alertmanager | Alertmanager receiver configuration, not a Grafana contact point | Teams already running Alertmanager | Confirm in the Grafana docs whether a given receiver type is available through an external Alertmanager before relying on it |
| Field names and options | Exact settings vary by version | All audiences | Confirm against the current Grafana contact point docs for the version you run before building |
How to set up a contact point and test it before on-call relies on it
This sequence takes a receiving channel or incident service from creation to a verified message in Grafana, so that a responder sees the right alert content in the right place before any on-call rota depends on it.
Create the receiving side in the chat or paging tool
The owner of the target system creates the destination first: a Slack channel with an incoming webhook or Slack app, a Microsoft Teams channel with a workflow or connector URL, or a PagerDuty service with an Events API integration key. For Opsgenie, the team creates an API integration and copies its key. Keep the channel or service dedicated to this alert stream so test traffic does not mix with unrelated messages. Check that the owner can see the destination in their own tool and that the webhook or key is stored in the team's password manager or secrets vault, not in a ticket or chat thread. Confirm each vendor's current setup steps with the vendor, since these screens change between releases.
Store the integration secret outside the contact point
Webhook URLs and integration keys act as credentials, so they should not be typed into the contact point form in plain text on a shared instance. Grafana can encrypt these fields when they are saved, and file provisioning can read them from environment variables or a secrets store the platform team controls. Decide which approach your deployment uses before creating the contact point, and record where the value lives. Check that the secret field shows as masked in the Grafana interface after saving, and that no one with viewer access can read the value back.
Create the contact point in Grafana
In Grafana Alerting, a contact point is created under the contact points page by choosing the integration type (Slack, Microsoft Teams, PagerDuty, Opsgenie, email or webhook) and entering its settings. Give it a name that states the team and severity, such as the owning team plus the paging level, so that it is easy to pick in a policy later. Set the message title and body to the default templates for now, since custom templates are covered separately. Save the contact point and confirm it appears in the list with the correct type and no validation error.
Send a test notification
Use the test function on the saved contact point to send a sample notification. Grafana sends a test alert that carries the contact point's configured template, so the message shows the title, labels and link fields as a real alert would. Check the destination directly: the Slack or Teams channel should show the message in the expected channel, or the PagerDuty service should show a new incident on the expected service with the expected urgency. If nothing arrives, check outbound network access from the Grafana server to the vendor endpoint, the webhook or key value, and any proxy settings before changing anything else.
Attach the contact point to a notification policy
Create or edit a route in the notification policy tree that matches the labels of the alerts this team should receive, and set the contact point as its receiver. Grouping and timing settings belong to the routing configuration and are covered on their own page, so keep the defaults for this check. Use the policy's preview or test-route function, if your Grafana version provides it, with sample label sets to confirm that an alert with the team's label lands on this contact point and that an unrelated alert does not. Record the expected match in the route description so the next editor understands it.
Trigger a controlled alert through the route
Create a temporary alert rule, or use an existing low-impact rule in a non-production folder, with a condition that you can switch on and off and labels that match the new route. Let the rule fire and check the full path: the rule enters firing state, the notification policy routes it to the new contact point, and the message reaches the responder's channel or incident. Open the link in the message and confirm it opens the rule or dashboard the responder would need. Resolve the alert and confirm the resolved message arrives where expected. Delete the temporary rule afterward.
Confirm message content and a responder's acknowledgement
Ask an on-call engineer who was not involved in the setup to read the received message on their phone and say what broke, where, and where to go next. This checks that labels, the summary and the links are readable on a mobile device. For PagerDuty and Opsgenie, have the engineer acknowledge the incident and confirm the escalation policy notifies the right person. Record the test date, the contact point name, the policy route and the tester in the team's runbook or change record, so that the evidence is available when the route is reviewed.
How Slack, Teams and paging integrations differ in practice
Slack contact points usually post to a channel through an incoming webhook URL or, where you configure it, a bot token with permission to post in a named channel. The webhook URL is itself the credential, so anyone who holds it can post into that channel. Store it as a secret rather than leaving it in plain provisioning files, and confirm in your Slack workspace settings that the app is still installed and the channel still exists. Messages carry the alert title, status, labels, annotations and a link back to the alert. Common failures are a webhook removed when its app is uninstalled, a bot token revoked after the user who installed it leaves, and rate limiting when a noisy rule floods one channel. Grouping and repeat intervals in the notification policy are the first defense against that last case.
- Credential form: a webhook URL is a bearer secret, while a bot token needs the right channel scopes.
- Message fields: title, status, labels, annotations and the alert link are sent in each post.
- Typical failure: a removed app or revoked token causes sends to fail without a visible change in Grafana.
- Rate limits: bursts of grouped notifications can be throttled, so review group intervals for busy channels.
- Verify after change: send a test notification and confirm it appears in the intended channel with the expected fields.
Teams contact points depend on a webhook created in a channel, and Microsoft has changed how these connectors are built and retired over time. Confirm with Microsoft's current documentation which connector or workflow type your tenant supports before you build the contact point, because a connector that works today can be deprecated. The webhook URL is again the credential, so limit who can view or edit the contact point in Grafana. Message formatting is more constrained than Slack, so long annotations may be truncated and templates should keep the title and key labels near the top. A typical failure is a channel owner deleting the connector or a team being archived, which stops delivery silently from the Grafana side. Tenant policies can also block external connectors.
- Credential form: a channel webhook or workflow URL acts as the secret, so restrict access to it.
- Connector status: confirm the connector type is still supported in your tenant before building.
- Message fields: title, status and key labels are the most reliable content; keep annotations short.
- Typical failure: an archived team or deleted connector stops delivery, and tenant policy may block new connectors.
- Verify after change: send a test alert, check the card renders in the channel, and confirm the owner of the connector is documented.
Paging integrations are different in kind because they create incidents that someone is expected to acknowledge. PagerDuty uses an integration key tied to a specific service, and Opsgenie uses an API key or integration key tied to a team or integration. Both keys grant the ability to create incidents, so treat them as production secrets, rotate them when people leave the on-call rota, and keep one key per service so a leaked key has a bounded blast radius. Resolution messages matter: confirm that Grafana sends resolve events so incidents close automatically. Typical failures include a key rotated on the vendor side without updating Grafana, a service disabled or moved to another escalation policy, and API rate limits during a large incident storm. Check the vendor's current limits rather than assuming them.
- Credential form: an integration or routing key tied to one service, which should be treated as a production secret.
- Message fields: trigger and resolve events carry the alert identity, severity and summary so incidents can close.
- Typical failure: a rotated key, a disabled service or an escalation policy change silently breaks paging.
- Rate limits: large alert storms can hit vendor API limits, so confirm the current limits with each vendor.
- Verify after change: trigger a test incident, confirm it reaches the right escalation policy, then resolve it and check it closes.
Email and generic webhooks are the most flexible contact points and the easiest to leave unmonitored. Email depends on your SMTP relay, its authentication and its sender reputation, so a relay change or an expired relay password stops alerts without any Grafana error on the dashboard. Webhooks post JSON to a URL you define, which means the receiving ticketing system must parse the payload and deduplicate repeated firings itself. Use an authorization header or a secret in the URL path, store it as a secret, and confirm the receiving endpoint accepts TLS from your Grafana host. Ticketing systems often need the alert status to open and close tickets, so verify that resolved notifications are sent and mapped correctly.
- Credential form: SMTP credentials for email, and a header or secret path for webhooks.
- Payload handling: the receiver must read the status field and deduplicate repeated firings.
- Typical failure: SMTP credential expiry, relay changes or a rejected TLS certificate stop delivery quietly.
- Ticket lifecycle: confirm resolved notifications open or close tickets as your process expects.
- Verify after change: fire a test alert, check the ticket or inbox result, then confirm the resolved path works end to end.
Which integrations Prometheus Alertmanager cannot send to
The short answer is that Grafana-managed contact points cover more receiver types than a plain Prometheus Alertmanager configuration, so teams moving alerts into Grafana should first list every destination they use today and check each one against the Grafana contact point types. The receiver lists differ between Grafana and Alertmanager releases, and both change over time, so confirm the exact set against the current Grafana alerting documentation and the Alertmanager configuration reference for the versions you run. Do not rely on a comparison table from a blog post or an older internal wiki page.
Start the check with the integrations in this topic: Slack, Microsoft Teams, PagerDuty, Opsgenie, email and generic webhooks into ticketing. For each one, confirm three things in your own environment: that the Grafana version you plan to run offers the contact point type, that the Alertmanager version you would fall back to supports the equivalent receiver, and that any required fields such as a routing key, webhook URL or API token can be stored in the way your secrets policy allows. Record the result in a short matrix. Where the two products differ, the matrix tells you whether alerts can stay in Grafana or whether a forwarding design is needed.
Treat this as a verification step, not a settled list. Ask your Grafana and Alertmanager vendors or partners to confirm receiver support for your exact versions, and test one notification per destination in a non-production route before any on-call rotation depends on it. A receiver that exists in one product but has a different option set in the other is a common source of surprise during migration, so compare the required and optional settings as well as the receiver name.
Securing credentials and message content in contact points
Contact points hold the secrets that let Grafana post into Slack, Teams, PagerDuty and ticketing tools, and they render alert content into messages that leave your network. The cards below cover where those secrets live, what reaches the message body, who can change routing, and how changes are recorded.
Storing webhook URLs and integration keys
Slack and Teams incoming webhook URLs and PagerDuty integration keys act as bearer credentials: anyone holding one can post to that channel or page that team. Treat them like passwords, keep them out of dashboards and exported JSON, and supply them through environment variables or a secrets manager rather than typing them into the UI. Check whether your Grafana edition encrypts stored contact point secrets at rest, and confirm how backups of the database handle them. In file provisioning, use placeholders resolved at startup so the repository never holds the live value.
Rotating and scoping receiving-side credentials
Each contact point should use its own webhook or integration key, scoped to one channel or one PagerDuty service, so that a leaked value exposes one destination rather than every team. Record which Slack app, Teams connector and PagerDuty service each key belongs to, and plan a rotation procedure that updates Grafana and the receiving system together. Confirm with each vendor how keys are revoked and whether rotation can happen without downtime for paging. Test the new key with a notification before retiring the old one.
Controlling what appears in notification bodies
Notification templates pass alert labels and annotations into chat and paging messages, and those messages are copied into channel history, mobile push notifications and third-party storage. Review rule labels and annotations for customer identifiers, personal data, internal hostnames or query text that should not leave the environment. Filter or omit sensitive fields in the template, and keep detailed diagnostics behind a link to an access-controlled dashboard. Ask each receiving tool what retention and search access its own history provides.
Limiting who can edit contact points
Editing a contact point changes where every matching alert goes, including whether a page is sent at all. Restrict contact point and notification policy editing to a small platform or on-call administrators group, and keep viewer access for responders who need to confirm routing. In the open-source edition, confirm which roles can edit alerting resources, and compare that with what your identity provider and Enterprise features would allow. Where possible, make the provisioning repository the only write path for production routing.
Auditing changes to routing and credentials
A silent change to a webhook URL or a route can stop pages for days before anyone notices. Keep contact point and policy definitions in version control, require review for changes, and compare the running configuration with the repository on a schedule. Check which change events your Grafana edition writes to its logs and whether they record the actor, the time and the object changed without logging the secret value itself. Retain these records for as long as your incident and audit policy requires.
Questions teams ask before configuring Grafana contact points
What does the setup effort for Grafana contact points depend on?
The effort depends mostly on how many destinations you need, how many teams own them, and how the alerts are routed. A single Slack channel for one team is a small job. Separate channels for several teams, paging services for each, mobile-friendly message templates and test coverage for each route add work quickly. Other drivers are whether the Grafana instance is a single server or a high availability pair, which affects how notifications are deduplicated, and whether contact points are managed by hand in the UI or in version-controlled files. Ask any partner to break the quote down by destination, routing tree and testing so you can see which items grow with scope.
Can our team configure Slack or PagerDuty contact points without outside help?
Usually yes, if someone on the team has admin rights in the Grafana instance and owner rights in the Slack workspace or PagerDuty account. Creating a contact point is a form in the Grafana UI, and the credentials it needs, such as a webhook URL or an integration key, come from the chat or paging tool. The harder parts tend to be routing alerts to the correct team, avoiding paging for low-severity alerts, writing messages that a responder can act on, and proving the route works during an incident. Those are design and testing decisions, and they are where a partner or an experienced internal engineer adds the most value. Confirm the exact integration steps against the current Grafana and vendor documentation, since screens and options change between releases.
What does the work need from our side?
The work needs named service owners who can say which alerts their team must receive and who is on call for each. It needs access to the Slack workspace, Microsoft Teams team or PagerDuty account, with permission to create channels, incoming webhooks, workflows or service integrations. Someone must approve which tools receive which severity, and who may change routing later. You also need a test window agreed in advance, because a real test sends messages to on-call staff and may page them. Plan for a quiet period or a dedicated test service so that a failed route does not wake the wrong people. Your security team should also decide where the credentials are stored, since they will be entered into Grafana.
How long does a typical contact point integration take?
The duration depends on scope, and no fixed timeline applies to every environment. A small change, such as one chat channel for one team with a tested message, moves quickly because most of the time goes to access requests and review. A broader rollout covering several teams, paging services, escalation paths and a rehearsed test is measured in phases that include owner sign-off and a test window. Access approvals in your own organization often take longer than the technical configuration. Ask for a written schedule that lists each dependency, including the approvals and the test window, so that delays are visible before work starts.
Should we pay a consultant to set up Grafana contact points?
Paying for help makes most sense when the alerts will page people, the routing spans several teams, or nobody on the team has recently set up notification routing. The value comes from design decisions that are hard to undo, such as label conventions, grouping, timing and escalation. It also comes from testing the routes before on-call staff depend on them. Doing the work internally costs staff time and may be cheaper in the short term, but it still needs the same owner sign-offs and test window. DeployOpen plans and implements work under a written, fixed scope, and does not publish prices, so ask for a quote tied to the destinations, teams and test plan you define.
How do contact points change under provisioning or as-code workflows?
Under provisioning, contact points are defined in files that Grafana loads at startup instead of created in the UI. Grafana documents file provisioning for alerting resources, and it also lists other as-code options, including Terraform and Git Sync. The main engineering question is ownership of the source of truth. If a contact point is provisioned from a file and then edited in the UI, the two can drift, and a later restart or sync may overwrite the manual change. Secrets such as webhook URLs and integration keys should come from a secrets store or environment variables rather than being committed to version control. Decide before the first deployment which team edits the files, how changes are reviewed, and how the route is tested after each change.
Do Slack, Teams and PagerDuty contact points work the same way in a high availability setup?
Not by default. Grafana's high availability guidance says that alerting needs additional configuration to avoid duplicate notifications, so a pair of active Grafana servers can send the same alert to a channel or paging service twice unless the cluster is set up for it. Before you configure paging destinations, confirm how your instance shares alert state across nodes, and test with a non-paging destination first. Duplicate pages erode trust in the on-call process, so this check belongs in the test plan rather than after go-live.
Official Grafana documentation to read alongside this page
Start with the Grafana documentation for Grafana Alerting, which describes how *contact points* fit into the wider alerting model: rules evaluate, notification policies route, and contact points deliver. The Grafana licensing page matters here too. Grafana is licensed under AGPLv3, and Grafana Enterprise is a separate commercial option, so confirm which edition your organization runs before you plan any feature that depends on edition-specific behavior. Keep the licensing terms in front of the team when you decide how the instance is hosted and who administers it.
Treat the contact point field lists in the documentation as version-specific. The integrations covered here, including Slack, Microsoft Teams, PagerDuty, Opsgenie, email and webhook, expose different required fields, token types, and optional settings over time. Open the documentation for the exact Grafana version you run, and compare the Slack and Teams fields against the webhook or connector setup in your own workspace. Record the version you verified against, because a later upgrade may change field names or defaults and the page you read today may not match the screen your on-call engineers see.
Check the installed version's release notes before relying on any contact point in production, and confirm with each vendor which endpoint types, webhook formats and authentication methods their product currently accepts. Note that Microsoft and Slack retire webhook and connector mechanisms on their own schedules, so verify those URLs and permissions directly in the vendor's admin console. The Grafana documentation tells you what Grafana sends, but only the vendor documentation tells you whether the receiving side still accepts it.
How DeployOpen scopes, delivers and supports Grafana contact points
DeployOpen plans, implements, documents and supports self-hosted Grafana inside your own infrastructure, including the contact points that carry alerts to Slack, Microsoft Teams, PagerDuty, Opsgenie, email and webhooks. Each engagement starts from a written scope that names the channels, the receivers and the people who must confirm the result before go-live.
How we scope
- We list each contact point type, its destination workspace, channel or service, and the teams that own it.
- We record which alerts reach paging tools and which go to chat or tickets, so severity rules are agreed up front.
- We confirm where secrets such as webhook URLs and integration keys will be stored and who may rotate them.
How we build
- We configure contact points in your Grafana instance, using provisioning files or the UI as your team decides.
- We test each receiver with sample notifications and confirm the message reaches the intended channel or on-call service.
- We check the integration against the vendor's current documentation, since Slack, Teams and PagerDuty settings change over time.
How we hand over
- You receive a written record of each contact point, its owner, its routing and the steps used to test it.
- We document how to rotate tokens and webhook URLs and how to add a new receiver without breaking existing routes.
- We walk your operations and on-call staff through the test results and the escalation path before handover is closed.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Before you request a quote, confirm which Grafana edition, version and hosting model your team runs.
