Configure notifications on Grafana Labs

Configure contact points

Tue, 27 Oct 2026 11:15:42 +0000

Configure contact points

Use contact points to specify where to receive alert notifications. Contact points contain the configuration for sending alert notifications, including destinations like email, Slack, IRM, webhooks, and their notification messages.

A contact point can have one or multiple destinations, known as contact point integrations. Alert notifications are sent to each integration within the chosen contact point.

On the Contact Points tab, you can:

Add, edit, and view contact points and integrations.
Search for name and type of contact points and integrations.
View how many notification policies each contact point is being used for and navigate directly to the linked notification policies.
View the status of notification deliveries.
Export individual contact points or all contact points in JSON, YAML, or Terraform format.
Delete contact points. Note that you cannot delete contact points that are in use by a notification policy. To proceed, either delete the notification policy or update it to use another contact point.

Note
Contact points are assigned to a specific Alertmanager and cannot be used by notification policies in other Alertmanagers.

Protected fields

For Grafana users, contact points may contain protected fields that require admin permissions to modify. Protected fields are sensitive configuration settings that affect where notifications are sent, such as:

Target URLs for integrations (webhooks, PagerDuty, Opsgenie, or other integrations.)
API endpoints
Other destination-related settings

These fields are protected to prevent unauthorized users from redirecting notifications to compromised servers, which could expose sensitive information such as authorization tokens, API keys, or alert data.

Users with edit permissions can modify most contact point settings and can add or remove integrations, but cannot change protected fields in existing integrations. Only users with admin permissions to the contact point can update protected fields.

The ability to modify protected fields is controlled by the RBAC action alert.notifications.receivers.protected:write. This role is granted by default to:

Users with the fixed “Alerting Admin” role
Users with admin permissions for the specific contact point

Supported contact point integrations

Each contact point integration has its own configuration options and setup process. The following list shows the contact point integrations supported by Grafana.

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

Some of the integrations above are not supported by Prometheus Alertmanager. For the list of supported integrations, refer to the Prometheus Alertmanager receiver settings.

Allowlist notification source IP addresses

Grafana Cloud notifications sent by the Grafana Alertmanager use the grafana service egress IP addresses, not the Hosted Alerts (alerts) list or src-ips.alertmanager-*.grafana.net DNS records. To retrieve the current addresses, refer to List of Grafana Cloud IP addresses to add to your allowlist.

Add a contact point

Complete the following steps to add a contact point.

In the left-side menu, click Alerts & IRM and then Alerting.
Click Notification configuration, then select the Contact points tab.
From the Choose Alertmanager dropdown, select an Alertmanager. By default, Grafana Alertmanager is selected.
Click + New contact point.
Enter a descriptive name for the contact point.
From Integration, select a type and fill out mandatory fields. For example, if you choose email, enter the email addresses. Or if you choose Slack, enter the Slack channel and users who should be contacted.
Some contact point integrations, like email or Webhook, have optional settings. In Optional settings, specify additional settings for the selected contact point integration.
In Notification settings, optionally select Disable resolved message if you do not want to be notified when an alert resolves.
Save your changes.

Add another contact point integration

A contact point can have multiple integrations, or destinations for sending notifications.

To add another integration to a contact point, complete the following steps.

Add or edit an existing contact point.
Click Add contact point integration and repeat the same steps as Add a contact point.
- From Integration, select a type and fill out mandatory fields.
- In Optional settings, specify additional settings for the selected contact point integration.
Save your changes.

Customize notification messages

In contact points, you can also customize notification messages. For example, when setting up an email contact point integration, click Message or Subject to modify it.

By default, notification messages include common alert details, which are usually sufficient for most cases.

If necessary, you can customize the content and format of notification messages. You can create a custom notification template, which can then be applied to one or more contact points.

On the Templates tab under Notification configuration, you can view, edit, copy or delete notification templates. Refer to manage notification templates for instructions on selecting or creating a template for a contact point.

Test a contact point

Testing a contact point is only available for Grafana Alertmanager. Complete the following steps to test a contact point.

In the left-side menu, click Alerts & IRM and then Alerting.
Click Notification configuration, then select the Contact points tab to view a list of existing contact points.
Find the contact point you want to test, then click Edit. You can also create a new contact point if needed.
Click Test to open the contact point testing dialog box.
Choose whether to send a predefined test notification or choose custom to add your own custom annotations and labels to include in the notification.
Click Send test notification to fire the alert.

Enable notifications for a contact point

After creating a contact point, you can enable it to receive alert notifications using one of the following methods:

Assign it to alert rules – Select the contact point in the notifications options for Grafana-managed alert rules to directly associate it with specific alerts.
Assign it to notification policies – Add the contact point to one or more notification policies, which manage the alert notifications you want the contact point to receive.

Troubleshoot notification delivery

The Contact points tab shows the status of the latest notification deliveries for each contact point. To review past delivery attempts and filter by contact point or delivery outcome, refer to View notification history.

Configure notification policies

Tue, 27 Oct 2026 11:15:42 +0000

Configure notification policies

Notification policies determine how alerts are routed to contact points.

Policies have a tree structure. Each policy can have one or more child policies and a set of label matchers.

Each alert (or alert instance) is evaluated by the default policy and subsequently by each child policy. Alerts are routed to the appropriate notification policy by matching alert labels with the policy’s label matchers. For further details, refer to label matching and routing in notification policies.

When an alert instance is assigned to a notification policy, the notification policy is responsible for:

Grouping similar alerts to minimize the number of notifications.
Controlling when notifications are sent using the timing options.
Determining the contact points that receive the alert notification.

Note
The default notification policy and its child policies are assigned to a specific Alertmanager, and they cannot use contact points or mute timings from other Alertmanagers.

Edit the default notification policy

You can change the contact point, grouping, and timing options for this policy. Mute timings and active time intervals aren’t available on the root policy. Add them on a child policy instead.

In the left-side menu, click Alerts & IRM and then Alerting.
Click Notification configuration, then select the Notification policies tab.
From the Choose Alertmanager dropdown, select an external Alertmanager. By default, the Grafana Alertmanager is selected.
In the Default policy section, click … -> Edit.
In Default contact point, update the contact point for where to send notifications when alert rules do not match any specific policy.
In Group by, choose labels to group alerts. If multiple alerts match this policy, they are grouped by the selected labels, and notifications are sent per group. For more details on using this option, refer to Group notifications.
In Timing options, set the timing options to configure when notifications are sent.
- Group wait: the time to wait before sending the first notification for a new group of alerts. Default is 30 seconds.
- Group interval: the time to wait before sending a notification about changes in the alert group. Default is 5 minutes.
- Repeat interval: the time to wait before sending a notification if the group has not changed since the last notification. Default is 4 hours.
Click Save to save your changes.

Add a child policy

You can create a child policy under a default policy or under an existing child policy.

If you want to choose where to position your policy, see the section on Add a sibling policy.

In the left-side menu, click Alerts & IRM and then Alerting.
Click Notification configuration, then select the Notification policies tab.
From the Choose Alertmanager dropdown, select an Alertmanager. By default, the Grafana Alertmanager is selected.
Click +New child policy from the default policy or an existing child policy.
In the Matching labels section of the child policy, add one or more matching label rules to narrow down a specific case from the parent policy.

For instance, a child policy of the default policy handles team=security alerts, or a child policy handles only the severity=critical alerts of a parent policy.
In the Contact point dropdown, select the contact point to send notifications. If left empty, the contact point of the parent policy is inherited.
Optionally, enable Continue matching subsequent sibling nodes to continue matching sibling policies even after the alert matched the current policy. If enabled, multiple policies can handle the same alert.
Optionally, enable Override grouping to set different grouping than the parent policy. If disabled, the grouping of the parent policy is inherited.
Optionally, enable Override general timings to set different timing options than the parent policy. If disabled, the timing options of the parent policy are inherited.
Optionally, in Mute timings and Active timings, select time intervals that apply to this policy. These fields aren’t available on the root policy.
Click Save policy to save your changes.

Add a sibling policy

In the left-side menu, click Alerts & IRM and then Alerting.
Click Notification configuration, then select the Notification policies tab.
Find the child policy you want to create a sibling for.
Click Add new policy -> New sibling above or New sibling below.

It’s important to determine which policy receives the alert first and to set the correct order of sibling and child policies.

Policies are evaluated from top to bottom. If a matching policy is found, the system continues to evaluate its child policies in the order they are displayed. For more details, refer to notification policies routing.
Follow the instructions from step 5 onward in adding a child policy.

Search for policies

Grafana allows you to search within the tree of policies by the following:

Label matchers
Contact Points

To search by contact point simply select a contact point from the Search by contact point dropdown. The policies that use that contact point are highlighted in the user interface.

To search by label matchers simply enter a valid matcher in the Search by matchers input field. Multiple matchers can be combined with a comma (,).

It is important to note that all matched policies are exact matches. Grafana supports regular expressions for creating label matchers. It does not support regular expression or partial matching in the search for policies.

Mute timings

Mute timings pause notifications during a recurring period. Active time intervals allow notifications only during a recurring period.

You can assign them only on child notification policies, not on the root policy. They aren’t inherited from a parent notification policy. For instructions, refer to Configure mute timings.

Manage multiple notification policy trees

By default, Grafana uses a single notification policy tree for all alert routing. As organizations grow in size and complexity, managing a single global tree can become difficult. Multiple notification policy trees allow you to split routing logic into separate, independently managed routing trees.

Each notification policy tree has its own name, root policy, and child policies which function similarly to the default policy tree. You can create additional routing trees to organize routing logic by team, service, or domain.

The Default Policy can’t be deleted. You can, however, reset the policy to clear it.

For provisioning instructions, refer to Enable multiple notification policy trees via Terraform.

Example

An example of an alert configuration.

Create a “default” contact point for slack notifications, and set it on the default policy.
Edit the default policy grouping to group alerts by cluster, namespace and severity so that you get a notification per alert rule and specific Kubernetes cluster and namespace.
Create specific route for alerts coming from the development cluster with an appropriate contact point.
Create a specific route for alerts with “critical” severity with a more invasive contact point integration, like pager duty notification.
Create specific routes for particular teams that handle their own on-call rotations.

Configure mute timings and active time intervals

Tue, 27 Oct 2026 11:15:42 +0000

Configure mute timings and active time intervals

Mute timings and active time intervals let you determine how your alert notifications are handled during designated periods of time. After you create a time interval, you can apply it as either a mute timing or active time interval for your notification policies.

A mute timing is a recurring interval that stops notifications for one or multiple notification policies during a specified period. It suppresses notifications but does not interrupt alert evaluation.

Use mute timings to temporarily pause notifications for a specific recurring period, such as a regular maintenance window or weekends.

Active time intervals provide the opposite functionality, where alerts handled by a notification policy are suppressed unless the notification happens at a time that matches the time interval. Use active time intervals for periods where you want to reduce alert noise. Mute timings take precedence over active time intervals when they overlap.

Note
Mute timings and active time intervals are assigned to a specific Alertmanager and only suppress notifications for alerts managed by that Alertmanager.

Mute timings and active time intervals vs silences

Mute timings and active time intervals and silences are distinct methods to suppress notifications. They do not prevent alert rules from being evaluated or stop alert instances from appearing in the user interface; they only prevent notifications from being created.

The following table highlights the key differences between mute timings and silences.

	Mute timing	Silence
Setup	Created and then added to notification policies	Matches alerts using labels to determine whether to silence them
Period	Uses time interval definitions that can repeat periodically	Has a fixed start and end time

Add time intervals

In the left-side menu, click Alerts & IRM, and then Alerting.
Click Notification configuration, then select the Time intervals tab.
From the Alertmanager dropdown, select an external Alertmanager. By default, the Grafana Alertmanager is selected.
Click + New time interval.
Fill out the form to create a time interval to match against for your mute timing or active time interval.
Save your changes.

Assign a time interval to a notification policy

After you create a time interval, assign it as a mute timing or an active time interval on a child notification policy. You can’t assign these settings to the root policy. They aren’t inherited from a parent policy.

In the left-side menu, click Alerts & IRM, and then Alerting.
Click Notification configuration, then select the Notification policies tab.
Find a child notification policy and click … -> Edit.
From Mute timings or Active timings, choose the time intervals to add to the policy.
Save your changes.

Time intervals

A time interval is a specific duration during which alerts are suppressed. The duration typically consists of a specific time range and the days of the week, month, or year.

A mute timing or active time interval can contain multiple time intervals.

Supported time interval options are:

Time range: The time inclusive of the start and exclusive of the end time (in UTC if no location has been selected, otherwise local time).
Location: Depending on the location you select, the time range is displayed in local time.
Days of the week: The day or range of days of the week. Example: monday:thursday.
Days of the month: The date 1-31 of a month. Negative values can also be used to represent days that begin at the end of the month. For example: -1 for the last day of the month.
Months: The months of the year in either numerical or the full calendar month. For example: 1, may:august.
Years: The year or years for the interval. For example: 2021:2024.

All fields are lists; to match the field, at least one list element must be satisfied. Fields also support ranges using : (e.g., monday:thursday).

If a field is left blank, any moment of time matches the field. For an instant of time to match a complete time interval, all fields must match.

If you want to specify an exact duration, specify all the options.

Example

If you wanted to create a time interval for the first Monday of the month, for March, June, September, and December, between the hours of 12:00 and 24:00 UTC your time interval specification would be:

Time range:
- Start time: 12:00
- End time: 24:00
Days of the week: monday
Months: 3, 6, 9, 12
Days of the month: 1:7

Configure silences

Tue, 27 Oct 2026 11:15:42 +0000

Configure silences

Silences stop notifications from being created for a specified time window but do not interrupt alert evaluation. Use them to temporarily prevent alert notifications, such as during incident response or a maintenance window.

Note
Silences are assigned to a specific Alertmanager and only suppress notifications for alerts managed by that Alertmanager.

In Grafana Cloud, the standalone Alertmanager UI is deprecated and no longer available. Manage silences here in the Grafana Alerting UI instead. For details, refer to Configure Alertmanagers.

Mute timings and active time intervals vs silences

The following table highlights the key differences between mute timings and silences.

	Mute timing	Silence
Setup	Created and then added to notification policies	Matches alerts using labels to determine whether to silence them
Period	Uses time interval definitions that can repeat periodically	Has a fixed start and end time

Add silences

To add a silence, complete the following steps.

In the left-side menu, click Alerts & IRM and then Alerting.
Click Silences.
From the Alertmanager dropdown, select an external Alertmanager to create and manage silences for the external data source. Otherwise, keep the default option of Grafana.
Click Create silence to open the Create silence page.
In Silence start and end, select the start and end date to indicate when the silence should go into effect and expire.
Optionally, in Duration, specify how long the silence is enforced. This automatically updates the end time in the Silence start and end field.

In the Label and Value fields, enter one or more Matching Labels to determine which alerts the silence applies to.

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 matcher 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`	`=~`	`^$`

Any matching alerts (in the firing state only) display under Affected alert instances.

In Comment, add details about the silence.
Click Submit.

Edit silences

To edit a silence, complete the following steps.

In the left-side menu, click Alerts & IRM and then Alerting.
Click Silences to view the list of existing silences.
Find the silence you want to edit, then click Edit (pen icon).
Make the desired changes, then click Submit to save your changes.

Remove silences

To remove a silence, complete the following steps.

In the left-side menu, click Alerts & IRM and then Alerting.
Click Silences to view the list of existing silences.
Select the silence you want to end, then click Unsilence.

Note
Clicking Unsilence ends the silence immediately, which is the only way to end a silence before its configured end time. Silences cannot be permanently deleted manually.

Silence duration and retention

Duration limits

There is no maximum duration for a silence. You can create a silence for any length of time. However, administrators can configure the following limits:

alertmanager_max_silences_count: Maximum number of active and pending silences per tenant (default: 0, no limit), expired silences are also counted.
alertmanager_max_silence_size_bytes: Maximum size of a silence in bytes (default: 0, no limit).

Expired silence retention

Expired silences are automatically deleted after 5 days. This retention period is not configurable. The cleanup process runs automatically every 15 minutes to remove expired silences that are older than the retention period.

Rule-specific silences

Rule-specific silences are silences that apply only to a specific alert rule. They’re created when you silence an alert rule directly using the Silence notifications action in the UI.

As opposed to general silences, rule-specific silence access is tied directly to the alert rule they act on. They can be created manually by including the specific label matcher: __alert_rule_uid__=<alert rule UID>.

URL link to a silence form

Default notification messages often include a link to silence alerts.

In custom notification templates, you can use .Alert.SilenceURL to redirect users to the UI where they can silence the given alert.

If .Alert.SilenceURL doesn’t fit your specific use case, you can also create a custom silence link for your custom templates.

Inhibition rules

Inhibition rules suppress notifications for target alerts when a related source alert is already firing. For more information, refer to Configure inhibition rules.

Configure inhibition rules

Tue, 27 Oct 2026 11:15:42 +0000

Configure inhibition rules

Note
Available in Grafana 13 or higher.

An inhibition rule suppresses notifications for target alerts when source alerts with matching label values are already firing. This lets you reduce noise when a root-cause alert makes dependent alerts redundant.

For example, if a node is down (the source), you can inhibit all alerts for services running on that node (the target). This prevents your team from receiving individual alerts for each affected service when the underlying cause is already captured in the source alert.

Note
Inhibition rules are assigned to a specific Alertmanager and only suppress notifications for alerts managed by that Alertmanager.

Caution
Inhibition rules are intended for compatibility with configurations imported from Prometheus Alertmanager or Mimir. They have no dedicated management UI in Grafana by design.

If not carefully configured, inhibition rules can silently suppress alerts and make issues harder to detect. Consider silences or mute timings for most suppression use cases.

Inhibition rules vs silences

Both inhibition rules and silences suppress alert notifications. The key difference is that inhibition rules suppress alerts automatically based on the presence of another alert, while silences suppress alerts for a fixed time window regardless of other alerts.

	Inhibition rule	Silence
Trigger	Active when a matching source alert is firing	Active during a configured time window
Duration	Lasts as long as the source alert fires	Has a fixed start and end time
Setup	Defined as a persistent configuration	Created manually per occurrence

Manage inhibition rules

You can manage inhibition rules by using the Grafana App Platform API. There is no dedicated UI for creating or editing inhibition rules.

The API resource is:

Group: notifications.alerting.grafana.app
Version: v1beta1
Resource: inhibitionrules

Caution
The inhibition rules API is in beta (v1beta1) and is subject to change.

Inhibition rules are also supported in the Prometheus Alertmanager. Refer to Configure Alertmanager to set up an external Alertmanager.

Inhibition rule schema

Each inhibition rule has the following fields:

Field	Required	Description
`name`	Yes	Unique name for the inhibition rule. Immutable after creation.
`source_matchers`	Yes	One or more matchers that identify source (inhibiting) alerts.
`target_matchers`	Yes	One or more matchers that identify target (inhibited) alerts.
`equal`	No	Labels that must have equal values in both source and target alerts for the inhibition to take effect.

Matcher format

Both source_matchers and target_matchers are lists of structured matcher objects. Each matcher has:

Field	Description
`label`	The name of the label to match against.
`type`	The matching operator. One of `=`, `!=`, `=~`, `!~`.
`value`	The value to match against. For `=~` and `!~`, this is a regular expression.

Operator	Description
`=`	Select alerts where the label equals the value.
`!=`	Select alerts where the label does not equal the value.
`=~`	Select alerts where the label matches the regular expression.
`!~`	Select alerts where the label does not match the regular expression.

The `equal` field

When equal is specified, the inhibition only applies when the source and target alerts have the same value for each listed label. For example, setting equal: [cluster] ensures that an alert in one cluster only inhibits alerts in the same cluster.

If equal is omitted, any firing source alert matching source_matchers inhibits all matching target alerts regardless of their label values.

Missing labels and empty-value labels are treated as equivalent for the purpose of equal matching.

Example: suppress warning alerts

The following example defines an inhibition rule that suppresses all warning-severity alerts in a cluster when a critical-severity alert is already firing for the same cluster.

{
  "name": "critical-inhibits-warnings",
  "source_matchers": [{ "label": "severity", "type": "=", "value": "critical" }],
  "target_matchers": [{ "label": "severity", "type": "=", "value": "warning" }],
  "equal": ["cluster", "namespace"]
}

In this example:

The source matcher selects critical alerts. When one fires, the rule becomes active.
The target matcher selects warning alerts. The rule suppresses these while the source alert fires.
The equal field ensures suppression only applies when source and target share the same cluster and namespace label values.

Inhibition rules and managed routes

An Alertmanager can serve multiple routing trees: the default Grafana-managed route and any routes imported from Prometheus Alertmanager or Mimir configurations. Inhibition rules behave differently depending on how each rule is created:

Grafana-managed rules are created through the API and apply across the entire Alertmanager. They can match alerts handled by any route, including imported routes.
Imported rules come from an imported Alertmanager configuration and are scoped to the alerts handled by their imported route. Grafana adds an internal label matcher that limits each imported rule to its own imported route, so an imported rule can’t suppress alerts that flow through other routes.

To suppress alerts across multiple imported configurations, create a Grafana-managed rule through the API instead of relying on the inhibition rules embedded in an imported configuration.

Template notifications

Tue, 27 Oct 2026 11:15:42 +0000

Template notifications

You can use notification templates to change the title, message, and format of notifications.

Grafana provides a default template for notification titles (default.title) and one default template for notification messages (default.message). Both templates display common alert details.

You can also create a notification template to customize the content and format of your notification messages. For example:

Personalize the subject of an email or the title of a message.
Modify text within notifications, like selecting or omitting certain labels, annotations, and links.
Format text with bold and italic styles, and add or remove line breaks.

However, there are limitations. You cannot:

Modify Visual Appearance: Add HTML or CSS to email notifications for visual changes. Alter the design of notifications in messaging services like Slack or Microsoft Teams, such as adding custom blocks or adaptive cards.
Manage Media and Data: Customize the data structure or format passed to the templates, like adding new JSON fields or sending XML data for webhooks. Modify HTTP headers in webhooks beyond those defined in the configuration, or adjust the number, size, or placement of images.

In Grafana Cloud, you can create up to 30 notification templates by default. Template changes can take 1 to 2 minutes to take effect while a background job synchronizes them with storage.

Here’s an example that displays the summary and description annotations for each alert in the notification:

{{ define "custom.alerts" -}}
{{ len .Alerts }} alert(s)
{{ range .Alerts -}}
  {{ template "alert.summary_and_description" . -}}
{{ end -}}
{{ end -}}
{{ define "alert.summary_and_description" }}
  Summary: {{.Annotations.summary}}
  Status: {{ .Status }}
  Description: {{.Annotations.description}}
{{ end -}}

The notification message would look like this:

2 alert(s)

  Summary: The database server db1 has exceeded 75% of available disk space.
  Status: firing
  Description: This alert fires when a database server is at risk of running out of disk space. You should take measures to increase the maximum available disk space as soon as possible to avoid possible corruption.

  Summary: The web server web1 has been responding to 5% of HTTP requests with 5xx errors for the last 5 minutes.
  Status: resolved
  Description: This alert fires when a web server responds with more 5xx errors than expected. This could be an issue with the web server or a backend service.

Note
Avoid adding extra information about alert instances in notification templates, as this information will only be visible in the notification message.

Instead, you should use annotations or labels to add information directly to the alert, ensuring it’s also visible in the alert state and alert history within Grafana. You can then print the new alert annotation or label in notification templates.

Select a notification template for a contact point

Notification templates are not tied to specific contact point integrations, such as email or Slack, and the same template can be shared across multiple contact points.

The notification template is assigned to the contact point to determine the notification message sent to contact point integrations.

By default, Grafana provides default templates, such as {{define "default.title"}} and {{define "default.message"}}, to format notification messages.

Grafana Cloud AI-generated templates

Grafana Cloud users can use built-in AI tool to generate templates in the appropriate alerting template language for you.

To use AI to create your template, follow these steps:

Go to Alerting -> Contact points.
Click the Notification Templates tab then, click the + New notification template button.
Name your template.
In the Template group section, click the Generate with AI button.
Supply the AI tool with a prompt or select from one of the example prompts and edit that if necessary.
Click Save.

More information

For further details on how to write notification templates, refer to:

Tip
For a practical example of templating, refer to our Getting Started with Templating tutorial.

Import Alertmanager configuration to Grafana-managed notifications

Tue, 27 Oct 2026 11:15:42 +0000

Import Alertmanager configuration to Grafana-managed notifications

You can import an existing Prometheus or Mimir Alertmanager configuration into Grafana Alerting. Grafana runs the imported receivers as Mimir Alertmanager v0 integrations and surfaces the configuration as Grafana notification resources: contact points, a notification policy tree, notification templates, time intervals, and inhibition rules. You operate your notification setup from Grafana.

Importing is a safe operation. The source Alertmanager keeps its configuration, and Grafana never writes back to it.

The import happens in two stages:

Stage: Grafana keeps the imported configuration as a unit of its own and combines it with your Grafana resources at runtime.
Promote: Grafana merges the imported configuration permanently into your Grafana configuration. Every imported resource becomes a normal, editable Grafana resource, and you can no longer revert the import in one action.

Because Grafana keeps the staged configuration separate, you can revert or re-import it all at once instead of resource by resource. Its resources are read-only, and no Grafana resource can reference them. The imported policy tree is the exception: an alert rule can route to it by name. Until a rule does, your existing notifications are unchanged.

Note
Importing Alertmanager configuration is in public preview. The API is behind the alertingImportAlertmanagerAPI feature toggle and the user interface is behind alertingMigrationWizardUI. Both are disabled by default. In Grafana Cloud, contact Support to enable them.

Before you begin

Before you import an Alertmanager configuration, make sure you have the following:

A source Grafana can read: A configuration YAML file with its template files, or a configured Mimir Alertmanager data source. Prometheus Alertmanager data sources aren’t supported.
Permissions: Creating, reading, updating, or deleting an import requires the corresponding scoped Alertmanager import permissions. Promoting an import requires read and delete permissions for the import, create permissions for contact points and notification policy trees, and write permissions for any notification templates, time intervals, and inhibition rules in the configuration. The Admin role has these permissions by default. For more details, refer to RBAC permissions.

Not every Alertmanager configuration can be imported as-is. Refer to limitations before you start.

How it works

Grafana imports the configuration as it is and evaluates it the way your source Alertmanager does, for configurations from supported versions. Receivers keep their Alertmanager fields, and they notify with the same logic and message format, because Grafana runs them as Mimir-compatible integrations instead of rewriting them into native Grafana ones.

Mimir-compatible integrations don’t offer what a native Grafana integration adds on top, such as images in notifications. To use those features, promote the import and then rebuild the contact point as a Grafana one.

What gets imported

Grafana imports every field of the configuration: receivers, the routing tree, template files, time intervals, and inhibition rules. Fields keep their names and values, apart from the renames described in name conflicts. Both time_intervals and the deprecated mute_time_intervals become time intervals.

The global section is the one part with no place of its own. Grafana resolves its values into the settings of each integration that relies on them as the configuration is parsed, so the defaults you set globally still apply.

Routing

Grafana adds the imported routing tree as a named policy tree of its own, alongside your default notification policy and any other named policy trees. Alerts reach it only when an alert rule routes to it by name. The matchers inside the imported tree then route those alerts the way they did in your source Alertmanager. For more details on serving more than one policy tree, refer to manage multiple notification policies.

If the imported root route leaves group_wait, group_interval, or repeat_interval unset, Grafana uses the default notification timing values.

You choose the tree name when you import. This name is also the identifier of the import, so pick something you recognize, such as mimir-prod. The name can’t be default or match another named policy tree. It must be a valid DNS subdomain name and is length-limited; for more details, refer to limitations.

Name conflicts

Contact points, time intervals, and notification templates are identified by name, and the imported configuration may reuse names that already exist. Rather than fail or overwrite, Grafana renames the incoming resource:

Grafana appends _ and the import identifier to the name, for example default becomes default_mimir-prod.
If that name is also taken, Grafana appends a number, for example default_mimir-prod_01.

All references to a renamed resource are updated throughout the imported configuration, so routing still points at the right contact point.

Templates count conflicts differently. An imported template never conflicts with a Grafana-managed template of the same name, only with a template from another imported configuration. For more details, refer to limitations.

Staged resources are read-only

While an import is staged, its resources appear with an Imported status in the Grafana Alerting user interface and in the notification APIs, and you can’t edit or delete them individually. The deprecated provisioning API is the exception: it doesn’t return them at all.

You also can’t reference an imported resource from a Grafana resource. For example, you can’t pick an imported contact point in a Grafana notification policy. The imported policy tree is the exception: an alert rule can route to it by name while the import is staged.

To make imported resources editable and available for reference, promote the import.

One import at a time

Grafana stores one imported configuration per organization. Before you stage another configuration, promote or revert the existing one. You can also explicitly replace the existing configuration during import.

Import with the Grafana Alerting user interface

The Grafana Alerting user interface imports notification resources and alert rules in one flow. It requires both the alertingImportAlertmanagerAPI and alertingMigrationWizardUI feature toggles.

Go to Alerting > Alert rules.
In the More menu, click Import to Grafana Alerting.
Choose how the resources are added:
- Stage brings the configuration in as a read-only, reversible copy.
- Promote merges the configuration into your live configuration immediately. This can’t be undone. To reverse it, you have to delete each resulting resource by hand.
Click Next.
On the Import notification resources step, choose the Import source:
- Alertmanager config YAML uploads a configuration file. Optionally, upload the template files the configuration references. Each file is imported as a template named after the file.
- Alertmanager data source reads the configuration from a configured Alertmanager data source.
Enter a Policy tree name.

Grafana validates the configuration as you fill in the form and reports any conflicts. The form lists the resources that Grafana renames before you import.
Click Next, and either configure the alert rules import or skip the step.
Review the summary, then click Start import.

Auto-sync an Alertmanager configuration

Auto-sync keeps a staged notification configuration up to date with a Mimir or Cortex Alertmanager data source. Grafana periodically reads the source configuration and applies changes to the staged resources without writing back to the source. Auto-sync doesn’t import or synchronize alert rules.

Note
Auto-sync is in private preview. The alerting.syncExternalAlertmanager feature toggle is disabled by default and requires a Grafana restart when enabled. To access Settings > Import, also enable alertingMigrationWizardUI. In Grafana Cloud, contact Support to request access.

Enable auto-sync

Before you begin, configure a Mimir or Cortex Alertmanager data source. Auto-sync supports only these data sources. If a staged configuration with a different identifier already exists, promote or revert it first.

You need the following permissions, scoped to configs:uid:default:

notifications.alerting.grafana.app/configs:get to read the configuration and sync status.
notifications.alerting.grafana.app/configs:update to enable or disable auto-sync.

Organization administrators have these permissions by default. You can also grant them through RBAC.

Go to Alerting > Settings.
Click the Import tab.
In Auto-sync configuration, select the Alertmanager data source.
Click Save.

Grafana uses the data source UID as the import identifier and notification policy tree name. The imported resources remain read-only while staged. To send notifications through the imported policy tree, route your Grafana-managed alert rules to that tree. Use the data source UID as the routing tree name.

The Auto-sync configuration section shows the sync status and any errors from the last sync attempt. If Grafana can’t fetch or validate an update, it keeps the configuration from the last successful sync.

Stop auto-sync or promote the configuration

While auto-sync is configured, you can’t manually import another notification configuration, and the user interface hides Revert for the sync-managed configuration. You can still import alert rules separately.

To stop synchronization, click Disable sync in Auto-sync configuration and confirm. Disabling sync doesn’t delete the staged configuration. You can then review, promote, or revert it.

Promoting the sync-managed configuration stops synchronization from that data source.

If Auto-sync configuration shows Managed by operator, you can’t change the setting through the user interface. In Grafana Cloud, contact Support to change or disable auto-sync.

Import with the API

The Alertmanager import endpoints are compatible with the Mimir Alertmanager HTTP API, so you can use mimirtool or plain HTTP requests.

In these endpoints, an import is addressed by its identifier, which is set with the X-Grafana-Alerting-Config-Identifier header and defaults to imported.

Method	Endpoint	Summary
POST	`/api/convert/api/v1/alerts`	Import an Alertmanager configuration, optionally promoting it in the same request.
GET	`/api/convert/api/v1/alerts`	Get the staged configuration. Secrets are masked.
DELETE	`/api/convert/api/v1/alerts`	Delete the staged configuration. The Grafana configuration is unaffected.
POST	`/api/convert/api/v1/alerts/{Identifier}/promote`	Promote a staged configuration into the Grafana configuration.

The POST endpoint accepts YAML and JSON. If no media type is specified, YAML is assumed. The request body has the same shape as the Mimir Alertmanager configuration API:

template_files:
  default.tmpl: '{{ define "custom" }}Custom message{{ end }}'
alertmanager_config: |
  route:
    receiver: webhook
  receivers:
    - name: webhook
      webhook_configs:
        - url: 'https://example.com/webhook'

A successful import returns the merge result:

{
  "status": "success",
  "stats": {
    "added_route": "mimir-prod",
    "added_receivers": ["webhook"],
    "added_templates": ["default.tmpl"]
  }
}

Configure auto-sync and read its status

Auto-sync uses a dedicated notification configuration API. Use credentials with the auto-sync permissions.

Note
Enable the alerting.syncExternalAlertmanager feature toggle before using this API. For availability and restart requirements, refer to Auto-sync an Alertmanager configuration.

The configuration is a per-organization resource named default. Grafana creates it automatically.

Read the configuration and status with GET /apis/notifications.alerting.grafana.app/v0alpha1/namespaces/{namespace}/configs/default:

curl \
  -H "Authorization: Bearer <SERVICE_ACCOUNT_TOKEN>" \
  "<GRAFANA_BASE_URL>/apis/notifications.alerting.grafana.app/v0alpha1/namespaces/<NAMESPACE>/configs/default"

Replace the following placeholders in these examples:

<GRAFANA_BASE_URL>: The base URL of your Grafana instance.
<SERVICE_ACCOUNT_TOKEN>: A service account token with the required configuration permissions.
<NAMESPACE>: The API namespace for your Grafana organization.
<DATASOURCE_UID>: The UID of the Mimir or Cortex Alertmanager data source to synchronize.

Enable auto-sync with PATCH /apis/notifications.alerting.grafana.app/v0alpha1/namespaces/{namespace}/configs/default. Set spec.externalAlertmanagerSync.datasourceUid with a JSON patch:

curl -X PATCH \
  -H "Authorization: Bearer <SERVICE_ACCOUNT_TOKEN>" \
  -H "Content-Type: application/json-patch+json" \
  "<GRAFANA_BASE_URL>/apis/notifications.alerting.grafana.app/v0alpha1/namespaces/<NAMESPACE>/configs/default" \
  --data '[{"op":"add","path":"/spec/externalAlertmanagerSync","value":{"datasourceUid":"<DATASOURCE_UID>"}}]'

A successful patch saves the setting; it doesn’t mean the first sync has completed. Read the resource again to inspect these status fields:

status.externalAlertmanagerSync.datasourceUid: The data source UID used on the last sync attempt.
status.externalAlertmanagerSync.origin: Whether the source is configured through the API or managed by an operator. For an operator-managed source in Grafana Cloud, contact Support to change or disable it.
status.conditions: Find the condition with type set to ExternalAlertmanagerSynced. Its status is True after a successful sync, False after a failed attempt, or Unknown when no sync is configured. Read reason and message for details. The MergeCommitted reason means the configuration was promoted and synchronization has stopped.

Status updates are asynchronous and can lag behind configuration changes.

To disable an API-configured sync, clear the setting with the same PATCH endpoint:

curl -X PATCH \
  -H "Authorization: Bearer <SERVICE_ACCOUNT_TOKEN>" \
  -H "Content-Type: application/json-patch+json" \
  "<GRAFANA_BASE_URL>/apis/notifications.alerting.grafana.app/v0alpha1/namespaces/<NAMESPACE>/configs/default" \
  --data '[{"op":"add","path":"/spec/externalAlertmanagerSync","value":{}}]'

Clearing the setting stops future synchronization but doesn’t delete the staged notification resources. It doesn’t override an operator-managed source. Read the status again to confirm that synchronization is no longer configured. Don’t delete the default configuration resource or write its status; Grafana manages both its lifecycle and status.

Optional headers

Use these headers for more granular import control:

`X-Grafana-Alerting-Config-Identifier`

The identifier of the import, which is also the name of the notification policy tree it creates. It must be a valid DNS subdomain name of at most 40 characters, using only lowercase alphanumeric characters, -, and .. Defaults to imported.

`X-Grafana-Alerting-Dry-Run`

Set to true to validate the configuration and report the merge result without saving anything. Use this to preview renames before importing.

`X-Grafana-Alerting-Promote`

Set to true to promote the configuration in the same request instead of staging it. Combine it with X-Grafana-Alerting-Dry-Run to preview what a promotion merges into the live configuration.

`X-Grafana-Alerting-Config-Force-Replace`

Set to true to replace an existing staged configuration that has a different identifier. Without it, importing a second configuration fails.

`mimirtool`

Use mimirtool alertmanager load to import a configuration and its template files:

MIMIR_ADDRESS=<GRAFANA_BASE_URL>/api/convert/ \
MIMIR_AUTH_TOKEN=<SERVICE_ACCOUNT_TOKEN> \
MIMIR_TENANT_ID=1 \
mimirtool alertmanager load alertmanager.yaml default.tmpl \
  --extra-headers "X-Grafana-Alerting-Config-Identifier=mimir-prod"

Replace the following placeholders:

<GRAFANA_BASE_URL>: The base URL of your Grafana instance.
<SERVICE_ACCOUNT_TOKEN>: A service account token with permission to import notification resources.

When the address points at <GRAFANA_BASE_URL>/api/convert/, mimirtool talks to Grafana rather than to a Mimir instance, so MIMIR_TENANT_ID must always be 1.

mimirtool alertmanager get and mimirtool alertmanager delete read and remove the staged configuration in the same way.

Promote a staged configuration

To promote a configuration that’s already staged, call the promote endpoint with its identifier:

curl -X POST \
  -H "Authorization: Bearer <SERVICE_ACCOUNT_TOKEN>" \
  <GRAFANA_BASE_URL>/api/convert/api/v1/alerts/mimir-prod/promote

After promotion, the staged configuration no longer exists. Its resources are part of the Grafana configuration. You can edit them through the regular notification APIs and user interface.

Review, promote, or revert a staged configuration

Staged configurations are managed in Grafana Alerting settings.

Go to Alerting > Settings.
Click the Import tab.

The Staged configuration section lists the contact points, notification policies, templates, time intervals, and inhibition rules the import contains, and links to each resource so you can inspect it before promoting.

To discard the import and everything it added, click Revert. Your Grafana configuration is unaffected. For a configuration managed by auto-sync, disable auto-sync before reverting. The user interface hides Revert while auto-sync is active. Deleting the staged configuration through the API doesn’t disable auto-sync: Grafana can import it again when the source configuration changes or Grafana restarts.

Warning
Reverting deletes the imported notification policy tree. Alert rules that route to that tree lose their target, and their alerts fall back to the root of your default notification policy. Update those rules to point elsewhere before you revert.

Limitations

Consider the following when you import an Alertmanager configuration:

Mimir version: Grafana supports notification configuration imports from Grafana Mimir up to 3.0.x. Later Mimir versions can use integrations and fields that the imported receivers don’t support.
Prometheus Alertmanager version: Grafana supports notification configuration imports from Prometheus Alertmanager up to v0.27. Later versions add integrations and fields that the imported receivers don’t support.
Unsupported receiver fields: Integration fields that read their values from elsewhere, including every *_file and *_ref variant, have no equivalent in Grafana. Grafana rejects a configuration that contains one, so nothing is imported. Supply the value inline in the matching field instead, and drop the _file or _ref variant.
Data source support: Grafana reads a configuration from a Mimir Alertmanager data source. Upstream Prometheus Alertmanager doesn’t expose a configuration API, so those data sources aren’t supported. Import a configuration YAML file instead.
Global settings: After you promote an import, the global section no longer exists as a section of its own. Grafana has resolved its values into each integration setting that relies on them, so a promoted contact point carries the resolved value rather than a reference to global.
Policy tree name: The name of the imported policy tree, which is also the import identifier, must be a valid DNS subdomain name of at most 40 characters, using only lowercase alphanumeric characters, -, and ..
One staged configuration at a time: Grafana stores one staged configuration per organization. Before you stage another configuration, promote or revert the existing one. You can also explicitly replace the existing configuration during import.
Template name conflicts across imports: Grafana renames colliding template files, but the templates defined inside those files share one namespace. Say an earlier import defines a template called default.email that renders X, and a new import defines default.email again, in a file under a different name, rendering Y. Which definition wins isn’t deterministic, and every contact point that uses that template gets the winner. As a result, contact points from the earlier import can start sending the wrong content. Check the names of the templates you define, not just the filenames, before you import a second configuration.
Deprecated provisioning API: A staged configuration isn’t visible in the deprecated provisioning API, which doesn’t return its contact points, templates, or time intervals. Use the Grafana Alerting notification API (notifications.alerting.grafana.app) instead.
Inhibition rules: Imported inhibition rules are supported through the API only. There’s no user interface for creating or editing them. For more details, refer to configure inhibition rules.

Next steps

After you import your notification configuration:

Import your data source-managed alert rules and route them through the imported policy tree.
Review the imported contact points, notification policies, templates, and time intervals.

Configure notifications on Grafana Labs

Configure contact points

Configure contact points

Protected fields

Supported contact point integrations

Allowlist notification source IP addresses

Add a contact point

Add another contact point integration

Customize notification messages

Test a contact point

Enable notifications for a contact point

Troubleshoot notification delivery

Configure notification policies

Configure notification policies

Edit the default notification policy

Add a child policy

Add a sibling policy

Search for policies

Mute timings

Manage multiple notification policy trees

Example

Configure mute timings and active time intervals

Configure mute timings and active time intervals

Mute timings and active time intervals vs silences

Add time intervals

Assign a time interval to a notification policy

Time intervals

Configure silences

Configure silences

Mute timings and active time intervals vs silences

Add silences

Edit silences

Remove silences

Silence duration and retention

Rule-specific silences

URL link to a silence form

Inhibition rules

Configure inhibition rules

Configure inhibition rules

Inhibition rules vs silences

Manage inhibition rules

Inhibition rule schema

Matcher format

The equal field

Example: suppress warning alerts

Inhibition rules and managed routes

Template notifications

Template notifications

Select a notification template for a contact point

Grafana Cloud AI-generated templates

More information

Import Alertmanager configuration to Grafana-managed notifications

Import Alertmanager configuration to Grafana-managed notifications

Before you begin

How it works

What gets imported

Routing

Name conflicts

Staged resources are read-only

One import at a time

Import with the Grafana Alerting user interface

Auto-sync an Alertmanager configuration

Enable auto-sync

Stop auto-sync or promote the configuration

Import with the API

Configure auto-sync and read its status

Optional headers

X-Grafana-Alerting-Config-Identifier

X-Grafana-Alerting-Dry-Run

X-Grafana-Alerting-Promote

X-Grafana-Alerting-Config-Force-Replace

mimirtool

Promote a staged configuration

Review, promote, or revert a staged configuration

Limitations

Next steps

The `equal` field

`X-Grafana-Alerting-Config-Identifier`

`X-Grafana-Alerting-Dry-Run`

`X-Grafana-Alerting-Promote`

`X-Grafana-Alerting-Config-Force-Replace`

`mimirtool`