An Observability Dashboard Prompt That Designs the Panels

A bad dashboard is worse than no dashboard. Forty panels in no particular order, the one metric that matters buried in the bottom-right, colors that don't mean anything. During an incident, that dashboard costs you minutes you don't have. A good dashboard answers "is the service healthy?" in two seconds. The difference is design, and an observability dashboard prompt turns that design from a guessing game into a repeatable spec.

The prompt worth reusing takes a service description and its key metrics, then returns a panel-by-panel layout built on RED or the Four Golden Signals: what goes top-left, what visualization each panel uses, and why. Same structure every service, so anyone can read any dashboard.

What an observability dashboard prompt produces

An observability dashboard prompt is a reusable AI prompt that converts a service description and metric list into a structured, panel-by-panel dashboard spec ordered by a recognized framework. The locked layout contract is the value: a dashboard you can read the same way you read every other one.

The best-practice docs explain the frameworks but won't lay out your dashboard. Grafana's dashboard best-practices docs describe the RED method, request and error rate on the left, latency on the right, one row per service, as prose principles. groundcover's observability-dashboards guide covers the Four Golden Signals well. Neither converts your service into a panel spec. That's the reusable prompt's job.

What you can do with this prompt

• Design a dashboard layout for a new service from its description and metrics.
• Reorganize a cluttered existing dashboard around RED or the golden signals.
• Pick the right visualization per metric: time-series for latency, stat panels for rates.
• Produce a consistent layout across every service so on-call reads them the same way.
• Draft the panel spec or JSON skeleton you wire into Grafana.

Anatomy of the prompt pack

Variables
  {{service_description}} – what it does, who depends on it
  {{available_metrics}}   – real metric names you emit today
  {{framework}}           – RED or Four Golden Signals
  {{audience}}            – on-call triage vs exec summary vs deep-dive
  {{data_source}}         – Prometheus, Datadog, etc.

Prompt
  Role: SRE designing a dashboard for fast incident triage.
  Task: lay out panels by framework, pick visualizations, order by importance.
  Output contract (locked):
    1. Top row       – the framework's core signals, eye-first
    2. Panel spec    – per panel: metric, visualization, why
    3. Layout order  – left-to-right, top-to-bottom data flow
    4. Color rules   – what red/green should mean here
    5. Gaps          – metrics the framework wants but you don't emit

The "Gaps" section is the one that earns its place. If you ask for a RED dashboard but {{available_metrics}} has no error-rate metric, the prompt should say so rather than fabricate a panel for data you don't have. That gap is a telemetry task, not a dashboard task.

How models behave when designing dashboards

Claude is the most disciplined at keeping the framework order intact, putting rate and errors before duration in a RED layout instead of reshuffling by metric type. GPT-4o picks visualizations well, time-series for latency, stat panels and gauges for success rates, but tends to over-populate the top row unless you cap it. Gemini is good at flagging missing metrics for the Gaps section but sometimes skips the color-meaning rules, so restate that blue or green means healthy and red means bad.

The model can't know your metric names. Paste them. A dashboard spec built on guessed metric names is a wiring exercise in frustration.

Prompt-craft patterns

Pattern 1 — framework order is fixed. Don't let the model reshuffle.

Lay out panels in {{framework}} order. For RED that's Rate and
Errors top-left, Duration top-right. Do not reorder by metric type
or alphabetically.

Pattern 2 — cap the top row. Force prioritization.

The top row holds only the framework's core signals, at most four
panels. Everything else goes in lower rows. State what you demoted
and why.

Pattern 3 — gaps over fabrication. Refuse to invent panels.

Only use metrics in {{available_metrics}}. If {{framework}} expects
a signal you don't emit, list it under Gaps instead of creating a
panel for data that doesn't exist.

The take worth defending: the RED method beats a custom dashboard for almost every service. People love designing custom dashboards with twelve clever panels, and then nobody can read each other's during an incident. A boring, consistent RED layout that every service shares is more valuable than a clever one nobody else understands. Consistency is the feature.

Variables you'll set

Getting started

1. List the real metric names the service emits today.
2. Pick a {{framework}}, RED is the safe default for a request-serving service.
3. Run the prompt on Claude and check the top row stays capped.
4. Resolve the Gaps section by instrumenting the missing signals.
5. Wire the panel spec into Grafana or your data source.
6. Reuse the same prompt and framework for the next service.

A dashboard is only as good as the metrics behind it, which is why this pairs with the SLO definition prompt, since the SLIs you define are the panels that matter most, and with the alert tuning prompt, because the same signals that anchor your dashboard should anchor your alerts.

In the catalog, the Observability Instrumentation Harness generates dashboard stubs directly, and the Incident Postmortem Agent Pack uses those dashboards to reconstruct what happened.

Put the signal that matters top-left, cap the top row, and share one boring framework across every service. A dashboard you can read in two seconds is worth more than a clever one you can't.