Notifications on Grafana Labs

Contact points

Fri, 03 Apr 2026 19:43:06 +0000

Contact points

Contact points contain the configuration for sending alert notifications. You can assign a contact point either in the alert rule or notification policy options.

A contact point includes one or more contact point integrations for sending alert notifications, such as:

Alertmanager
Amazon SNS
Cisco Webex Teams
DingDing
Discord
Email
Google Chat
Grafana IRM
Jira
Kafka REST Proxy
Line
Microsoft Teams
MQTT
Opsgenie
PagerDuty
Pushover
Sensu Go
Slack
Telegram
Threema Gateway
VictorOps
Webhook
WeCom

For example, a contact point could contain a PagerDuty integration; an email and Slack integration; or a PagerDuty integration, a Slack integration, and two email integrations. You can also configure a contact point with no integrations; in which case no notifications are sent.

Each contact point integration can also define the notification message to be sent, which can use the predefined message, a custom message, or notification templates.

For a complete list of supported integrations and more details about contact points, refer to Configure contact points.

Notification policies

Fri, 03 Apr 2026 19:43:06 +0000

Notification policies

Notification policies provide you with a flexible way of designing how to handle notifications and minimize alert noise.

Using label matchers, alert instances are routed to notification policies. The notification policy can then group multiple alert instances into a single notification and deliver it to the contact point.

Notification policies are not a list, but rather are structured according to a tree structure:

The root of the notification policy tree is the Default notification policy.
Each policy can have child policies.
Each policy can have sibling policies, sharing the same parent and hierarchical level.

Each policy consists of a set of label matchers (0 or more) that specify which alerts they are or aren’t interested in handling. A matching policy refers to a notification policy with label matchers that match the alert instance’s labels.

Use labels and label matchers to link alert rules to notification policies and silences. This allows for a flexible way to manage your alert instances, specify which policy should handle them, and which alerts to silence.

A label matchers consists of 3 distinct parts, the label, the value and the operator.

The Label field is the name of the label to match. It must exactly match the label name.
The Value field matches against the corresponding value for the specified Label name. How it matches depends on the Operator value.

The Operator field is the operator to match against the label value. The available operators are:

Operator	Description
`=`	Select labels that are exactly equal to the value.
`!=`	Select labels that are not equal to the value.
`=~`	Select labels that regex-match the value.
`!~`	Select labels that do not regex-match the value.

Note
If you are using multiple label matchers, they are combined using the AND logical operator. This means that all matchers must match in order to link a rule to a policy.

Label matching example

If you define the following set of labels for your alert:

{ foo=bar, baz=qux, id=12 }

then:

A label matcher defined as foo=bar matches this alert rule.
A label matcher defined as foo!=bar does not match this alert rule.
A label matcher defined as id=~[0-9]+ matches this alert rule.
A label matcher defined as baz!~[0-9]+ matches this alert rule.
Two label matchers defined as foo=bar and id=~[0-9]+ match this alert rule.

Exclude labels

You can also write label matchers to exclude labels.

Here is an example that shows how to exclude the label Team. You can choose between any of the values below to exclude labels.

Label	Operator	Value
`team`	`=`	`""`
`team`	`!~`	`.+`
`team`	`=~`	`^$`

Tip
For a practical example of routing with notification policies, refer to our Getting Started with Alert Instances and Notification Routing tutorial.

Routing

To determine which notification policies handle an alert instance, the system looks for matching policies starting from the top of the tree—beginning with the default notification policy.

If a matching policy is found, the system continues to evaluate its child policies in the order they are displayed. If a child policy matches the alert, the system then evaluates its child policies recursively until no more matching child policies are found. In this case, only the deepest matching child policy handles the alert instance.

By default, once a matching policy is found, the system does not continue to look for sibling policies. If you want sibling policies of one matching policy to handle the alert instance as well, then enable Continue matching siblings on the particular matching policy.

Note
The default notification policy matches all alert instances. It always handles alert instances if there are no child policies or if none of the child policies match the alert instance’s labels—this prevents any alerts from being missed.

If alerts use multiple labels, these labels must also be present in a notification policy to match and route notifications to a specific contact point.

This routing and tree structure makes it convenient to organize and handle alerts for dedicated teams, while also narrowing down specific cases within the team by applying additional labels.

Inheritance

In addition to child policies being a useful concept for routing alert instances, they also inherit properties from their parent policy. This also applies to child policies of the default notification policy.

By default, a child policy inherits the following notification properties from its parent:

Then, each policy can overwrite these properties if needed.

The inheritance of notification properties, together with the routing process, is an effective method for grouping related notifications and handling specific cases through child policies.

Inheritance example

This example shows how the notification policy tree from the previous example allows the child policies of the team=operations to inherit its contact point. In this way, you can avoid specifying the same contact point multiple times for each child policy.

Group alert notifications

Fri, 03 Apr 2026 19:43:06 +0000

Group alert notifications

Grouping in Grafana Alerting allows you to batch relevant alerts together into a smaller number of notifications. This is particularly important if notifications are delivered to first-responders, such as engineers on-call, where receiving lots of notifications in a short period of time can be overwhelming. In some cases, it can negatively impact a first-responders ability to respond to an incident. For example, consider a large outage where many of your systems are down. In this case, grouping can be the difference between receiving 1 phone call and 100 phone calls.

Tip
For a practical example of grouping, refer to our Getting Started with Grouping tutorial.

Group notifications

Grouping combines similar alert instances within a specific period into a single notification, reducing alert noise.

In the notification policy, you can configure how to group multiple alerts into a single notification:

The Group by option specifies the criteria for grouping incoming alerts within the policy. The default is by alert rule.
Timing options determine when and how often to send the notification.

Alert instances are grouped together if they have the same exact label values for the labels configured in the Group by option.

For example, given the Group by option set to the team label:

alertname:foo, team=frontend, and alertname:bar, team=frontend are in one group.
alertname:foo, team=frontend, and alertname:qux, team=backend are in another group.

Group by alert rule or labels

By default, notification policies in Grafana group alerts by the alert rule. Specifically, they are grouped using the alertname and grafana_folder labels, as alert rule names are not unique across folders.

If you want to group alerts by other labels, something other than the alert rule, change the Group by option to any other combination of labels.

A single group for all alerts

If you want to group all alerts handled by the notification policy in a single group (without grouping notifications by alert rule or other labels), leave Group by empty in the Default policy.

Disable grouping

If you want to receive every alert as a separate notification, you can do so by grouping by a special label called ..., ensuring that other labels are not present.

Timing options

In the notification policy, you can also configure how often notifications are sent for each group of alerts. There are three distinct timers applied to groups within the notification policy:

Group wait: the time to wait before sending the first notification for a new group of alerts.
Group interval: the time to wait before sending a notification about changes in the alert group.
Repeat interval: the time to wait before sending a notification if the group has not changed since the last notification.

These timers reduce the number of notifications sent. By delaying the delivery of notifications, incoming alerts can be grouped into just one notification instead of many.

Group wait

Default: 30 seconds

Group wait is the duration Grafana waits before sending the first notification for a new group of alerts.

This option helps reduce the number of notifications sent for related alerts occurring within a short time frame. The longer the group wait, the more time other alerts have to be included in the initial notification of the new group. The shorter the group wait, the earlier the first notification is sent, but at the risk of not including some alerts.

If an alert is resolved before the duration elapses, no notification is sent for that alert. This reduces noise from flapping alerts.

Example

Consider a notification policy that:

Matches all alert instances with the team label—matching labels equals to team=~.+.
Groups notifications by the team label—one group for each distinct team.
Sets the Group wait timer to 30s.

Time	Incoming alert instance	Notification policy group	Number of instances
00:00	`alertname=f1` `team=frontend`	`frontend`	1	Starts the group wait timer of the `frontend` group.
00:10	`alertname=f2` `team=frontend`	`frontend`	2
00:20	`alertname=b1` `team=backend`	`backend`	1	Starts the group wait timer of the `backend` group.
00:30^*		`frontend`	2	Group wait elapsed. Send initial notification reporting 2 alerts.
00:35	`alertname=b2` `team=backend`	`backend`	2
00:40	`alertname=b3` `team=backend`	`backend`	3
00:50^*		`backend`	3	Group wait elapsed. Send initial notification reporting 3 alerts.

Group interval

Default: 5 minutes

If an alert was too late to be included in the first notification due to group wait, it is included in subsequent notifications after group interval.

Group interval is the duration to wait before sending notifications about group changes. A group change occurs when:

A new firing alert is added to the group.
An existing alert is resolved.

Example

Here are the related excerpts from the previous example:

Time	Incoming alert instance	Notification policy group	Number of instances
00:30^*		`frontend`	2	Group wait elapsed and starts Group interval timer. Send initial notification reporting 2 alerts.
00:50^*		`backend`	3	Group wait elapsed and starts Group interval timer. Send initial notification reporting 3 alerts.

And below is the continuation of the example setting the Group interval timer to 5 minutes:

Time	Incoming alert instance	Notification policy group	Number of instances
01:30	`alertname=f3` `team=frontend`	`frontend`	3
02:30	`alertname=f4` `team=frontend`	`frontend`	4
05:30^*		`frontend`	4	Group interval elapsed and resets timer. Send one notification reporting 4 alerts.
05:50^*		`backend`	3	Group interval elapsed and resets timer. No group changes, and do not send notification.
08:00	`alertname=f4` `team=backend`	`backend`	4
10:30^*		`frontend`	4	Group interval elapsed and resets timer. No group changes, and do not send notification.
10:50^*		`backend`	4	Group interval elapsed and resets timer. Send one notification reporting 4 alerts.

How it works

Once the first notification has been sent for a new group of alerts, the group interval timer starts.

When the group interval timer elapses, the system resets the group interval timer and sends a notification only if there were group changes. This process repeats until there are no more alerts.

It’s important to note that an alert instance exits the group after being resolved and notified of its state change.

When the group interval timer elapses and no alerts remain, the group is deleted. The group wait timer will then start again the next time a new alert arrives.

Repeat interval

Default: 4 hours

Repeat interval acts as a reminder that alerts in the group are still firing.

The repeat interval timer decides how often notifications are sent (or repeated) if the group has not changed since the last notification.

How it works

Repeat interval is evaluated every time the group interval resets. If the alert group has not changed and the time since the last notification was longer than the repeat interval, then a notification is sent as a reminder that the alerts are still firing.

Repeat interval must not only be greater than or equal to group interval, but also must be a multiple of Group interval. If Repeat interval is not a multiple of group interval it is coerced into one. For example, if your Group interval is 5 minutes, and your Repeat interval is 9 minutes, the Repeat interval is rounded up to the nearest multiple of 5 which is 10 minutes.

The maximum duration of the repeat interval is 5 days, constrained by the default value of the notification_log_retention setting in Grafana.

Example

Here are the related excerpts from the previous example:

Time	Incoming alert instance	Notification policy group	Number of instances
05:30^*		`frontend`	4	Group interval resets. Send the last notification.
10:50^*		`backend`	4	Group interval resets. Send the last notification.

And below is the continuation of the example setting the Repeat interval timer to 4 hours:

Time	Notification policy group	Number of instances
04:05:30	`frontend`	4	Group interval resets. The time since the last notification was no longer than the repeat interval.
04:10:30	`frontend`	4	Group interval resets. The time since the last notification was longer than the repeat interval. Send one notification reminding the 4 firing alerts.
04:10:50	`backend`	4	Group interval resets. The time since the last notification was no longer than the repeat interval.
04:15:50	`backend`	4	Group interval resets. The time since the last notification was longer than the repeat interval. Send one notification reminding the 4 firing alerts.