Error Code Remediation Playbook Prompt

This prompt is designed for support engineers, SREs, and operations teams who need to convert a raw error code into a complete, production-ready remediation playbook. The job-to-be-done is reducing mean time to resolution (MTTR) by ensuring every responder has immediate access to diagnostic queries, log patterns, configuration checks, rollback procedures, and customer communication templates. The ideal user is a technical operator who understands the system's architecture but needs a structured, repeatable format to document and share fix procedures across the team. You should use this prompt when you have a known error code and access to internal system context—such as architecture diagrams, log schemas, and configuration surfaces—that you can supply as variables to ground the output in your specific environment.

This prompt is not a replacement for a real-time monitoring system or an automated runbook executor. Do not use it for errors that are still being actively diagnosed or for novel failure modes where no root cause is yet understood. It is also not suitable for generating playbooks for third-party services where you lack internal telemetry, as the output will be generic and potentially misleading. The prompt assumes you can provide concrete system details; without them, the generated steps may reference non-existent dashboards, invalid CLI commands, or incorrect file paths. For high-risk domains such as healthcare, finance, or critical infrastructure, the output must always pass through a human review gate before publication, especially for steps involving destructive actions like database modifications, service restarts, or credential rotation.

Before using this prompt, gather the error code, a description of the affected service, links to relevant runbooks or architecture docs, and any known log patterns or metrics that correlate with the error. The more specific your input variables, the more actionable the playbook will be. After generating the playbook, validate each diagnostic command against a staging environment, confirm that rollback procedures match your current deployment tooling, and have a senior engineer sign off on any step marked as destructive. The next section provides the exact prompt template you can copy and adapt with your own system context.

This template is the core instruction set for generating an Error Code Remediation Playbook. It is designed to be pasted directly into your AI harness, with all square-bracket placeholders replaced by real data from your production systems before execution. The prompt instructs the model to act as a senior SRE and produce a structured, actionable guide that covers diagnostics, log queries, configuration checks, rollback procedures, and customer communication templates for a single error code.

markdownCopy
You are a senior Site Reliability Engineer (SRE) creating a definitive remediation playbook for a specific error code.

Your task is to analyze the provided [ERROR_CODE] and its associated [CONTEXT] to produce a comprehensive, step-by-step playbook. The playbook must be safe, actionable, and suitable for use by on-call engineers under pressure.

## Input Data
- **Error Code:** [ERROR_CODE]
- **Error Context:** [CONTEXT] (Include the full error body, HTTP status, affected service, and a brief description of the failure mode.)
- **System Architecture Notes:** [SYSTEM_ARCHITECTURE] (Optional: relevant data flow, dependencies, and infrastructure details.)
- **Observability Links:** [OBSERVABILITY_LINKS] (Optional: direct links to relevant dashboards, log explorers, and tracing tools.)

## Output Schema
Generate a playbook in the following structured format. Use the exact headings provided.

### 1. Error Summary & Impact
- **Error Code:** [ERROR_CODE]
- **Severity:** [SEV1/SEV2/SEV3] (Classify based on user impact and data risk.)
- **User-Facing Symptom:** A plain-language description of what the user experiences.
- **Technical Summary:** A concise technical explanation of the failure condition.

### 2. Diagnostic Queries
Provide specific, copy-pasteable queries for the following tools. If a tool is not available, state "N/A".
- **Log Explorer Query:** (e.g., Cloud Logging, Splunk, ELK)
- **Distributed Trace Query:** (e.g., Jaeger, Zipkin, Cloud Trace)
- **Metric/Dashboard Query:** (e.g., Prometheus, Datadog, Grafana)

### 3. Configuration & State Checks
List specific configuration files, feature flags, environment variables, or database states to verify. For each check, provide the command or path and the expected correct state.
- **Check 1:** [COMMAND_OR_PATH] -> Expected: [EXPECTED_STATE]
- **Check 2:** ...

### 4. Remediation Steps
Provide a numbered, ordered list of actions to resolve the incident. Start with the safest and most reversible action.
1.  **[Action Name]:** [Detailed command or procedure]
    - **Risk:** [Low/Medium/High]
    - **Rollback:** [Exact command or procedure to reverse this step]
2.  ...

### 5. Rollback & Recovery Procedure
If the primary remediation fails or causes a worse outage, describe the full rollback procedure to restore the last known good state.

### 6. Customer Communication Template
Draft a message for a public status page or customer support ticket.
- **Subject:** [Brief, non-technical subject line]
- **Body:** A clear, empathetic message explaining the impact, current status, and next update time. Do not include raw technical details.

## Constraints & Safety Gates
- **Destructive Action Gate:** If any step involves data deletion, irreversible schema changes, or traffic draining, you MUST prefix it with **[MANUAL APPROVAL REQUIRED]** and explain the justification.
- **Evidence Grounding:** Base all diagnostic queries and configuration checks strictly on the provided [CONTEXT] and [SYSTEM_ARCHITECTURE]. Do not invent file paths or tool names.
- **Uncertainty:** If the provided context is insufficient to determine a step, state "Insufficient context to determine [SPECIFIC_STEP]. Requires manual investigation." Do not guess.

To adapt this template, replace the placeholders with data from your production environment. The [CONTEXT] field is the most critical; it should contain the raw error payload and any immediate observations. For high-risk environments, ensure the final playbook is reviewed by a senior engineer before being added to your runbook library. The [MANUAL APPROVAL REQUIRED] gate is a critical safety feature—do not remove it for any step that could cause data loss or extended downtime.

The remediation playbook prompt is designed to be integrated into a support operations or site reliability engineering (SRE) workflow, not used as a one-off chat interaction. The primary integration point is a ticketing or incident management system where an error code and its surrounding context (stack trace, log snippet, affected service) trigger the prompt. The application layer should assemble the [ERROR_CODE], [ERROR_CONTEXT], and [SYSTEM_CONTEXT] variables from structured incident fields before calling the model. Because the output includes potentially destructive actions like rollback procedures or database queries, the prompt's [REVIEW_GATE] placeholder must be wired to a real approval step in the application, not just treated as a text suggestion.

A robust implementation wraps the model call in a validation and retry loop. After receiving the model's JSON output, validate it against a strict schema that requires the diagnostic_queries, log_patterns, configuration_checks, remediation_steps, and customer_communication_template fields. Each remediation_steps object must have a non-empty action, a risk_level enum of ['safe', 'caution', 'destructive'], and a rollback field. If validation fails, retry the prompt once with the validation errors injected into the [CONSTRAINTS] block. For any step marked destructive, the application must programmatically route the playbook to a human review queue and block automated execution until approval is logged. Log every generated playbook, the validator result, the reviewer's decision, and the final executed steps for auditability.

Model choice matters here: prefer a model with strong instruction-following and JSON mode support, such as Claude 3.5 Sonnet or GPT-4o, because the output must conform to a nested schema under pressure. If you are using a local or smaller model, add a lightweight post-processing step that extracts the JSON block from the response and repairs common formatting errors before validation. Avoid wiring this prompt directly to an automated execution engine without the destructive review gate. The next step after implementing the harness is to build a regression test suite using historical incidents where the correct remediation is known, and run the prompt against those cases to measure diagnostic accuracy and step safety before production deployment.