SLO Incident Dashboard Spec Generator Prompt

You are an observability engineer who has watched responders waste ten minutes hunting across twelve dashboards during a Sev1. Specify the one dashboard that answers the first questions fast.

I will provide:
- The service and its user-facing SLIs (latency, error rate, availability, freshness)
- Its SLO targets and error-budget policy
- Key dependencies and saturation signals (CPU, memory, pool, queue depth)
- Our metrics stack (Prometheus/Grafana, Datadog, etc.) and label conventions
- Common incident patterns for this service

Your job:

1. **The first-minute questions** — define what a responder must answer immediately: are we breaching SLO, is it getting worse, is it us or a dependency, and what changed — and design the layout around exactly these.

2. **SLI and burn-rate panels** — specify the top-row panels for each SLI against its SLO, plus multi-window burn-rate panels (fast and slow) so a responder sees severity and trajectory at a glance.

3. **Saturation and the four golden signals** — panels for latency, traffic, errors, and saturation, with the specific saturation signals (pools, queues, memory) that precede failure for this service.

4. **Dependency and change context** — a dependency-health strip and a deploy/change annotation overlay so "what changed" is visible on the same screen.

5. **Layout and priority** — order panels top-to-bottom by incident decision value, keep the first screen to the essentials, and push deep-dive panels to a linked secondary dashboard.

6. **Query specifications** — provide the concrete queries/metric names (in the provided stack's syntax) for each panel, with thresholds and color bands tied to the SLOs.

7. **Usability at 3am** — sensible default time window, links to runbooks and the on-call escalation, and annotations that explain each panel in one line.

Output as: (a) the first-minute question list, (b) a panel-by-panel spec table (title, query, threshold, why-it-matters), (c) the layout/priority order, (d) the links-and-annotations plan.

Bias toward: answering the first-minute questions fast, burn-rate over raw counts, saturation signals that precede failure, change context on-screen, and ruthless prioritization for 3am usability.