Observability Dashboard Design Rubric Prompt

This prompt is for SREs, platform engineers, and engineering leads who need to audit the quality of an existing or proposed observability dashboard. The primary job-to-be-done is a structured, repeatable evaluation that goes beyond subjective opinion. The prompt produces a scored rubric assessing layout, signal hierarchy, actionable information density, and cognitive load, calibrated against SRE golden signals and incident response needs. Use it when you are inheriting a dashboard, conducting a pre-launch review, or standardizing dashboard quality across multiple teams.

The ideal user brings a specific dashboard definition to the review. This can be a screenshot, a JSON/JSONNET model, a list of panels and their queries, or a detailed description of the dashboard's purpose and audience. The prompt requires context about the underlying service's SLIs, its role in the system, and the primary on-call workflows the dashboard is meant to support. Without this context, the rubric will produce generic feedback that fails to assess whether the dashboard surfaces the right signals for the right people at the right time.

Do not use this prompt to generate a dashboard from scratch, to write PromQL or SQL queries, or to troubleshoot why a specific metric is missing. It is a review and scoring tool, not a design or debugging assistant. Avoid using it on dashboards that are purely for business analytics, executive reporting, or project management, as the rubric is grounded in operational SRE principles and will penalize designs that are optimized for a non-operational audience. For high-stakes reviews where a poor dashboard could delay incident detection, always pair the model's output with a human review by a senior SRE who understands the service's failure modes intimately.

This prompt template is the core of the playbook. It instructs the model to act as an SRE reviewer and evaluate a dashboard's design against a multi-dimensional rubric. The template uses square-bracket placeholders for all variable inputs, allowing you to adapt it for different dashboards, services, and review standards without rewriting the core logic. The output is a structured JSON object containing a score and justification for each rubric dimension, making it suitable for direct integration into an automated review pipeline or a human-in-the-loop approval workflow.

textCopy
You are an SRE reviewing an observability dashboard for a critical production service. Your goal is to produce a scored rubric evaluating the dashboard's design quality. You will be provided with the dashboard's title, a description of its panels, and the service it monitors.

Evaluate the dashboard against the following five dimensions, each scored from 1 (critically deficient) to 5 (exemplary). Provide a one-sentence justification for each score.

**Rubric Dimensions:**
1.  **Layout and Information Architecture:** Is the layout logical? Does it guide the on-call engineer's eye from high-level health to specific debugging details? Are related panels grouped together?
2.  **Signal Hierarchy and Golden Signals:** Does the dashboard prominently feature the four golden signals (Latency, Traffic, Errors, Saturation) for the service? Are these signals clearly labeled and easy to locate?
3.  **Actionable Information Density:** Does the dashboard present enough data to diagnose common issues without overwhelming the user? Are units, thresholds, and baselines clearly marked? Is there a clear distinction between "at a glance" status and deep-dive data?
4.  **Cognitive Load and Clarity:** Are chart types appropriate for the data? Are colors used consistently and meaningfully (e.g., red for errors)? Is the dashboard free of unnecessary decoration, confusing acronyms, or misleading axes?
5.  **Incident Response Readiness:** Can an on-call engineer use this dashboard to confirm an incident, understand its scope, and identify the likely failing component within the first 60 seconds? Are links to related runbooks, logs, or traces present?

**Inputs:**
[DASHBOARD_TITLE]
[DASHBOARD_PANEL_DESCRIPTIONS]
[SERVICE_NAME]
[SERVICE_SLOS]

**Output Format:**
Return ONLY a valid JSON object with the following structure. Do not include any text outside the JSON object.
{
  "dashboard_title": "[DASHBOARD_TITLE]",
  "service_name": "[SERVICE_NAME]",
  "overall_score": 0.0,
  "rubric_scores": {
    "layout_and_information_architecture": {
      "score": 0,
      "justification": "string"
    },
    "signal_hierarchy_and_golden_signals": {
      "score": 0,
      "justification": "string"
    },
    "actionable_information_density": {
      "score": 0,
      "justification": "string"
    },
    "cognitive_load_and_clarity": {
      "score": 0,
      "justification": "string"
    },
    "incident_response_readiness": {
      "score": 0,
      "justification": "string"
    }
  },
  "top_3_recommendations": ["string", "string", "string"]
}

To adapt this template, replace the bracketed placeholders with your specific data. [DASHBOARD_TITLE] and [SERVICE_NAME] are straightforward identifiers. [DASHBOARD_PANEL_DESCRIPTIONS] is the most critical input; provide a structured text list of each panel's title, chart type, and queried metrics. [SERVICE_SLOS] is optional but highly recommended, as it allows the model to calibrate its "Incident Response Readiness" score against real targets. For high-stakes reviews, always route the final JSON output to a human for approval before accepting the score as a release gate.

This prompt is designed to be called programmatically as part of a dashboard review workflow, not as a one-off chat interaction. The typical integration point is a CI/CD pipeline for observability-as-code repositories, a dashboard governance service, or an internal review tool that platform engineers use before promoting a dashboard to production. The prompt expects a structured [DASHBOARD_SPEC] input containing the dashboard JSON model, panel descriptions, target audience, and linked runbooks. The output is a JSON rubric with scores and justifications that downstream systems can parse and act on.

Wire the prompt into an application by constructing a request that includes the dashboard specification, the golden signals relevant to the service, and the incident response requirements. Validate the output against the [OUTPUT_SCHEMA] before accepting it: check that every dimension has a numeric score, a justification string, and a critical_findings array. If validation fails, retry once with the validation errors appended to the [CONSTRAINTS] field. For high-risk dashboards—those used in on-call rotations or incident response—route the scored rubric to a human reviewer via a Slack notification or review queue. The reviewer can override scores or add context before the dashboard is promoted. Log every rubric generation with the prompt version, model, input hash, and output scores for auditability.

Model choice matters here. Use a model with strong structured output capabilities and a context window large enough to hold the full dashboard specification. If the dashboard spec exceeds the context window, preprocess it by extracting panel titles, queries, thresholds, and layout metadata into a compact summary before passing it to the prompt. Do not use this prompt for real-time alert evaluation or as a substitute for SRE judgment during active incidents. The rubric is a design-time governance tool, not a runtime safety check. Pair it with a dashboard linter for syntactic checks and a cost attribution model for telemetry volume analysis to create a complete dashboard governance pipeline.