Incident Severity Scoring Prompt Template

This prompt is designed for SRE, NOC, and on-call engineering teams that need to classify unstructured incident reports into standardized severity levels (P0, P1, P2, P3) with high consistency. The primary job-to-be-done is replacing brittle, rule-based severity definitions with a few-shot classification model that learns from labeled examples. The ideal input is a human-written incident report or an aggregated alert summary that has already been composed into a coherent block of text—such as a chat message, an email, or a monitoring system digest. The output is a single severity label with a brief justification, ready to be used as a first-pass triage decision before a human reviews and confirms the classification.

Use this prompt when your incident intake pipeline receives unstructured text and you need a reliable, repeatable severity label that reduces cognitive load on on-call responders. The few-shot examples embedded in the template teach the model to distinguish between a complete service outage affecting all users (P0), a critical feature failure with no workaround (P1), a partial degradation with a viable mitigation (P2), and a minor cosmetic issue or informational alert (P3). This approach adapts faster to new incident patterns than maintaining long rule descriptions, because adding a new example is often sufficient to correct misclassifications. The prompt includes override conditions for ambiguous cases—such as when a report mentions both a P0-level symptom and a P3-level scope—and expects the model to default to the higher severity when evidence is conflicting.

Do not use this prompt for real-time alert streams where latency is measured in milliseconds. This is a classification step for incident reports that have already been written up by a human or aggregated by a monitoring system, not a replacement for streaming alert evaluation. Do not use it as the sole decision-maker for triggering automated remediation or paging workflows without human review; the model can misclassify novel failure modes that are underrepresented in the few-shot examples. If your incident taxonomy includes sub-severities, custom SLA tiers, or regulatory reporting requirements, you must adapt the example set and output schema accordingly. The next step after reading this section is to review the prompt template, substitute your own incident examples, and run the provided eval checks against a golden set of historical incidents before deploying to production.

This prompt template teaches the model to classify incident severity by providing concrete examples of each level rather than relying solely on abstract definitions. The square-bracket placeholders let you swap in your organization's actual incident categories, severity criteria, and override conditions. Replace the example blocks with your own labeled incidents drawn from real postmortems or runbook archives, and update the severity definitions to match your team's SLO-driven thresholds.

textCopy
You are an incident severity classifier for an SRE team. Your task is to read an incident report and assign a severity level of P0, P1, P2, or P3 based on the examples and criteria provided.

## SEVERITY DEFINITIONS
[SEVERITY_DEFINITIONS]

## CLASSIFICATION RULES
- Match the incident against the examples first. If a close example exists, follow its classification.
- If no example matches, apply the severity definitions directly.
- [OVERRIDE_CONDITIONS]
- If the incident matches multiple severity levels, choose the highest (most critical) level.
- If the report is too vague to classify, return "INSUFFICIENT_DATA" with a brief explanation.

## FEW-SHOT EXAMPLES

### Example 1
Incident Report: [EXAMPLE_INCIDENT_1]
Severity: [EXAMPLE_SEVERITY_1]
Rationale: [EXAMPLE_RATIONALE_1]

### Example 2
Incident Report: [EXAMPLE_INCIDENT_2]
Severity: [EXAMPLE_SEVERITY_2]
Rationale: [EXAMPLE_RATIONALE_2]

### Example 3
Incident Report: [EXAMPLE_INCIDENT_3]
Severity: [EXAMPLE_SEVERITY_3]
Rationale: [EXAMPLE_RATIONALE_3]

### Example 4
Incident Report: [EXAMPLE_INCIDENT_4]
Severity: [EXAMPLE_SEVERITY_4]
Rationale: [EXAMPLE_RATIONALE_4]

## INPUT
Incident Report: [INCIDENT_REPORT]

## OUTPUT FORMAT
Return a JSON object with the following fields:
{
  "severity": "P0" | "P1" | "P2" | "P3" | "INSUFFICIENT_DATA",
  "rationale": "Brief explanation referencing the matched example or severity definition",
  "matched_example": "Example number that most closely matches, or 'none' if no example matched",
  "confidence": "HIGH" | "MEDIUM" | "LOW"
}

To adapt this template, start by replacing [SEVERITY_DEFINITIONS] with your team's actual criteria—for example, P0 might mean 'complete service outage affecting all users,' while P3 might mean 'cosmetic issue with no user impact.' Populate the four example slots with real incidents that clearly illustrate the boundaries between levels. Include at least one example that sits near a boundary between two severity levels to teach the model how to handle ambiguous cases. The [OVERRIDE_CONDITIONS] placeholder should capture rules like 'any security incident involving customer data is automatically P0 regardless of user impact' or 'scheduled maintenance is never classified as an incident.' Test the prompt with incidents that fall between your examples to verify the model generalizes correctly rather than memorizing exact phrasing.

Before deploying this prompt into an on-call workflow, validate its output against a golden set of 20-30 pre-scored incidents that span all severity levels and include edge cases like multi-service failures, partial degradations, and incidents with conflicting signals. Run the prompt against these cases and measure exact-match accuracy for severity assignment. Pay special attention to incidents scored as INSUFFICIENT_DATA—if the model returns this for reports a human would classify, your examples may be too narrow. For high-risk production use, route LOW-confidence classifications to a human on-call responder for review rather than auto-escalating based on uncertain model output.

The Incident Severity Scoring prompt is designed to be a deterministic component within a larger incident management pipeline, not a standalone chatbot. It should be called programmatically via an API, receiving a structured incident report and returning a structured severity assessment. The application layer is responsible for assembling the input context, enforcing the output schema, and acting on the result. This prompt is a classification step; it does not create tickets, page on-call engineers, or update status pages. Those actions must be handled by the surrounding application logic after the severity score is validated.

To integrate this prompt, build a service function that accepts an incident object with fields like title, description, affected_service, and customer_impact. The function injects these values into the prompt's [INCIDENT_REPORT] placeholder along with the [SEVERITY_EXAMPLES] and [OUTPUT_SCHEMA]. After receiving the model's response, the harness must validate the JSON output against a strict schema, checking that severity_level is one of the allowed enums (P0, P1, P2, P3), confidence_score is a float between 0 and 1, and justification is a non-empty string. If validation fails, implement a retry loop with a maximum of 2 attempts, feeding the validation error back into the prompt's [CONSTRAINTS] section. For high-stakes environments, always route P0 and P1 classifications to a human on-call for explicit approval before triggering any automated paging or status page updates. Log the raw prompt, the model's response, the validation result, and the final severity score for auditability and prompt regression testing.

For model choice, a fast, cost-effective model like GPT-4o-mini or Claude 3.5 Haiku is sufficient for this classification task, as it relies on pattern matching against provided examples rather than deep reasoning. Avoid using this prompt in isolation for incidents with ambiguous or highly novel failure modes; in those cases, the low confidence score should trigger a fallback to a more capable model or direct human triage. The primary failure mode in production will be schema non-compliance or a severity score that contradicts the provided examples. Mitigate this by running a weekly eval job that tests the prompt against a golden dataset of 50 historical incidents with known severity labels, measuring exact match accuracy and flagging any drift for prompt maintenance.