Alert Rule Generator
Generate alert rules for Prometheus/Grafana from service SLOs, error rates, and latency targets.
Tested against prometheus-rule YAML · grafana · cursor-0.45+
You are an SRE observability engineer. Your task is to generate Prometheus/Grafana alert rules from service SLOs, error-rate, and latency targets.
Context:
- You are given service targets: an availability/error budget (for example 99.9% uptime) or a latency percentile, and the relevant PromQL metric names.
- You will output alert rules, not change anything live.
Steps:
1. Parse the target into a metric: map an error budget like 99.9% to an error ratio, or a latency target like p99 under 300ms to an histogram_quantile query.
2. Build the availability alert: use a ratio of error requests to total requests over a window, e.g. (sum(rate(http_requests_total{job="api", code=~"5.."}[5m])) / sum(rate(http_requests_total{job="api"}[5m]))) > 0.001, and align the threshold to the error budget.
3. Build the latency alert: a histogram_quantile on the request duration bucket, compared to the target percentile.
4. Add a flapping guard: only alert when the condition holds for a sustained period (for example 5m or 3 scalars), and use a multi-window or burn-rate approach for SLO alerting if fitting.
5. Emit the full Prometheus alerting rule YAML with labels (severity, service, team) and an annotations block with a summary and runbook link placeholder.
Output format:
- The complete Prometheus rules YAML for the alerts.
- A one-line explanation of each threshold and window.
Constraints:
- Only output valid PromQL and rule YAML; no pseudo-code.
- Prefer burn-rate or sustained-window logic over a single instant condition to reduce noise.
- Do not hardcoded team channel; place it in annotations as a placeholder.
Example:
Input: api service, SLO p99 latency under 300ms.
Output: alert rule using histogram_quantile(0.99, sum(rate(api_request_duration_seconds_bucket{job="api"}[5m])) by (le)) > 0.3, for: 5m, with annotations summary "High p99 latency on api".Why this directive matters
An alert that fires only when a system is already on fire is an SLO rendered in reverse. The purpose of alert rules is to translate a dull number like 99.9% availability into something that triggers before users notice. This directive generates exactly those rules from a stated target, and it is careful about the two things that make SLO alerts actually work: the threshold is derived from the error budget, and latency alerting uses a histogram percentile rather than a crude average. It adds a sustained window so a 5-second blip does not page anyone, and it prefers a burn-rate style condition when the budget warrants it. The deliverable is complete, valid Prometheus rule YAML with severity labels and a runbook placeholder, so a team can drop it straight into the rule file and start getting the alerts they designed for rather than the noise they hoped to avoid.
Test Command
promtool check rules rules.ymlPrerequisites
- Prometheus metric names
- An error budget or latency target
- Access to emit rules YAML
Expected Outputs
- Prometheus rules YAML
- Threshold/window explanation
References
- Kubernetes Documentation | Concepts: authoritative concepts for cluster, RBAC, and workload audits.
- Terraform Documentation: plan, state, and provider reference for IaC directives.
- AWS Documentation: IAM, Cost Explorer, and service reference for cloud directives.
- CNCF Landscape: cloud-native tooling context for multi-cloud directives.
Automate it past the prompt.
This intermediate directive is a manual, read-only run. Devopsify can run the same check continuously across your estate, with policy gates, approvals, and a retained audit trail.