Prometheus
Prometheus rule evaluation slow
Overview
What does this alert mean?
A rule group's evaluation takes longer than its configured interval. Alerts from this group may be delayed.
Contributing factors
- Complex PromQL with high label cardinality
- Prometheus under-resourced — insufficient CPU
- TSDB under heavy concurrent write load
Affected components
- All alerting and recording rules in the slow rule group
- Dependent dashboards that query the recording rules
Expected action
Identify the slow rule group, pre-compute expensive sub-expressions as recording rules, or reduce cardinality.
Services
- Prometheushttps://prometheus.io/docs/Team: Fill in: owning team name
Metrics
Metric
prometheus_rule_group_last_duration_secondsDescription & unit
Duration of the last evaluation of a rule group, in seconds.
Unit: seconds
Threshold rationale
If evaluation takes longer than the group interval, subsequent evaluations queue up and alerts are delayed.
Normal behavior
Rule group evaluation should complete in well under the group interval (typically < 10% of the interval).
Screenshots


Alert Behavior
Silencing
Silence while actively optimizing the rule group.
Expected frequency
Rare — usually appears after cardinality growth or a new complex rule is added.
Severities
Severity guidance
Warning. Escalate if evaluation lag is causing known alert delays in production.
Impacted users
SRE team — delayed alerts mean slower incident detection.
Things to check to determine severity
- Which rule group is slow? (`prometheus_rule_group_last_duration_seconds`)
- What is the cardinality of the metrics involved?
- Was a new rule recently added?
Verification
Prometheus query
prometheus_rule_group_last_duration_seconds > prometheus_rule_group_interval_secondsDashboards
- Prometheus Self-Monitoring — Fill in: dashboard URL
Log queries
- Prometheus slow query logs — Fill in: log query URL
Troubleshooting
Steps
- 1Identify slow groups: query
prometheus_rule_group_last_duration_secondsand sort descending - 2In Prometheus UI go to Status → Rules — look for groups with high last duration
- 3For each slow rule, run the PromQL manually and time it: note the cardinality of the result
- 4Pre-compute expensive sub-expressions as recording rules with a shorter interval
- 5Check Prometheus CPU usage — if saturated, scale vertically or shard rule groups
Useful commands
curl -s 'http://<prometheus>:9090/api/v1/query?query=prometheus_rule_group_last_duration_seconds' | jq '.data.result | sort_by(.value[1]) | reverse | .[:5]'Possible Resolutions
A new recording rule used a high-cardinality join. Replacing the join with a pre-computed recording rule reduced evaluation time by 90%.
Dependencies
- TSDB write throughput
- CPU and memory available to Prometheus
Escalation
Guidance
Escalate if evaluation lag exceeds 2x the group interval for more than 10 minutes.
Slack channels
- #observability-oncall — Fill in: channel URL
Definitions
Alert rule
Fill in: link to the alert rule in _data/rules.yml on GitHubTuning notes
Split large rule groups into smaller ones with focused scopes to reduce per-group evaluation time.
Related Links
Related alerts
Documentation
Template adapted from https://runbooks.gitlab.com/template-alert-playbook/