Alert rules
A data source-managed alert rule lives in your Prometheus-compatible ruler, not in Grafana. The plugin reads it from there and, when the backend allows it, writes changes back.
Two kinds of rule
Both live side by side in the same rule groups, and the plugin lists both together.
Alerting rules watch for a condition and produce alerts when it holds. This is what most people mean by a rule.
- alert: HighRequestLatency
expr: job:request_latency_seconds:mean5m{job="api"} > 0.5
for: 10m
labels:
severity: warning
annotations:
summary: 'High latency on {{ $labels.job }}'Recording rules evaluate an expression ahead of time and save the result as a new time series. They produce no alerts. They exist so that expensive queries run once on a schedule instead of every time a dashboard or alerting rule needs them.
- record: job:request_latency_seconds:mean5m
expr: rate(request_latency_seconds_sum[5m]) / rate(request_latency_seconds_count[5m])The example above shows the two working together: the recording rule does the arithmetic, and the alerting rule compares the result against a threshold.
What a rule is made of
Recording rules have no pending period, keep firing for, or annotations, because there’s no alert to delay, hold open, or describe.
Where rules live
Rules are organized into groups, and groups sit inside a namespace. In Mimir and Cortex a namespace is roughly a file’s worth of rules; in vanilla Prometheus it corresponds to a rule file on disk.
The group is the unit of evaluation: everything in a group runs together, on the group’s interval, in the order the rules are listed. Refer to Rule groups and evaluation.


