SRE Golden Signals Dashboard Prompt Template

This prompt is designed for Site Reliability Engineers (SREs) and platform engineers who need to translate a service description into a structured, implementation-ready dashboard specification. The core job is to take a high-level understanding of a service—its user-facing interactions, internal dependencies, and known failure modes—and produce a consistent, repeatable monitoring plan centered on the four golden signals: latency, traffic, errors, and saturation. Use it when onboarding a new service, standardizing observability across a fleet of microservices, or redesigning an existing dashboard that has become cluttered with vanity metrics and lacks a clear signal hierarchy.

The prompt assumes you have a solid grasp of the service's architecture but need a framework to force disciplined thinking about what to measure and why. It is not a replacement for that architectural understanding; if you cannot describe the service's critical paths, its dependencies, and what 'normal' looks like, the output will be generic and low-value. The prompt works best when you provide a concrete service description that includes user journeys, upstream and downstream dependencies, and the specific technologies involved (e.g., HTTP APIs, message queues, databases). Do not use this prompt to generate raw PromQL, SQL, or vendor-specific query syntax. Its output is a human-readable specification that an engineer then implements in their observability tool of choice, such as Grafana, Datadog, or Honeycomb.

Before running this prompt, gather the service's key architectural details: a list of user-facing endpoints or operations, the critical internal and external dependencies, any existing SLIs or SLOs, and a summary of the last one or two incidents if available. The prompt will guide you through defining panels for each golden signal, specifying the data sources, and structuring the dashboard layout for rapid diagnosis during an incident. After generating the specification, validate it against your on-call diagnostic workflows: can an on-call engineer locate the affected signal within 30 seconds? Does the dashboard surface saturation before it causes user-facing errors? If the answer is no, iterate on the specification before implementation.

This prompt template produces a structured dashboard specification covering latency, traffic, errors, and saturation panels. It is designed for SREs and platform engineers who need to move from service context to a concrete, implementable dashboard design. The template forces explicit consideration of SLIs, data sources, panel types, thresholds, and on-call diagnostic workflows. Before using this prompt, you should have a clear understanding of the target service's architecture, its critical user journeys, and the telemetry systems already in place.

textCopy
You are an SRE architect designing a Golden Signals dashboard for a production service. Your output must be a complete, implementation-ready dashboard specification.

## Service Context
- Service Name: [SERVICE_NAME]
- Service Description: [SERVICE_DESCRIPTION]
- Critical User Journey: [CRITICAL_USER_JOURNEY]
- Architecture Type: [ARCHITECTURE_TYPE] (e.g., monolith, microservice, serverless, event-driven)
- Protocol: [PROTOCOL] (e.g., HTTP/gRPC/async messaging)
- Dependencies: [DEPENDENCIES]

## Telemetry Context
- Metrics System: [METRICS_SYSTEM] (e.g., Prometheus, Datadog, CloudWatch, Grafana)
- Logging System: [LOGGING_SYSTEM]
- Tracing System: [TRACING_SYSTEM]
- Available Metric Namespaces: [AVAILABLE_METRIC_NAMESPACES]
- Dashboard Tool: [DASHBOARD_TOOL] (e.g., Grafana, Datadog, New Relic)

## Constraints
- [CONSTRAINTS] (e.g., cardinality limits, retention windows, cost budgets, compliance boundaries)

## Output Schema
Produce a JSON object with the following structure:
{
  "dashboard_title": "string",
  "service_identifier": "string",
  "panels": [
    {
      "signal_type": "latency|traffic|errors|saturation",
      "panel_title": "string",
      "description": "string explaining what this panel shows and why it matters",
      "query": "string (the actual PromQL/Datadog/CloudWatch query)",
      "visualization": "line|heatmap|stat|gauge|table",
      "thresholds": {
        "warning": "number or expression",
        "critical": "number or expression"
      },
      "slo_target": "string (the SLO this panel supports, or null)",
      "diagnostic_links": ["list of related panels or drill-down targets"]
    }
  ],
  "layout": {
    "rows": [
      {
        "row_title": "string",
        "panel_ids": ["list of panel indices from the panels array"]
      }
    ]
  },
  "on_call_workflow": {
    "initial_triage": "string describing which panels to check first when an alert fires",
    "diagnostic_path": ["ordered list of diagnostic steps"],
    "escalation_triggers": ["conditions that warrant escalation beyond first responder"]
  },
  "validation_notes": ["list of assumptions, known gaps, or data quality concerns"]
}

## Instructions
1. For each golden signal (latency, traffic, errors, saturation), design at least one panel.
2. Latency panels must distinguish between average, tail (p95/p99), and max latency where appropriate.
3. Traffic panels must show request rate, connection count, or message throughput relevant to the service protocol.
4. Error panels must separate client errors (4xx) from server errors (5xx) and include error rate as a percentage of total traffic.
5. Saturation panels must identify the most constrained resource (CPU, memory, I/O, connection pool, queue depth) and show utilization relative to capacity.
6. Every query must be syntactically valid for the specified metrics system.
7. Thresholds must be derived from SLO targets where available, or from reasonable operational defaults.
8. The on-call workflow must be actionable: a first responder should know exactly which panels to check and in what order.
9. If any required signal cannot be instrumented with available telemetry, note this explicitly in validation_notes and suggest a workaround or instrumentation gap.
10. Do not invent metric names. Use only the provided metric namespaces. If a metric is missing, state the gap.

After pasting this template, replace every square-bracket placeholder with concrete values from your service and telemetry environment. The most critical placeholders are [AVAILABLE_METRIC_NAMESPACES] and [CONSTRAINTS] because they determine whether the generated queries will actually execute. If you are unsure about available metrics, run a discovery query against your metrics system first and paste the results into the context. For high-risk production services, always have a second SRE review the generated dashboard specification before deploying it, and validate that every query returns expected data in a staging or pre-production environment.

This prompt is a design-side tool, not a runtime component. It should be integrated into a service onboarding template or a pull request checklist within your internal developer platform. When a new service entry is added to your service catalog, trigger this prompt automatically to generate an initial dashboard specification. The output is a JSON specification, so your harness must validate the JSON structure before presenting it to the user. If the JSON is malformed, use a retry loop with a simplified prompt that asks the model to fix the specific parsing error reported by your validator.

Store the generated specification in version control alongside the service's code. This ensures the dashboard design evolves with the service and can be reviewed in the same pull request workflow. For automation, use a CI/CD pipeline step that runs the prompt, validates the output against a JSON Schema that defines the required fields for each panel type (latency, traffic, errors, saturation), and posts the result as a comment on the service onboarding ticket. The human review step is critical: an SRE must approve the specification before any dashboard implementation work begins. This approval should be captured as a code review approval or a ticketing system sign-off.

For model choice, use a model with strong JSON generation capabilities and a context window large enough to hold your service catalog entry, any relevant SLO definitions, and the prompt template. If your service catalog contains sensitive data, run this prompt in a private deployment or ensure your API provider meets your data handling requirements. Do not bypass the human review step for production services. The model can propose a dashboard layout, but only an on-call SRE can validate that the proposed panels will actually help them diagnose an incident at 3 AM.