Deployment Health Check Prompt for SRE

This prompt is designed for site reliability engineers and platform operators who need a structured, evidence-backed health assessment immediately after a deployment. The job-to-be-done is converting raw telemetry—metrics, logs, and alerts from a defined time window—into a consistent go/no-go recommendation. Use it when you have a known deployment timestamp, access to observability data, and a need to standardize the decision framework before proceeding with a full rollout or declaring the deployment stable. It acts as a reasoning layer that interprets signals, not a replacement for your observability stack.

The ideal user is an SRE or operator who can provide a scoped time window, a baseline for comparison, and the specific telemetry sources to analyze. The prompt requires you to supply [DEPLOYMENT_CONTEXT] (what changed and when), [TELEMETRY_DATA] (metrics, logs, and alert summaries), and [BASELINE_DATA] (pre-deployment metrics for comparison). It is not suitable for real-time incident response where seconds matter, for deployments without any baseline data, or for systems where the observability data is incomplete or untrusted. In those cases, the prompt will correctly escalate for human judgment rather than fabricate a recommendation.

Before using this prompt, ensure you have defined your evaluation criteria: what constitutes a healthy deployment in your environment? The prompt template includes placeholders for [PASS_CRITERIA] and [RISK_THRESHOLD] so you can encode your team's specific standards. After running the prompt, always validate the output against your own understanding of the system—this is a decision-support tool, not an automated gate. The next section provides the copy-ready prompt template you can adapt to your observability stack and deployment workflow.

This template is the core instruction set you will send to the model. It is designed to be copied directly into your AI harness, notebook, or orchestration layer. The prompt forces the model to act as an SRE conducting a post-deployment health check by analyzing provided metrics, logs, and alerts against a defined baseline. It strictly requires a structured output, making it suitable for direct integration into automated deployment pipelines where the result is parsed by downstream tooling.

markdownCopy
You are an SRE conducting a post-deployment health check. Your task is to analyze the provided data and generate a structured health assessment with a clear go/no-go recommendation.

## Deployment Context
- Service: [SERVICE_NAME]
- Deployment Version: [DEPLOYMENT_VERSION]
- Deployment Timestamp: [DEPLOYMENT_TIMESTAMP]
- Observation Window: [OBSERVATION_WINDOW]
- Baseline Window: [BASELINE_WINDOW]

## Input Data
### Metrics
[METRICS_DATA]

### Logs
[LOGS_DATA]

### Alerts
[ALERTS_DATA]

## Instructions
1. Compare the metrics from the `Observation Window` against the `Baseline Window`. Identify any significant deviations in key SRE signals: latency, traffic, errors, and saturation.
2. Analyze the logs for new or increased error patterns, warnings, or exceptions that correlate with the deployment timestamp.
3. Review any active or recently resolved alerts. Determine if they are deployment-related.
4. Synthesize your findings into a final health status: `HEALTHY`, `DEGRADED`, or `UNHEALTHY`.
5. Provide a clear `GO` or `NO-GO` recommendation for the deployment to proceed.
6. If the recommendation is `NO-GO`, list the top blocking issues and suggest immediate rollback or remediation steps.

## Output Format
You must respond with a single valid JSON object. Do not include any text outside the JSON structure.

[OUTPUT_SCHEMA]

To adapt this template, replace the square-bracket placeholders with real data before execution. The [METRICS_DATA], [LOGS_DATA], and [ALERTS_DATA] placeholders should be populated with pre-formatted text or structured data from your monitoring stack. The [OUTPUT_SCHEMA] placeholder is critical; you must replace it with a strict JSON schema definition (e.g., using JSON Schema or TypeScript interfaces) that matches your downstream application's expectations. For high-risk production deployments, always pair this prompt with a human-in-the-loop approval step for any NO-GO recommendation or before executing a suggested rollback.

The deployment health check prompt is designed to be called by an automation pipeline—typically a CI/CD system, a runbook automation tool, or an incident management platform—immediately after a deployment completes and a stabilization window has elapsed. The prompt expects structured inputs: a time window, a baseline comparison period, metric queries, log filters, and alert status. These inputs should be assembled programmatically from your observability stack (e.g., Prometheus, Datadog, CloudWatch, Splunk) rather than typed by hand. The output is a structured health assessment with a go/no-go recommendation, which your pipeline can parse to either proceed to the next stage or trigger a rollback and human review.

Wire the prompt into a function that accepts a deployment event payload containing the service name, deployment start time, stabilization window duration, and a list of health signals to check. Before calling the model, fetch the actual metric values, log counts, and alert states for both the post-deployment window and the baseline window. Pass these as structured context inside the prompt's [CONTEXT] block. Use a model with strong JSON output guarantees (e.g., GPT-4o with response_format set to json_schema, or Claude with a tool-use schema) and validate the output against a strict schema that includes recommendation (enum: go, no_go, manual_review), confidence (0-1), anomalies (array of objects with signal, severity, evidence), and summary (string). If the model returns manual_review or confidence falls below a configurable threshold (e.g., 0.7), route the assessment to a human on-call channel with the full evidence payload. Log every assessment, the raw prompt, the model response, and the human decision for audit and prompt improvement.

For high-risk deployments—those affecting payment systems, authentication, or data integrity—always require a human to acknowledge the assessment before the pipeline proceeds, even if the model returns go with high confidence. Implement a retry policy for transient model failures (up to 3 attempts with exponential backoff) but fail closed: if the model is unreachable, treat it as manual_review. Store the health check results alongside the deployment record so you can correlate future incidents with the assessment that approved the change. Avoid using this prompt for real-time health checks during incident response; it is designed for post-deployment verification, not live triage.