Grafana SLO Burn-Rate Dashboard Design Prompt

You are a senior SRE who designs SLO dashboards that follow the Google SRE multi-window, multi-burn-rate methodology.

I will provide:
- The SLI definition (e.g. request success ratio, latency threshold)
- The SLO target (e.g. 99.9% over 30 days) and the datasource
- The service name and label selectors

Your job:

1. **Define the SLI as a ratio**: good events / valid events, expressed as Prometheus recording rules so the dashboard never recomputes raw histograms at query time.
2. **Compute the error budget**: `1 - SLO` over the 30-day window, and show budget remaining as a Stat panel with green/amber/red thresholds.
3. **Multi-window burn rate**: build the classic pairs (1h/5m at 14.4x, 6h/30m at 6x, 24h/2h at 3x, 3d/6h at 1x) so alerts fire fast on severe burn yet stay quiet on slow drift.
4. **Burn-rate panels**: time series of the burn-rate ratio with threshold lines at each alert boundary, plus a "budget remaining" trend for the full compliance window.
5. **Alerting**: emit Grafana unified alert rules (or Prometheus rules) for the fast-burn (page) and slow-burn (ticket) conditions, with the short-window guard to suppress flapping.
6. **Template variables**: a `service` variable driven by `label_values()` so one dashboard serves every service.
7. **Provisioning**: deliver the dashboard JSON, the recording rules YAML, and the alert rules YAML.

Mark DESTRUCTIVE: none — this is read-only. But warn if the burn-rate expressions divide by zero on low-traffic services and recommend `clamp_min` or a minimum-events guard.

---

SLI definition: [DESCRIBE]
SLO target and window: [DESCRIBE]
Datasource and labels: [DESCRIBE]

Why this prompt works

Most SLO dashboards fail one of two ways: they alert on a single long window (so incidents are caught slowly and page endlessly on recovery), or they recompute expensive histograms on every refresh. This prompt forces the multi-window / multi-burn-rate pattern with a short-window guard and pushes the SLI into recording rules, which is what makes a burn-rate board both fast and cheap.

How to use it

1. State the SLI as good/valid events so the assistant can write the ratio recording rule.
2. Give the exact SLO and window so budget and burn thresholds are correct.
3. Name the label selectors so the service variable and rules match your metrics.
4. Ask for all three artifacts: dashboard JSON, recording rules, alert rules.

Useful commands

# Validate Prometheus recording/alert rules before loading
promtool check rules slo-rules.yml

# Import the finished dashboard via the Grafana API
curl -X POST http://localhost:3000/api/dashboards/db \
  -H "Authorization: Bearer $GRAFANA_TOKEN" \
  -H "Content-Type: application/json" \
  -d @slo-dashboard.json

Example config

# Prometheus recording rules: 5m and 1h burn rates for a request-success SLO
groups:
  - name: slo-checkout-availability
    rules:
      - record: job:sli_error:ratio_rate5m
        expr: |
          sum(rate(http_requests_total{job="checkout",code=~"5.."}[5m]))
          /
          clamp_min(sum(rate(http_requests_total{job="checkout"}[5m])), 0.001)
      - record: job:sli_error:ratio_rate1h
        expr: |
          sum(rate(http_requests_total{job="checkout",code=~"5.."}[1h]))
          /
          clamp_min(sum(rate(http_requests_total{job="checkout"}[1h])), 0.001)
      - alert: CheckoutErrorBudgetFastBurn
        # 14.4x burn over 1h AND 5m confirms — pages
        expr: |
          job:sli_error:ratio_rate1h > (14.4 * 0.001)
          and
          job:sli_error:ratio_rate5m > (14.4 * 0.001)
        for: 2m
        labels: { severity: page }
        annotations:
          summary: "Checkout burning 30-day error budget 14.4x too fast"

Common findings this catches

• NaN/Inf panels → unguarded division on low-traffic services.
• Slow paging → single long window with no short-window guard.
• Expensive refresh → histograms recomputed instead of recorded.
• Broken detection → recording-rule and alert windows out of sync.
• Alert fatigue → SLO tighter than the platform delivers.

When to escalate

• SLO targets disputed across teams — agree them in an error-budget policy first.
• Metric cardinality or Prometheus load from the rules — the observability platform team.
• Paging thresholds vs on-call tolerance — the on-call/incident-management owner.