Configure alert rules on Grafana Labs

Configure Grafana-managed alert rules

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

Caution
Pre-provisioned Loki and Prometheus data source-managed alerts have been deprecated in Grafana Cloud and can not be created in new stacks. New Grafana Cloud stacks will use Grafana-managed alerting (GMA) by default. Datasource-managed alerting (DMA) is not provisioned in new stacks. Existing stacks are not affected.

This applies to the default Loki and Prometheus Grafana Cloud data sources managed by Grafana Labs and Cloud Alertmanager, which will not be available nor will Grafana provision the data source for it. If you add your own Mimir, Loki, or Alertmanager data sources, you can continue to use data source-managed alerts.

Cloud users can import DMA rules into GMA rules with the import tool. See the import data source-managed alerts to Grafana-managed alerts documentation for information on how to do this.

Configure Grafana-managed alert rules

Grafana-managed alert rules are the default way to create alert rules in Grafana.

Grafana-managed rules inherit their model from Prometheus Alerting and extend it with greater flexibility—such as multi-data source queries, expression-based transformations, advanced alert conditions, images in notifications, custom states, and more.

To create or edit Grafana-managed alert rules, follow the instructions below.

Tip
For quick-start tutorials on key alerting features, see Getting started with Grafana Alerting tutorials.

Before you begin

Before you create Grafana-managed alert rules, review the following requirements and options.

Supported data sources

Grafana-managed alert rules can query backend data sources when the data source’s plugin.json file sets {"backend": true, "alerting": true}.

Before you create an alert rule, verify that the data sources you plan to query are compatible and properly configured.

You can find the public data sources that support alert rules in the Grafana Plugins directory.

Alert rule limits in Grafana Cloud

In Grafana Cloud, the number of Grafana-managed alert rules you can create depends on your Grafana Cloud plan.

Free Forever plan: You can create up to 500 free alert rules, with each alert rule having a maximum of 1000 alert instances.
All paid plans: They have a soft limit of 2000 alert rules and support unlimited alert instances. To increase the limit, open a support ticket from the Cloud portal.

Permissions

Only users with Edit permissions for the folder storing the rules can edit or delete Grafana-managed alert rules. Only admins can restore deleted Grafana-managed alert rules.

Provisioning

Note that if you delete an alert resource created in the UI, you can no longer retrieve it.

To backup and manage alert rules, you can provision alerting resources using options such as configuration files, Terraform, or the Alerting API.

Default versus Advanced options

Grafana Alerting provides multiple configuration options to support different alerting needs.

To simplify alert rule creation, some settings display a Default and an Advanced configuration view:

Use Default to create basic query conditions and route alerts directly to a contact point. Use Advanced for more complex query definitions, or to route alerts using notification policies.

You can switch between options at any time. After you create an alert rule, Grafana remembers your last selection and uses it as the default for the next rule.

Set alert rule name

Click Alerts & IRM -> Alert rules -> + New alert rule.
Enter a name to identify your alert rule.

This name is displayed in the alert rule list. It is also the alertname label for every alert instance that is created from this rule.

Define query and condition

Define a query to get the data you want to measure and a condition that needs to be met before an alert rule fires.

Depending on the data source, the query editor offers a Builder and a Code option. Builder helps you construct a query with a visual interface. The Builder option is useful if you have limited experience with the query language, while Code lets you write the query directly for more control. Switch between them using the Builder and Code tabs on the query editor toolbar.

The Default option allows you to configure one query and one alert condition. The Advanced option allows you to use multiple queries and expressions for more complex rule definitions.

You can switch between Default and Advanced options at any time.

Switching from Advanced to Default may result in queries and expressions that can’t be converted. In this case, a warning message asks if you want to continue to reset to default settings.

If the Default versus Advanced options feature is not enabled in your Grafana instance, follow the Advanced options instructions.

Set folder and labels

Organize your alert rule with a folder and set of labels.

In the Labels section, you can optionally choose whether to add labels to organize your alert rules and their notifications. For more details, refer to alert rule labels.

Select a folder or click + New folder.
Add labels, if required.

Add custom labels by selecting existing key-value pairs from the drop down, or add new labels by entering the new key or value.

Configure alert evaluation behavior

Use alert rule evaluation to determine how frequently an alert rule should be evaluated and how quickly it should change its state.

To do this, you need to make sure that your alert rule is in the right evaluation group and set a pending period time that works best for your use case.

Select an evaluation group or click + New evaluation group.

If you are creating a new evaluation group, specify the interval for the group.

All rules within the same group are evaluated concurrently over the same time interval.
Enter a pending period.

The pending period is the period in which an alert rule can be in breach of the condition until it fires.

After a condition is met, the alert goes into the Pending state. If the condition remains active for the duration specified, the alert transitions to the Firing state, else it reverts to the Normal state.
Optionally, set the Keep firing for period.

You can set the minimum amount of time that an alert remains firing after the breached threshold expression no longer returns any results. This sets an alert to a “Recovering” state for the duration of time set here. The Recovering state can be used to reduce noise from flapping alerts. Select “none” to stop an alert from firing immediately after the breach threshold is cleared.
Turn on pause alert notifications, if required.

You can pause alert rule evaluation to prevent noisy alerting while tuning your alerts. Pausing stops alert rule evaluation and doesn’t create any alert instances. This is different from mute timings, which stop notifications from being delivered, but still allow for alert rule evaluation and the creation of alert instances.
In Configure no data and error handling, you can define the alerting behavior and alerting state for two scenarios:
- When the evaluation returns No data or all values are null.
- When the evaluation returns Error or timeout.
Configure no data and error handling

Configure the behavior when the evaluation returns no data:
- Set No Data state (Default)
  
  If the pending period is 0, the alert instance transitions immediately to No Data. Otherwise, it transitions to the Pending state, and then to No Data after the pending period has elapsed and the last evaluation returns no data.
  
  When entering the No Data state, the alert rule creates a new DatasourceNoData alert instance with labels for the alert rule name, UID, and data source UID.
- Set Alerting state
  
  If the pending period is 0, the alert instance transitions immediately to Alerting. Otherwise, it transitions to the Pending state, and then to Alerting after the pending period has elapsed and the last evaluation returns no data or a threshold breach.
- Set Normal state
  
  The alert instance transitions immediately to the Normal state.
- Keep last state
  
  The alert instance keeps its current state.
You can also configure the behavior when the evaluation returns an error:
- Set Error state (Default)
  
  If the pending period is 0, the alert instance transitions immediately to Error. Otherwise, it transitions to the Pending state, and then to Error after the pending period has elapsed and the last evaluation returns an error.
  
  When entering the Error state, the alert rule creates a new DatasourceError alert instance with labels for the alert rule name, UID, and data source UID.
- Set Alerting state
  
  If the pending period is 0, the alert instance transitions immediately to Alerting. Otherwise, it transitions to the Pending state, and then to Alerting after the pending period has elapsed and the last evaluation returns an error or a threshold breach.
- Set Normal state
  
  The alert instance transitions immediately to the Normal state.
- Keep last state
  
  The alert instance keeps its current state.
For more details, refer to alert instance states and modify the no data or error state.
In Configure no data and error handling, you can also configure Missing series evaluations to resolve: how many consecutive evaluation intervals must pass without data before an alert instance is considered stale.

Configure notifications

Configure who receives notifications when the alert rule fires.

The Default option allows you to select a contact point to handle notifications for this alert rule. The Advanced option routes notifications through notification policies.

You can switch between Default and Advanced options at any time.

If the Default versus Advanced options feature is not enabled in your Grafana instance, follow the Advanced options instructions.

Configure notification message

Use annotations to add information to alert messages that can help respond to the alert.

Annotations are included by default in notification messages, and can use text or templates to display dynamic data from queries.

Grafana provides several optional annotations.

Optional: Add a summary.

Short summary of what happened and why.
Optional: Add a description.

Description of what the alert rule does.
Optional: Add a Runbook URL.

Webpage where you keep your runbook for the alert
Optional: Add a custom annotation.

Add any additional information that could help address the alert.
Optional: Link dashboard and panel.

Link the alert rule to a panel to facilitate alert investigation.
Click Save rule.

Create and link alert rules to panels

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

Create and link alert rules to panels

Grafana allows you to link an alert rule to a dashboard panel. This can help you:

Inform alert responders about where to investigate and which data to examine.
Visualize the alert state directly from dashboards.
Include a screenshot of the panel in notification messages.

An alert rule is linked to a panel by setting the __dashboardUid__ and __panelId__ annotations. Both annotations must be set together.

Link alert rules to panels

When configuring the alert rule, you can set the dashboard and panel annotations as shown in this video.

Configure the alert rule.
In the Configure notification message section, click Link dashboard and panel.
Select an existing dashboard, then choose a panel from the selected dashboard.
Complete the alert rule configuration and click Save rule to initiate the alert rule.

You can then view the alert state on the panel.

By default, notification messages include a link to the dashboard panel. Additionally, you can enable displaying panel screenshots in notifications.

Create alert rules from panels

To streamline alert creation, you can create an alert rule directly from a panel.

Navigate to a dashboard in the Dashboards section.
Hover over the top-right corner of a panel and click the panel menu icon.
From the dropdown menu, select More… > New alert rule.
This opens the Edit rule form and pre-fills some values:
- Sets the annotations to the corresponding dashboard and panel.
- Sets the alert rule query using the panel query.
Complete the alert rule configuration and click Save rule to initiate the alert rule.

You can then view the alert state on the panel.

By default, notification messages include a link to the dashboard panel. Additionally, you can enable displaying panel screenshots in notifications.

Note
Changes to panel and alert rule queries aren’t synchronized. If you change a query, you have to update it in both the panel and the alert rule.

Access linked alert rules from panels

This option is available only in time series panels. To access alert rules associated to a time series panel, complete the following steps.

Hover over the top-right corner of the panel and click the panel menu icon.
Click Edit.
Click the Alert tab to view existing alert rules or create a new one.

Tip
For a practical example, refer to our Getting started: Link alerts to visualizations tutorial.

Import data source-managed rules to Grafana-managed rules

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

Import data source-managed rules to Grafana-managed rules

You can convert existing alert rules from data sources such as Mimir, Loki, and Prometheus into Grafana-managed alert rules. This enables you to operate and manage these rules using Grafana Alerting.

This guide explains two methods for importing data source-managed rules:

Using the Grafana Alerting user interface to import rules from connected data sources or Prometheus rule YAML files.
Using command-line tools like mimirtool and cortextool to import rules from YAML files.

Importing rules is a safe operation: the original data source–managed rules remain intact in their original location. During import, the rules are converted into Grafana-managed rules while preserving their configuration and behavior.

Choose the method that best fits your workflow. As a best practice, test and validate your import process before migrating all alert rules.

Import your notification configuration first

Rules only tell you about a problem if the notification reaches someone. Grafana-managed rules route through the Grafana Alertmanager, not through the Alertmanager your data source-managed rules used, so imported rules notify through whatever contact points and notification policies already exist in Grafana.

Consider importing your Alertmanager configuration before you import rules. Grafana imports the configuration as it is and runs it the way your Prometheus or Mimir Alertmanager does. You can then route the rules you import through the imported policy tree.

How it works

When you use any of the import methods, data source–managed rules are copied to another folder as Grafana-managed rules.

The original data source–managed rules remain intact in their original location.

The copied rules are converted to Grafana-managed rules, preserving their behavior by using equivalent Grafana-managed features. The following settings are applied during the conversion:

Unique UIDs

The newly created rules are assigned unique UIDs. If you don’t want a UID to be auto-generated, you can specify one using the __grafana_alert_rule_uid__ label.
Query offset

A query offset is applied to each rule. For example, an offset of 1m adjusts the query’s time range to To: now-1m.

The rule query offset is taken from the query_offset value in the rule group configuration. If empty, it defaults to the rule_query_offset configuration setting, which is 1m by default.
Rule query conversion

For alert rules, adds prometheus_math and threshold expressions to preserve Prometheus no data behavior, ensuring the alert stays in Normal state when query returns no data.
Missing series evaluations to resolve

The Missing series evaluations to resolve setting is set to 1 to replicate Prometheus’s alert eviction behavior.
Rule group labels

Labels defined at the rule group level are added as labels to each imported rule within the group.
Sequential evaluation

Imported rules are evaluated sequentially within each rule group, mirroring Prometheus behavior. This differs from native Grafana-managed alert rules, where the evaluation order is not enforced. For more details, refer to evaluation strategies.
Feature compatibility

The rule group limit option and the query function within alert rule templates are not currently supported in Grafana-managed rules. If the limit option is present, the import fails. However, rules with query in templates are imported.

Note
Rules with the label __grafana_origin are not included in rule imports. These rules are typically created by apps such as Kubernetes Monitoring, Synthetic Monitoring, and other Grafana plugins.

Import rules with Grafana Alerting

You can use the Grafana Alerting user interface to import rules from the following sources:

Connected Mimir and Loki data sources with the ruler API enabled
Prometheus YAML rule files

Imported rules using this method are editable in the user interface. Like regular Grafana-managed rules, you can later export them for provisioning.

Before you begin

To use Grafana Alerting to migrate rules, you need the following RBAC permissions:

Alerting: Rules Writer, Set provisioning status.
Datasources: Reader.
Folders: Creator.

The Folders permission is optional and only necessary if you want to create new folders for your target namespace. If your account doesn’t have permissions to view a namespace, the tool creates a new one.

To convert data source-managed alert rules to Grafana managed alerts:

Go to Alerting > Alert rules.
Navigate to the Data source-managed alert rules section and click Import to Grafana-managed rules.
Choose the Import source from which you want to import rules:
- Select Existing data source-managed rules to import rules from connected Mimir or Loki data sources with the ruler API enabled.
- Select Prometheus YAML file to import rules by uploading a Prometheus YAML rule file.
In the Data source dropdown, select the data source that the imported alert rules will query.
(Optional) In Additional settings, select a target folder or designate a new folder to import the rules into.

If you import the rules into an existing folder, don’t choose a folder with existing alert rules, as they could get overwritten.
(Optional) Select a Namespace and/or Group to determine which rules are imported.
(Optional) Turn on Pause imported alerting rules.

Pausing stops alert rule evaluation and doesn’t create any alert instances for the newly created Grafana-managed alert rules.
(Optional) Turn on Pause imported recording rules.

Pausing stops alert rule evaluation behavior for the newly created Grafana-managed alert rules.
(Optional) In the Target data source of the Recording rules section, you can select the data source to which the imported recording rules will write metrics. By default, it is the data source selected in the Data source dropdown.
Click Import.

A preview shows the rules that will be imported. If your target folder contains folders with the same name of the imported folders, a warning displays to inform you. You can explore the warning to see a list of folders that might be overwritten.

Click Yes, import to import the rules.

Import rules with command-line tools

You can also use command-line tools to import data source-managed rules as Grafana-managed rules: use mimirtool for Mimir and Prometheus rules, and cortextool for Loki rules.

Both tools provide rules commands to import rules groups. For example:

rules load can import rule groups from files.
rules sync can read rule files and applies only the differences compared to existing Grafana-managed rules. This is useful for automation workflows and pipelines.

By default, rules imported using the API or command-line tools are Provisioned and not editable in the user interface. To make them editable, enable the X-Disable-Provenance header.

Before you begin

You need to have installed mimirtool or cortextool (version 0.11.3 or later).

You need a service account with the following RBAC permissions:

Alerting: Rules Reader, Rules Writer, Set provisioning status.
Datasources: Reader.
Folders: Creator, Reader, Writer.

You need to a service account token with your service account. For more details, refer to service accounts and service account tokens.

mimirtool

To convert and import them into a Grafana instance, you can use the mimirtool rules load command:

MIMIR_ADDRESS=<GRAFANA_BASE_URL>/api/convert/ \
MIMIR_AUTH_TOKEN=<SERVICE_ACCOUNT_TOKEN> \
MIMIR_TENANT_ID=1 \
mimirtool rules load rule_file.yaml \
  --extra-headers "X-Grafana-Alerting-Datasource-UID=<DATASOURCE_UID_QUERY_TARGET>"

This command imports Prometheus alert rules defined in rule_file.yaml as Grafana-managed alert rules. It’s important to know that:

When using the <GRAFANA_BASE_URL>/api/convert/ endpoint, mimirtool interacts with Grafana—not with a Mimir instance. In this case, MIMIR_TENANT_ID must always be set to 1.
The X-Grafana-Alerting-Datasource-UID header configures the data source that the imported alert rules will query. Use multiple --extra-headers flags to include other optional headers.

Similarly, the rules sync command can import and update Grafana-managed alert rules.

MIMIR_ADDRESS=<GRAFANA_BASE_URL>/api/convert/ \
MIMIR_AUTH_TOKEN=<SERVICE_ACCOUNT_TOKEN> \
MIMIR_TENANT_ID=1 \
mimirtool rules sync rule_file.yaml \
  --extra-headers "X-Grafana-Alerting-Datasource-UID=<DATASOURCE_UID_QUERY_TARGET>" \
  --concurrency 1

The --concurrency flag must be set to 1, as the default value of 8 may cause API errors.

This sync command reads rules from the file, compares them with the existing Grafana-managed rules in the instance, and applies only the differences—creating, updating, or deleting rules as needed.

## Sync Summary: 0 Groups Created, 1 Groups Updated, 0 Groups Deleted

For more information other Mimirtool commands and options, see the Mimirtool documentation and the Mimir HTTP Rule API documentation.

cortextool

For Loki alert rules, use cortextool (version 0.11.3 or later) with the --backend=loki flag. For example:

CORTEX_ADDRESS=<GRAFANA_BASE_URL>/api/convert/ \
CORTEX_AUTH_TOKEN=<SERVICE_ACCOUNT_TOKEN> \
CORTEX_TENANT_ID=1 \
cortextool rules load loki_rules.yaml \
  --extra-headers "X-Grafana-Alerting-Datasource-UID=<LOKI_DATASOURCE_UID_QUERY_TARGET>" \
  --backend=loki

Optional Headers

Additional configuration headers for more granular import control include the following:

`X-Disable-Provenance`

When this header is set to true:

The imported rules are not marked as provisioned.
They can then be edited in the Grafana UI.
They are excluded from the GET and DELETE operations on the /api/convert endpoints.

Do not enable this header when using the rules sync command, as it relies on the GET and DELETE operations to detect and update existing rules.

`X-Grafana-Alerting-Alert-Rules-Paused`

Set to true to import alert rules in paused state.

`X-Grafana-Alerting-Recording-Rules-Paused`

Set to true to import recording rules in paused state.

`X-Grafana-Alerting-Datasource-UID`

The UID of the data source to use for alert rule queries.

If not specified in the header, Grafana uses the configured default from unified_alerting.prometheus_conversion.default_datasource_uid. If neither the header nor the configuration option is provided, the request fails.

`X-Grafana-Alerting-Target-Datasource-UID`

The UID of the target data source for recording rules. If not specified, the value from X-Grafana-Alerting-Datasource-UID is used.

`X-Grafana-Alerting-Folder-UID`

Enter the UID of the target destination folder for imported rules.

`X-Grafana-Alerting-Notification-Settings`

JSON-encoded AlertRuleNotificationSettings object that allows setting the contact point for the alert rules.

AlertRuleNotificationSettings object

When you set X-Grafana-Alerting-Notification-Settings, the header value must be a JSON-encoded object with the following keys:

Field	Type	Required	Example	Description
`receiver`	`string`	Yes	`"grafana-default"`	Name of the contact point (receiver) to which alerts are routed. Must exist in Grafana before import.
`group_by`	`[]string`	No	`["alertname","grafana_folder","cluster"]`	Label set used by Alertmanager to aggregate alerts into a single notification.
`group_wait`	`duration`	No	`"30s"`	How long Alertmanager waits before sending the first notification for a new group.
`group_interval`	`duration`	No	`"5m"`	Time to wait before adding new alerts to an existing group’s next notification.
`repeat_interval`	`duration`	No	`"4h"`	Minimum time before a previously-sent notification is repeated. Must not be less than `group_interval`.
`mute_time_intervals`	`[]string`	No	`["maintenance"]`	One or more mute time interval names that silence alerts during those windows.
`active_time_intervals`	`[]string`	No	`["maintenance"]`	List of active time interval names. Alerts are suppressed unless the current time matches one of them.

Compatible endpoints

The API endpoints listed in this section are supported in Grafana and are used by mimirtool and cortextool, as shown earlier. These endpoints are compatible with Mimir HTTP API.

In these endpoints, a “namespace” corresponds to a folder title in Grafana.

The POST endpoints can be used to import data source–managed alert rules. They accept requests in both YAML and JSON. If no media type is specified, YAML is assumed.

Endpoint	Method	Summary	Mimir equivalent
POST	`/convert/prometheus/config/v1/rules`	Create or update multiple rule groups across multiple namespaces. Requires `X-Grafana-Alerting-Datasource-UID`.	None
POST	`/convert/prometheus/config/v1/rules/:namespaceTitle`	Create or update a single rule group in a namespace. Requires `X-Grafana-Alerting-Datasource-UID`.	Set rule group

The GET and DELETE endpoints work only with provisioned and imported alert rules. All GET endpoints support both JSON and YAML response formats based on the Accept header: use application/json for JSON responses, or application/yaml for YAML responses. YAML is the default format when no Accept header is specified.

Endpoint	Method	Summary	Mimir equivalent
GET	`/convert/prometheus/config/v1/rules`	Get all imported rule groups across all namespaces.	List rule groups
GET	`/convert/prometheus/config/v1/rules/:namespaceTitle`	Get imported rule groups in a specific namespace.	Get rule groups by namespace
GET	`/convert/prometheus/config/v1/rules/:namespaceTitle/:group`	Get imported rule group in a specific namespace.	Get rule group
DELETE	`/convert/prometheus/config/v1/rules/:namespaceTitle`	Delete all imported alert rules in a namespace.	Delete namespace
DELETE	`/convert/prometheus/config/v1/rules/:namespaceTitle/:group`	Delete a specific imported rule group.	Delete rule group

Create or update multiple rule groups

POST /convert/prometheus/config/v1/rules

Creates or updates multiple rule groups across multiple namespaces. This endpoint expects a request with a map of namespace titles to arrays of rule groups, and returns 202 on success.

This endpoint has no Mimir equivalent and is Grafana-specific for bulk operations.

Example request body

namespace1:
  - name: MyGroupName1
    rules:
      - alert: MyAlertName1
        expr: up == 0
        labels:
          severity: warning
namespace2:
  - name: MyGroupName2
    rules:
      - alert: MyAlertName2
        expr: rate(http_requests_total[5m]) > 0.1
        labels:
          severity: critical

Configure data source-managed alert rules

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

Caution
Pre-provisioned Loki and Prometheus data source-managed alerts have been deprecated in Grafana Cloud and can not be created in new stacks. New Grafana Cloud stacks will use Grafana-managed alerting (GMA) by default. Datasource-managed alerting (DMA) is not provisioned in new stacks. Existing stacks are not affected.

This applies to the default Loki and Prometheus Grafana Cloud data sources managed by Grafana Labs and Cloud Alertmanager, which will not be available nor will Grafana provision the data source for it. If you add your own Mimir, Loki, or Alertmanager data sources, you can continue to use data source-managed alerts.

Cloud users can import DMA rules into GMA rules with the import tool. See the import data source-managed alerts to Grafana-managed alerts documentation for information on how to do this.

Configure data source-managed alert rules

Data source-managed alert rules are alert rules that are stored in the data source, such as in Prometheus or Loki, rather than in Grafana.

In Grafana Alerting, you can:

Create and edit data source-managed rules for Grafana Mimir and Grafana Loki data sources.
View rules from Prometheus data sources when Manage alerts via Alerting UI is enabled. However, you cannot create or edit these rules in Grafana.
Import data source-managed rules from Loki, Mimir, and Prometheus into Grafana-managed rules.

Note
Data source-managed rules are supported for horizontal scalability, but they can introduce more operational complexity than Grafana-managed alert rules.

We recommend using Grafana-managed alert rules whenever possible, as they provide a richer feature set and better integration with the full Grafana Alerting workflow.

Comparison with Grafana-managed rules

The table below compares Grafana-managed and data source-managed alert rules.

Feature	Grafana-managed alert rule	Data source-managed alert rule
Supported data sources	All backend data sources enabling the `alerting` option	Only supports creating rules for Mimir and Loki data sources
Mix and match data sources	Yes	No
Add expressions to transform your data and set alert conditions	Yes	No
No data and error states	Yes	No
Stale alert instances	Yes	No
Images in alert notifications	Yes	No
Role-based access control	Yes	No
Alert state history	Yes	No
Alert version history	Yes	No
Terraform provisioning	Yes	No
Recording rules	Yes	Yes
Organization	Organize and manage access with folders	Use namespaces
Alert rule evaluation	Alert evaluation is done in Grafana	Alert rule evaluation is done in the data source and allow for horizontal scaling
Scaling	Alert rules are stored in the Grafana database.	Alert rules are stored within the data source and allow for horizontal scaling

The following diagram shows the architecture of a Mimir setup that uses data source-managed alert rules.

Create data source-managed alert rules

To create or edit data source-managed alert rules, follow these instructions.

Before you begin

Verify that you have write permission to the Mimir or Loki data source. Otherwise, you cannot create or update data source-managed alert rules.

Enable the Ruler API

For more information, refer to the Mimir Ruler API or Loki Ruler API.

Mimir - use the /prometheus prefix. The Prometheus data source supports both Grafana Mimir and Prometheus, and Grafana expects that both the Query API and Ruler API are under the same URL. You cannot provide a separate URL for the Ruler API.
Loki - The local rule storage type, default for the Loki data source, supports only viewing of rules. To edit rules, configure one of the other rule storage types.

Permissions

Alert rules for Mimir or Loki instances can be edited or deleted by users with Editor or Admin roles.

If you do not want to manage alert rules for a particular data source, go to its settings and clear the Manage alerts via Alerting UI checkbox.

Set alert rule name

Click Alerts & IRM -> Alert rules -> + New alert rule.
Enter a name to identify your alert rule.

This name is displayed in the alert rule list. It is also the alertname label for every alert instance that is created from this rule.

Define query and condition

Define a query to get the data you want to measure and a condition that needs to be met before an alert rule fires.

Note
By default, new alert rules are Grafana-managed. To switch to Data source-managed, follow these instructions.

Select a Prometheus-based data source from the drop-down list.

You can also click Open advanced data source picker to find more options.
Enter a PromQL or LogQL query, including the alert condition.
In the Rule type option, select Data source-managed.
Click Preview alerts.

Set alert evaluation behavior

Use alert rule evaluation to determine how frequently an alert rule should be evaluated and how quickly it should change its state.

Select a namespace or click + New namespace.
Select an evaluation group or click + New evaluation group.

If you are creating a new evaluation group, specify the interval for the group.

All rules within the same group are evaluated sequentially over the same time interval. You can reorder them from the Alert rules page.
Enter a pending period.

The pending period is the period in which an alert rule can be in breach of the condition until it fires.

After a condition is met, the alert goes into the Pending state. If the condition remains active for the duration specified, the alert transitions to the Firing state, else it reverts to the Normal state.

Configure labels and notifications

Add labels to your alert rules to set which notification policy should handle your firing alert instances.

All alert rules and instances, irrespective of their labels, match the default notification policy. If there are no nested policies, or no nested policies match the labels in the alert rule or alert instance, then the default notification policy is the matching policy.

Add labels if you want to change the way your notifications are routed.

Add custom labels by selecting existing key-value pairs from the drop down, or add new labels by entering the new key or value.

Configure notification message

Use annotations to add information to alert messages that can help respond to the alert.

Annotations are included by default in notification messages, and can use text or templates to display dynamic data from queries.

Grafana provides several optional annotations.

Optional: Add a summary.

Short summary of what happened and why.
Optional: Add a description.

Description of what the alert rule does.
Optional: Add a Runbook URL.

Webpage where you keep your runbook for the alert
Optional: Add a custom annotation.

Add any additional information that could help address the alert.
Optional: Link dashboard and panel.

Link the alert rule to a panel to facilitate alert investigation.
Click Save rule.

Create recording rules

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

Configure recording rules

Recording rules allow you to periodically pre-compute frequently used or computationally expensive queries, saving the results as a new time series metric.

For instance, you can create a recording rule generating a new metric, error_9001_count, which counts occurrences of a specific log error within one minute. Then, query the error_9001_count metric in dashboards and alert rules.

Recording rules can be helpful in various scenarios, such as:

Faster queries are needed: Performing heavy aggregations or querying large data sets is quicker with precomputed results than real-time queries.
Reducing system load: Precomputing specific queries in advance can reduce system overload caused by multiple simultaneous queries.
Simplifying complex aggregations: Create a new metric from complex aggregations to facilitate alert and dashboard setup.
Reusing queries to reduce costs: Improve efficiency by reusing the same query across similar alert rules and dashboards.

How recorded metrics work

A recording rule generates a new recorded metric by evaluating its rule definition on a fixed evaluation interval (for example, every 1m or 5m) and writing a single value as a new data point in the recorded metric.

The rule definition must return that single value, either from an instant query or a range query combined with a Reduce expression.

Recorded metrics are not guaranteed to exactly match the original raw data.

Aggregations in the recording rule query and evaluation lags can produce results that differ from the original raw data. Shorter evaluation intervals can reduce this gap by improving resolution.

For PromQL recommendations in recording rules, refer to Prometheus recording rules best practices.

Alerting on recorded metrics

When alert rules query recorded metrics, consider the following recommendations:

Use frequent evaluation intervals. Set frequent evaluation intervals for recording rules. Long intervals, such as an hour, can cause the recorded metric to be stale and lead to misaligned alert rule evaluations, especially when combined with a long pending period.
Align alert evaluation with recording frequency. The evaluation interval of an alert rule that depends on a recorded metric should be aligned with the recording rule’s interval. If a recording rule runs every 3 minutes, the alert rule should also be evaluated at a similar frequency to ensure it acts on fresh data. For details about the evaluation sequence, refer to how rules are evaluated within a group.
Use _over_time functions for instant queries. Since all alert rules are ultimately executed as an instant query, you can use functions like max_over_time(my_metric[5m]) as an instant query. This allows you to get an aggregated value over a period without using a range query and a reduce expression.

Types of recording rules

Similar to alert rules, Grafana supports two types of recording rules:

Grafana-managed recording rules, which can query any Grafana data source supported by alerting. It’s the recommended option.
Data source-managed recording rules, which can query Prometheus-based data sources like Mimir or Loki.

Configure rule sequences

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

Note
Rule sequences is currently in public preview. Grafana Labs offers limited support, and breaking changes might occur prior to the feature being made generally available.

Configure rule sequences

Use rule sequences in Grafana Alerting when a recording rule or alert rule depends on the results of another recording rule. A rule sequence references existing Grafana-managed rules and defines their evaluation order and shared evaluation interval.

You can create and manage rule sequences through the Grafana Alerting API or Terraform. The API uses v0alpha1 and is subject to change.

Before you begin

Before you create a sequence, ensure you have the following:

Grafana version: Use Grafana Cloud or Grafana OSS or Enterprise 13.1 or later.
Rules: Create at least one Grafana-managed recording rule and any dependent recording rules or alert rules. Place all the rules in the same folder.
Recording rule storage: Ensure your recording rules write to a Prometheus-compatible data source. In Grafana Cloud, rules without an explicit target write to your managed Prometheus data source by default. In self-managed Grafana, configure a target data source or a default target. For details, refer to Create Grafana-managed recording rules.
API access: Use an authenticated account with permission to manage alert rules in the folder. For authentication options, refer to Authentication options for the HTTP API.

Understand evaluation order

For each evaluation interval, Grafana evaluates the rules in two stages:

Evaluate the recording rules in the order listed in spec.recordingRules.
Evaluate the alert rules in the order listed in spec.alertingRules, after the recording rules.

For example, you can evaluate a recording rule that calculates a request rate, then a recording rule that uses that metric to calculate an error ratio, and then an alert rule that queries the error ratio.

The sequence’s spec.trigger.interval sets the evaluation interval for every rule in the sequence, overriding each rule’s individual interval while it belongs to the sequence. You continue to manage each rule’s queries, expressions, and other settings separately.

Rules outside the sequence retain their existing evaluation behavior. A sequence defines evaluation order, not a general-purpose organizational group.

Evaluation order doesn’t guarantee that a preceding rule produces new data. Grafana continues to the next rule even if a recording rule fails or returns no data. A dependent rule can query older data or receive no data, depending on its query and the target data source. Configure its error and no-data handling accordingly.

Even when a recording rule succeeds, its samples might not be available to query immediately. Grafana waits for the write request to complete but doesn’t check whether the target data source can return the samples before it evaluates the next rule. A sequence guarantees evaluation order, not read-after-write consistency.

Create a sequence with the API

Create a RuleSequence resource that references the rules by name. For alert rules and recording rules, use each resource’s metadata.name, which corresponds to its rule UID.

Send a POST request to /apis/rules.alerting.grafana.app/v0alpha1/namespaces/{namespace}/rulesequences with the Content-Type: application/json header and the following body:

{
  "apiVersion": "rules.alerting.grafana.app/v0alpha1",
  "kind": "RuleSequence",
  "metadata": {
    "name": "request-error-sequence",
    "namespace": "<NAMESPACE>",
    "annotations": {
      "grafana.app/folder": "<FOLDER_UID>"
    }
  },
  "spec": {
    "trigger": {
      "interval": "1m"
    },
    "recordingRules": [{ "name": "<REQUEST_RATE_RULE_UID>" }, { "name": "<ERROR_RATIO_RULE_UID>" }],
    "alertingRules": [{ "name": "<ALERT_RULE_UID>" }]
  }
}

Replace the placeholders with the following values:

<NAMESPACE>: Use your Grafana instance’s namespace in both the request path and body. For namespace formats, refer to API structure in Grafana.
<FOLDER_UID>: Use the UID of the folder that contains all referenced rules.
<REQUEST_RATE_RULE_UID>: Use the UID of the recording rule that calculates the request rate.
<ERROR_RATIO_RULE_UID>: Use the UID of the recording rule that queries the request-rate metric and calculates the error ratio.
<ALERT_RULE_UID>: Use the UID of the alert rule that queries the error-ratio metric.

The example evaluates the three rules in that order every minute. Configure the dependent rules to query the metrics produced by the preceding recording rules. Adding a rule to a sequence doesn’t change its query or automatically connect it to another rule’s output.

To retrieve the sequence, send a GET request to /apis/rules.alerting.grafana.app/v0alpha1/namespaces/{namespace}/rulesequences/{name}. Use request-error-sequence as {name} for this example.

Create a sequence with Terraform

Use the grafana_apps_rules_rulesequence_v0alpha1 resource to manage a sequence in Terraform. Set metadata.folder_uid to the folder that contains the rules, and reference their UIDs in spec.recording_rules and spec.alerting_rules.

For a complete example and resource fields, refer to grafana_apps_rules_rulesequence_v0alpha1.

Update or remove a sequence

To change the order, membership, or interval through the API, retrieve the current sequence and send the updated resource with a PUT request to /apis/rules.alerting.grafana.app/v0alpha1/namespaces/{namespace}/rulesequences/{name}. Preserve its metadata.resourceVersion from the response.

To remove a sequence, send a DELETE request to /apis/rules.alerting.grafana.app/v0alpha1/namespaces/{namespace}/rulesequences/{name}. Deleting a sequence doesn’t delete the rules it references.

After Grafana picks up the change, rules removed from a sequence return to their stored evaluation interval and group settings.

If you manage the sequence with Terraform, update or remove it in your Terraform configuration instead.

Sequence constraints

When you create or update a sequence, follow these constraints:

Recording rules: Include at least one recording rule. Alert rules are optional.
Folder: Place the sequence and all referenced rules in the same folder.
Membership: Reference each rule only once. A rule can belong to only one sequence.
Rule changes: Remove a rule from its sequence before you delete the rule or move it to another folder.
Interval: Use a positive interval that’s an integer multiple of your instance’s base evaluation interval. For example, with a base interval of 10s, you can use 10s, 30s, or 1m, but not 15s. The API rejects invalid intervals instead of adjusting them.
Self-managed evaluation jitter: In Grafana OSS and Enterprise, keep the jitterAlertRulesWithinGroups feature toggle disabled when you use rule sequences. This toggle disables sequential evaluation and is disabled by default.

For more information about recording rules and evaluation behavior, refer to the following resources:

Template annotations and labels

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

Template annotations and labels

You can use templates to customize alert and notification messages, including dynamic data from alert rule queries.

In Grafana Alerting, you can template alert messages in two ways.

Template annotations and labels: In the alert rule definition, you can template annotations and labels to include extra information from query data to the alert, adding meaningful details based on the query results.
Template notifications: You can template notifications to control the content and appearance of your notifications.

How templating works

In this diagram, you can see the differences between both types of templates.

Refer to Templates Introduction for a more detailed explanation of this diagram.

Both types of templates are written in the Go templating system. However, it’s important to understand that variables and functions used in notification templates are different from those used in annotation and label templates.

Template annotations and labels: These templates add extra information to individual alert instances. Template variables like $labels and $values represent alert query data of the individual alert instance.
Template notifications: Notification templates format the notification content for a group of alerts. Variables like .Alerts include all firing and resolved alerts in the notification.

Template annotations

Annotations add additional information to alert instances and are often used to help identify the alert and guide responders on how to address the issue.

Annotations are key-value pairs defined in the alert rule. They can contain plain text or template code that is evaluated when the alert fires.

Grafana includes several optional annotations, such as description, summary, and runbook_url, which can be edited in the alert rule. You can also create your custom annotations. For example, you might create a new annotation named location to report the location of the system that triggered the alert.

Here’s an example of a summary annotation explaining why the alert was triggered, using plain text.

CPU usage has exceeded 80% for the last 5 minutes.

However, if you want to display dynamic query values in annotations, you need to use template code. Common use cases include:

Displaying the query value that triggered the alert.
Highlighting label information that identifies the alert, such as the environment, instance, or region.
Providing specific instructions based on query values.
Customizing runbook links depending on query labels.
Including contact information based on query labels.

For instance, you can template the previous example to display the specific instance and CPU value that triggered the alert.

CPU usage for {{ $labels.instance }} has exceeded 80% ({{ $values.A.Value }}) for the last 5 minutes.

Alternatively, you can use the index function to print query values.

CPU usage for {{ index $labels "instance" }} has exceeded 80% ({{ index $values "A" }}) for the last 5 minutes.

The result of the annotation would be as follows.

CPU usage for Instance 1 has exceeded 80% (81.2345) for the last 5 minutes.

How to template an annotation

Complete the following steps to template an annotation.

Navigate to Alerts & IRM -> Alert rules -> create or edit an alert rule.
Scroll down to the Configure notification message section.
Copy in your template in the corresponding annotation field (summary, description, runbook_url, custom).

Preview annotation templates

You can template annotations when creating or editing an alert rule.

Two common methods are used to test and preview annotation templates:

Trigger the alert and view the alert instance state in the Grafana UI, where all annotations of the alert instance are displayed.
Use a notification template that displays all annotations, then preview the notification template using the alert instance.

Template labels

The set of labels for an alert instance is used to uniquely identify that alert among all other alert instances.

Labels determine how alerts are routed and managed for notifications, making their design key to the effectiveness of your alerting system.

Labels can be returned from an alert rule query, such as the pod label in a Kubernetes Prometheus query. You can also define additional labels in the alert rule to provide extra information for processing alerts.

Like annotations, labels are key-value pairs that can contain plain text or template code evaluated when the alert fires.

Template labels when the labels returned by your queries are insufficient. For instance:

A new label based on a query value can group a subset of alerts differently, changing how notifications are sent.
A new label based on a query value can be used in a notification policy to alter the notification contact point.

Here’s an example of templating a severity label based on the query value.

{{ if (gt $values.A.Value 90.0) -}}
critical
{{ else if (gt $values.A.Value 80.0) -}}
high
{{ else if (gt $values.A.Value 60.0) -}}
medium
{{ else -}}
low
{{- end }}

In this example, the value of the severity label is determined by the query value, and the possible options are critical, high, medium, or low. You can then use the severity label to change their notifications—for instance, sending critical alerts immediately or routing low alerts to a specific team for further review.

Note: An alert instance is uniquely identified by its set of labels.

Avoid displaying query values in labels, as this can create numerous alert instances—one for each distinct label set. Instead, use annotations for query values.

If a templated label’s value changes, it maps to a different alert instance, and the previous instance is considered stale. Learn all the details in this example using dynamic labels.

How to template a label

Complete the following steps to template a label.

Navigate to Alerts & IRM -> Alert rules -> create or edit an alert rule.
Scroll down to the Configure labels and notifications section.
Click + Add labels.
Enter a key that identifies the label.
Copy in your template in the value field.

Preview label templates

You can template label values when creating or editing an alert rule.

To preview label values, select Use notification policy, and then click on Preview routing.

More information

For further details on how to template alert rules, refer to:

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

Improve alert rule quality with Alert Advisor

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

Improve alert rule quality with Alert Advisor

Alerts are easier to act on when they carry the right context. A runbook URL helps you investigate an issue, and a team label helps you route your notifications.

Alert Advisor checks your Grafana-managed alert rules against a quality policy of required labels and annotations, so you can find and fix rules that are missing that context. With Alert Advisor, you can:

Define which labels and annotations your Grafana-managed alert rules must have.
Find rules that are missing required labels or annotations and update them.
Optionally block supported provisioning writes that don’t meet selected requirements.

Before you begin

Before you begin, check that you have the following permissions in your Grafana organization:

Rule access: Have permission to view the Grafana-managed alert rules you want to assess.
Policy permissions: To configure the quality policy, have the Admin role in your organization or a role with alert.rules.quality:write and alert.rules:read.
Rule updates: To fix findings, have permission to update the affected rules. For provisioned rules, you also need access to their source configuration and permission to reapply it.

For more information about alerting permissions and folder access, refer to Configure RBAC.

Understand policy scope

A single quality policy applies to Grafana-managed alert rules across folders in your organization. Data source-managed alert rules and recording rules are excluded.

Alert Advisor reports a finding when a required label or annotation is missing, empty, or contains only whitespace. The checks do not validate the content itself, they only check for the presence of a particular field. For example, requiring a runbook URL doesn’t check whether the link works.

Detection and enforcement

You choose a mode for each requirement:

Mode	Behavior
Detect-only	Missing values appear as findings but don’t block rule creation or updates.
Enforced	Missing values appear as findings and block rule creation or updates through supported provisioning paths.

Both modes contribute to the quality score. Enabling enforcement doesn’t stop existing rules from evaluating or sending notifications.

Supported enforcement paths

Enforcement applies to provisioned rules created or updated through Terraform and the Alerting provisioning HTTP API, with the following exceptions:

Provisioning API requests that set the X-Disable-Provenance header, including Terraform grafana_rule_group resources with disable_provenance = true, aren’t enforced.
kubectl writes are enforced only when the manifest sets grafana.app/managedBy to kubectl or terraform together with a non-empty grafana.app/managerId, or sets grafana.com/provenance to api.

Writes from the Grafana rule editor aren’t enforced, but the resulting rules can still have quality findings.

Configure a quality policy

Start with detect-only requirements to identify missing information before enabling enforcement. The following example requires a runbook URL and a team label.

The Quality policy settings button is visible only if you have the policy permissions listed in Before you begin.

To configure a quality policy, follow these steps:

Go to Alerting > Alert rules and select Alert quality.
Click Quality policy settings (the cog icon) to open the Quality policy drawer.
Under Required annotations, turn on Runbook URL.

You can also require Summary and Description.
Under Required labels, enter team in Label keys and select the matching option.

You can select keys already used by your rules or add a new key.
Keep Enforce off for the requirements you add.

New requirements start in detect-only mode.
Click Save.

Grafana displays Policy saved to confirm the change.

The saved policy identifies rules with missing or empty runbook_url annotations or team labels.

A policy with no required annotations or labels checks nothing.

Review alert quality

In Alert Advisor, the Alert quality tab lists rules that don’t meet your policy and shows an overall quality score.

To review the findings, follow these steps:

Go to Alerting > Alert rules and select Alert quality.
Review the Alert quality score and the number of rules that need attention.
Inspect the missing annotations and labels in the Findings list.

Each missing field appears as a badge. To check whether a requirement is enforced or detect-only, hover over its badge.

Understand the score

The score represents the proportion of assessed rules that meet every configured requirement, on a scale of 0 to 10. For example, if 8 of 10 rules meet the policy, the score is 8.0. Grafana rounds the score to one decimal place.

The score measures compliance with your policy, not alert accuracy, severity, or noise. Both detect-only and enforced requirements count toward the score.

Your permissions determine which rules you can view and assess. Search filters change the findings’ list, not the score or the total rule count. Grafana also displays 10.0 when there are no rules to assess, so check the rule count alongside the score.

Resolve quality findings

Add meaningful values for the missing fields in each rule. For the example policy, set runbook_url to the rule’s runbook URL and team to the owning team’s name.

Changing label values can affect notification routing. Choose values that match your team’s notification policies.

Update provisioned rules

For provisioned rules, make changes in the source configuration so they remain part of your provisioning workflow.

To resolve a finding on a provisioned rule, follow these steps:

Locate the rule in its source configuration, using the rule name, folder, and group shown in Alert quality.
Add values for the missing annotations and labels.
Reapply the configuration through your usual provisioning workflow.
Reload the Alert quality page and check the rule’s findings.

A rule disappears from the findings list when it meets every configured requirement. If other required fields are still missing, the rule remains in the list with those findings.

Update rules in Grafana

For rules that you can edit in Grafana, use the Edit action on the quality page.

To resolve a finding in the rule editor, follow these steps:

Click Edit for the affected rule.
Fill in the missing annotations and labels in the rule editor.
Click Save.
Return to Alert quality and reload the page to check the findings.

Optional: Enforce quality requirements

After reviewing and resolving findings, enable enforcement for the requirements you want to apply to supported provisioning writes. You can enforce selected requirements while keeping others detect-only.

To enable enforcement, follow these steps:

On the Alert quality page, click Quality policy settings (the cog icon) to open the Quality policy drawer.
Turn on Enforce beside each requirement you want to enforce.

For example, enforce team while keeping Runbook URL detect-only. To enforce all currently configured requirements, turn on Enforce all requirements instead.
Click Save.

Grafana displays Policy saved to confirm the change.

Disable enforcement or remove a requirement

To return a requirement to detect-only, turn off its Enforce control (or Enforce all requirements, if every requirement is enforced) and click Save. The requirement remains in the policy and continues to affect the quality score.

To stop checking a field altogether, remove its requirement instead: turn off its switch under Required annotations, or remove its key from Label keys. Then click Save.

Troubleshoot quality findings and rejected writes

Use the following guidance when you can’t access the feature, resolve a finding, or apply a rule change.

Symptom	Action
Alert quality or the Quality policy settings button isn’t visible.	Ask your stack administrator to check your permissions and the feature’s availability in your stack.
A rule has no Edit action.	If it has a Provisioned badge, update its source configuration. Otherwise, check your permission to update rules in that folder.
Grafana reports that no quality policy is configured.	Add at least one requirement in the Quality policy drawer and click Save. An empty policy doesn’t assess any fields.
No findings match your search, but the score is below 10.0.	Clear Search to view all findings. Search filters don’t change the score.
A finding remains after enforcement is disabled.	Detect-only requirements still produce findings. Fill in the missing value or remove the requirement from the policy.
A provisioning write is rejected by the quality policy.	Use the rule and field details in the error to update the source configuration, then reapply it.
A write succeeds despite a quality finding.	Check that the requirement is enforced and the policy is saved. Confirm that the write uses a supported enforcement path and isn’t one of its exceptions.

Next steps

Use these guides to improve rule context, manage rules as code, and configure access:

Rule context: Labels and annotations.
Provisioning: Use Terraform to provision alerting resources.
API management: Use the HTTP API to manage alerting resources.
Permissions: Configure RBAC.

Configure alert rules on Grafana Labs

Configure Grafana-managed alert rules

Configure Grafana-managed alert rules

Before you begin

Supported data sources

Alert rule limits in Grafana Cloud

Permissions

Provisioning

Default versus Advanced options

Set alert rule name

Define query and condition

Set folder and labels

Configure alert evaluation behavior

Configure no data and error handling

Configure notifications

Configure notification message

Create and link alert rules to panels

Create and link alert rules to panels

Link alert rules to panels

Create alert rules from panels

Access linked alert rules from panels

Import data source-managed rules to Grafana-managed rules

Import data source-managed rules to Grafana-managed rules

Import your notification configuration first

How it works

Import rules with Grafana Alerting

Before you begin

Import rules with command-line tools

Before you begin

mimirtool

cortextool

Optional Headers

X-Disable-Provenance

X-Grafana-Alerting-Alert-Rules-Paused

X-Grafana-Alerting-Recording-Rules-Paused

X-Grafana-Alerting-Datasource-UID

X-Grafana-Alerting-Target-Datasource-UID

X-Grafana-Alerting-Folder-UID

X-Grafana-Alerting-Notification-Settings

AlertRuleNotificationSettings object

Compatible endpoints

Create or update multiple rule groups

Example request body

Configure data source-managed alert rules

Configure data source-managed alert rules

Comparison with Grafana-managed rules

Create data source-managed alert rules

Before you begin

Enable the Ruler API

Permissions

Set alert rule name

Define query and condition

Set alert evaluation behavior

Configure labels and notifications

Configure notification message

Create recording rules

Configure recording rules

How recorded metrics work

Alerting on recorded metrics

Types of recording rules

Configure rule sequences

Configure rule sequences

Before you begin

Understand evaluation order

Create a sequence with the API

Create a sequence with Terraform

Update or remove a sequence

Sequence constraints

Related resources

Template annotations and labels

Template annotations and labels

How templating works

Template annotations

How to template an annotation

Preview annotation templates

Template labels

How to template a label

Preview label templates

More information

Improve alert rule quality with Alert Advisor

`X-Disable-Provenance`

`X-Grafana-Alerting-Alert-Rules-Paused`

`X-Grafana-Alerting-Recording-Rules-Paused`

`X-Grafana-Alerting-Datasource-UID`

`X-Grafana-Alerting-Target-Datasource-UID`

`X-Grafana-Alerting-Folder-UID`

`X-Grafana-Alerting-Notification-Settings`