Operational Health Check Summary Prompt Template

This prompt is designed for AI operations leads and SREs who must produce recurring system health snapshots from production trace data. It synthesizes key health indicators such as availability, error rates, latency percentiles, tool-call success rates, and alert correlations into a structured status report with green/yellow/red assessments. Use this prompt when raw trace data is too verbose for stakeholder review but diagnostic signal must be preserved. The output is intended for engineering managers, product leads, and technical program managers who need a decision-ready summary, not a raw dashboard dump.

This prompt belongs in a scheduled reporting workflow where trace data is aggregated before being passed to the model. The required inputs include a time-bounded trace dataset, SLA thresholds for each metric, and a list of active or recent alerts. The model expects pre-aggregated numerical summaries—passing raw span-level traces will produce unreliable results. Before deploying this prompt, validate that your upstream aggregation pipeline correctly computes p95/p99 latency, error rates by category, and tool-call success/failure counts. A mismatch between the aggregation window and the reporting period is the most common failure mode.

This prompt is not a real-time alerting prompt and should not be used for incident response where second-by-second accuracy is required. It is also not a substitute for a dashboard—stakeholders who need interactive drill-down should use observability tools directly. Avoid using this prompt when the underlying trace data contains unresolved sampling gaps, when SLA thresholds are undefined, or when the audience expects raw data rather than a synthesized assessment. For high-severity incidents, use the Incident Root-Cause Summary Prompt Template instead; this prompt is for steady-state health reporting.

This prompt template is designed to be copied directly into your prompt management system or application code. It expects aggregated trace data to be injected into the placeholders before each invocation. The template enforces a structured output format with severity assessments, threshold-based evaluations, and alert correlation—ensuring that every health check summary follows the same diagnostic rigor regardless of which team member generates it. Replace each square-bracket placeholder with actual data from your observability pipeline before sending the prompt to the model.

textCopy
You are an AI operations analyst producing a recurring operational health check summary for stakeholders. Your task is to synthesize the provided production trace data into a structured status report with green, yellow, and red assessments for each health indicator.

## INPUT DATA

### Trace Aggregation Window
- Start: [START_TIMESTAMP]
- End: [END_TIMESTAMP]
- Environment: [ENVIRONMENT]
- Service/Model: [SERVICE_NAME]

### Key Metrics from Traces
- Total requests: [TOTAL_REQUESTS]
- Success rate: [SUCCESS_RATE_PERCENT]%
- Error rate: [ERROR_RATE_PERCENT]%
- Average latency (p50): [P50_LATENCY_MS]ms
- Average latency (p95): [P95_LATENCY_MS]ms
- Average latency (p99): [P99_LATENCY_MS]ms
- Token consumption total: [TOTAL_TOKENS]
- Estimated cost: [ESTIMATED_COST]

### Threshold Definitions
- Success rate warning threshold: [SUCCESS_RATE_WARNING]%
- Success rate critical threshold: [SUCCESS_RATE_CRITICAL]%
- Latency p95 warning threshold: [LATENCY_P95_WARNING]ms
- Latency p95 critical threshold: [LATENCY_P95_CRITICAL]ms
- Error budget remaining: [ERROR_BUDGET_PERCENT]%

### Top Failure Modes (from trace analysis)
[TOP_FAILURE_MODES]

### Recent Incidents and Alerts
[RECENT_INCIDENTS]

### Alert Correlation Data
[ALERT_CORRELATION_DATA]

### Comparison to Previous Period
[PREVIOUS_PERIOD_COMPARISON]

## OUTPUT SCHEMA

Produce a JSON object with the following structure:

{
  "report_metadata": {
    "generated_at": "ISO 8601 timestamp",
    "reporting_period": "[START_TIMESTAMP] to [END_TIMESTAMP]",
    "environment": "[ENVIRONMENT]",
    "service": "[SERVICE_NAME]"
  },
  "executive_summary": "One-paragraph summary of overall health status with the most critical finding first.",
  "health_indicators": [
    {
      "indicator": "Name of the health indicator",
      "status": "green | yellow | red",
      "current_value": "Measured value with units",
      "threshold": "Threshold that triggered this status",
      "trend": "improving | stable | degrading",
      "assessment": "Brief explanation of why this status was assigned"
    }
  ],
  "top_failure_modes": [
    {
      "category": "Failure category name",
      "frequency": "Count or percentage",
      "impact": "Description of user or system impact",
      "trend": "increasing | stable | decreasing"
    }
  ],
  "alert_correlation": {
    "correlated_alerts": ["List of alert IDs or descriptions that correlate with observed issues"],
    "uncorrelated_anomalies": ["Anomalies observed in traces without corresponding alerts"],
    "false_positives": ["Alerts that fired without corresponding trace evidence"]
  },
  "incident_summary": {
    "active_incidents": ["Brief descriptions of ongoing incidents"],
    "resolved_this_period": ["Brief descriptions of resolved incidents"],
    "incident_trend": "Description of incident frequency trend"
  },
  "recommendations": [
    {
      "priority": "high | medium | low",
      "recommendation": "Actionable recommendation",
      "rationale": "Why this recommendation matters based on trace evidence"
    }
  ],
  "data_quality_notes": ["Any caveats about data completeness, sampling gaps, or known measurement issues"]
}

## CONSTRAINTS

1. Assign statuses strictly based on the provided threshold definitions. Do not override thresholds with subjective judgment.
2. If a metric is within the warning threshold but not the critical threshold, assign "yellow." If it exceeds the critical threshold, assign "red."
3. For each red indicator, include at least one corresponding recommendation.
4. If alert correlation data shows alerts without trace evidence, flag them as false positives rather than ignoring them.
5. Do not fabricate failure modes or incidents not present in the input data.
6. If data is missing for any health indicator, note it in data_quality_notes and assign a status of "yellow" with the assessment "Insufficient data for assessment."
7. Keep the executive summary to three sentences maximum.
8. All trend assessments must be derived from the comparison data provided, not assumed.

## RISK LEVEL: [RISK_LEVEL]

If RISK_LEVEL is "high," add an additional field `escalation_required: true | false` to the report_metadata and include a `human_review_notes` field with specific items requiring manual verification before distribution.

Adaptation guidance: Before using this template, ensure your observability pipeline can populate every placeholder with real data. The [TOP_FAILURE_MODES] placeholder should receive pre-aggregated failure mode data from your trace analysis system—do not pass raw traces and expect the model to perform aggregation, as this introduces hallucination risk. The [RISK_LEVEL] placeholder controls whether the output includes escalation flags and human review notes; set it to "high" for reports going to executives or external stakeholders. If your organization uses different threshold definitions, replace the threshold placeholders with your actual SLO values rather than making the model infer them. For production deployments, validate the output JSON against the schema before distribution, and log any schema violations for prompt improvement cycles.

This prompt is designed to be part of a recurring, automated reporting pipeline, not a one-off chat interaction. The implementation harness should treat the prompt as a deterministic function: it receives structured trace data, applies the template, and returns a structured JSON report. The surrounding application code is responsible for data freshness, schema validation, retry logic, and human-in-the-loop approval before the report reaches stakeholders. Because the output includes green/yellow/red health assessments that may trigger operational decisions, the harness must prevent stale or hallucinated status indicators from being distributed.

The recommended wiring pattern is a scheduled job (e.g., a cron-triggered cloud function or an Airflow DAG) that executes the following steps: (1) Query your observability store for the relevant time window's trace data, aggregating metrics like p50/p95 latency, error rates, tool-call failure counts, and eval pass rates. (2) Populate the [TRACE_METRICS], [ALERT_HISTORY], and [TIME_WINDOW] placeholders with this structured data. (3) Call the model with the prompt template and a low temperature (0.0–0.2) to maximize consistency. (4) Validate the output JSON against a strict schema that checks for required fields (overall_status, indicators, recommendations), correct enum values (green, yellow, red), and threshold-to-status consistency (e.g., if error rate exceeds the defined threshold, the status must not be green). (5) If validation fails, retry once with the validation error message appended as a [CONSTRAINTS] note. If the retry also fails, escalate to a human reviewer with the raw metrics and the failed output. (6) On successful validation, route the report to a review queue where an on-call engineer or AI operations lead can approve, edit, or reject it before distribution.

For model choice, prefer a model with strong JSON mode and instruction-following capabilities (e.g., GPT-4o, Claude 3.5 Sonnet). Avoid models that struggle with structured output or tend to add unsolicited commentary outside the schema. If your trace data volume is large, pre-summarize it before passing it into the prompt; do not dump raw trace logs into the context window. Instead, provide pre-computed aggregates and a curated list of the top 3–5 anomalies or alerts. The prompt's [CONSTRAINTS] section should be dynamically populated with your organization's specific SLA thresholds so the model's color-coding aligns with real operational policy. Log every prompt invocation, the raw model response, validation results, and the final reviewer decision. This audit trail is essential for debugging threshold misalignment, model drift, or reviewer overrides over time.