Incident History Review Prompt for Release Risk

Release coordinators and QA managers use this prompt to systematically review recent incident records, postmortems, and unresolved problem tickets before making a release decision. The core job-to-be-done is connecting operational history to the specific release context—identifying recurring failure patterns, unresolved root causes, and systemic weaknesses that could amplify risk in the upcoming deployment. This prompt is designed for environments where incident data exists in structured or semi-structured form (ticketing systems, postmortem documents, runbooks) and the goal is a risk report that surfaces patterns a human reviewer might miss when scanning individual records.

The ideal input includes incident summaries with timestamps, severity classifications, root cause status (resolved, unresolved, partial), affected components, and any documented remediation actions. The prompt expects you to provide this context through placeholders like [INCIDENT_RECORDS] and [RELEASE_CONTEXT], which should contain the specific services, features, or infrastructure changes planned for the upcoming release. The model will cross-reference historical failure patterns against the release scope to identify where past incidents intersect with proposed changes. This works best when incident data is recent (last 3-6 months) and includes enough detail to distinguish between one-off environmental failures and systemic design weaknesses.

Do not use this prompt as a substitute for a security vulnerability review, a real-time monitoring assessment, or a formal threat model. It analyzes documented operational history—it cannot detect novel attack vectors, predict capacity failures from current load patterns, or replace the judgment of an on-call engineer evaluating live system telemetry. The output is a risk report that informs the release decision, not a binary go/no-go verdict. Always pair this analysis with current test results, deployment pipeline checks, and human review of any high-severity patterns the model surfaces. If your incident records lack root cause detail or are inconsistently classified, expect the model to flag uncertainty rather than fabricate connections.

This prompt template is designed to be dropped directly into your AI orchestration layer—whether that's a Python script, a LangChain node, an AWS Step Function, or a custom API call. It accepts a structured set of incident records, postmortem summaries, and unresolved problem tickets as input, and it enforces a strict output schema that your release management dashboard or CI/CD pipeline can parse. The prompt instructs the model to ground every finding in specific incident evidence, assign explicit confidence levels, and flag recurring failure patterns that might otherwise be missed in a manual review. Before using this template, ensure you have collected at least 90 days of incident history, postmortem documents, and any open problem tickets related to the services or components in the release scope.

codeCopy
SYSTEM: You are a release risk analyst reviewing incident history to assess deployment risk. Your output must be valid JSON matching the schema below. Every risk finding must cite specific incident IDs or postmortem references as evidence. Do not fabricate incidents or assume patterns without evidence. If evidence is insufficient to support a conclusion, set confidence to LOW and explain what data is missing.

USER:
Review the following incident history and produce a structured release risk report.

[INCIDENT_DATA]

[POSTMORTEM_SUMMARIES]

[OPEN_PROBLEM_TICKETS]

[RELEASE_SCOPE]

[OUTPUT_SCHEMA]:
{
  "report_id": "string",
  "generated_at": "ISO8601 timestamp",
  "review_period": {
    "start_date": "ISO8601 date",
    "end_date": "ISO8601 date"
  },
  "summary": {
    "total_incidents_reviewed": "integer",
    "incidents_in_scope": "integer",
    "open_problems_reviewed": "integer",
    "overall_risk_level": "LOW | MEDIUM | HIGH | CRITICAL",
    "overall_confidence": "HIGH | MEDIUM | LOW"
  },
  "recurring_failure_patterns": [
    {
      "pattern_id": "string",
      "description": "string",
      "affected_components": ["string"],
      "incident_references": ["string"],
      "frequency": "integer",
      "trend": "INCREASING | STABLE | DECREASING",
      "confidence": "HIGH | MEDIUM | LOW"
    }
  ],
  "unresolved_root_causes": [
    {
      "cause_id": "string",
      "description": "string",
      "originating_incidents": ["string"],
      "time_open_days": "integer",
      "blocking_release": "boolean",
      "remediation_status": "string",
      "confidence": "HIGH | MEDIUM | LOW"
    }
  ],
  "risk_findings": [
    {
      "finding_id": "string",
      "category": "RECURRING_INCIDENT | UNRESOLVED_ROOT_CAUSE | DEPENDENCY_RISK | CONFIGURATION_RISK | CAPACITY_RISK | OTHER",
      "severity": "LOW | MEDIUM | HIGH | CRITICAL",
      "description": "string",
      "evidence": ["string"],
      "affected_release_components": ["string"],
      "confidence": "HIGH | MEDIUM | LOW",
      "recommendation": "string"
    }
  ],
  "pre_release_remediation": [
    {
      "action_id": "string",
      "priority": "P0 | P1 | P2 | P3",
      "description": "string",
      "addresses_finding_ids": ["string"],
      "owner_suggestion": "string",
      "estimated_effort": "string"
    }
  ],
  "residual_risk_statement": "string",
  "human_review_required": "boolean",
  "human_review_reasons": ["string"]
}

[CONSTRAINTS]:
- Only reference incidents, postmortems, and problem tickets provided in [INCIDENT_DATA], [POSTMORTEM_SUMMARIES], and [OPEN_PROBLEM_TICKETS].
- If no incidents relate to the [RELEASE_SCOPE], state this explicitly and set overall_risk_level to LOW.
- For any finding with confidence LOW, include a specific note about what additional data would increase confidence.
- If any unresolved root cause has been open for more than 30 days and affects a component in [RELEASE_SCOPE], flag it as blocking_release: true.
- Set human_review_required to true if overall_risk_level is HIGH or CRITICAL, or if any finding has severity CRITICAL with confidence MEDIUM or LOW.
- Do not recommend skipping pre-release remediation for HIGH or CRITICAL severity findings.

To adapt this prompt for your environment, replace the square-bracket placeholders with real data before each invocation. [INCIDENT_DATA] should contain structured records with at minimum: incident ID, title, severity, status, affected components, detection date, and resolution date. [POSTMORTEM_SUMMARIES] should include the postmortem document ID, incident reference, root cause summary, and action items with completion status. [OPEN_PROBLEM_TICKETS] should list problem IDs, descriptions, linked incidents, and days since opened. [RELEASE_SCOPE] should enumerate the services, components, databases, and infrastructure being deployed in the candidate release. If your incident management tool (PagerDuty, ServiceNow, Jira) exports JSON or CSV, build a pre-processing step that maps those fields into the expected input structure before calling this prompt. For high-risk releases where the model's recommendation could block a deployment, always route the output through a human review step and log the full prompt, response, and reviewer decision for audit purposes.

The Incident History Review Prompt is designed to be integrated into a release gate pipeline, not run as a one-off chat. The primary integration point is a release coordinator dashboard or a CI/CD quality gate that triggers the prompt when a release candidate is proposed. The application layer is responsible for gathering the required inputs—incident records, postmortem documents, unresolved problem tickets, and the target release context—before assembling the prompt. This prompt is high-risk because it influences go/no-go decisions; therefore, the implementation must include validation, evidence grounding, and a mandatory human review step before any recommendation is accepted.

Wire the prompt into a structured workflow with these components: Input Collection—query your incident management system (e.g., PagerDuty, ServiceNow, Jira) for incidents in a configurable lookback window (default 90 days), filter by services included in the release scope, and retrieve linked postmortems and unresolved problem records. Prompt Assembly—populate the [INCIDENT_RECORDS] placeholder with a structured summary per incident (ID, severity, date, duration, affected service, root cause status, recurrence count), [POSTMORTEM_SUMMARIES] with key findings and action items, [UNRESOLVED_PROBLEMS] with open problem tickets and their age, and [RELEASE_CONTEXT] with the services, changes, and risk profile of the proposed release. Model Selection—use a model with strong reasoning and long-context handling (e.g., Claude 3.5 Sonnet, GPT-4o) because the prompt requires synthesizing patterns across potentially dozens of incidents. Set temperature to 0.1–0.2 for consistent risk assessment. Output Validation—parse the model response against the expected schema (risk level, recurring patterns, unresolved root causes, recommendations, confidence score). Reject outputs that lack specific incident references, contain unsupported risk claims, or omit the confidence score. Implement a retry with a stricter [CONSTRAINTS] block if validation fails. Human Review—route every output to a release coordinator for approval. The UI should highlight high-severity recurring patterns, unresolved root causes older than 30 days, and any recommendation that contradicts the quantitative risk score. Log the full prompt, response, validator results, and reviewer decision for auditability.

Common failure modes in production include: the model hallucinating incident patterns that don't exist in the provided records, over-indexing on a single severe incident while ignoring a pattern of low-severity recurrences, and producing recommendations that sound plausible but lack grounding in the specific incident data. Mitigate these by requiring the output to cite specific incident IDs for every claimed pattern, implementing a secondary eval prompt that checks whether each recommendation is traceable to at least one input record, and setting a minimum confidence threshold (e.g., 0.7) below which the output is automatically escalated for deeper human analysis. Do not use this prompt for real-time incident response or as a substitute for on-call judgment—it is a pre-release review tool, not an operational decision-maker. For regulated environments, ensure the audit log captures the full prompt, model version, response, validator output, and human reviewer identity and timestamp.