Incident Severity Classification Prompt for Ops

This prompt is designed for SRE and operations engineers who need a consistent, auditable method for classifying production incidents into severity tiers (SEV0 through SEV4). The core job-to-be-done is translating an unstructured incident report—often written under pressure during an active event—into a structured severity assessment that directly controls paging policies, escalation paths, and response SLAs. Use this when your on-call workflow requires a deterministic severity label before automated alerting fires, or when you need to reassess severity during a postmortem to validate whether the initial classification matched actual impact. The prompt expects three categories of input: a free-text incident description, monitoring context (such as error rates, latency spikes, or alert annotations), and service catalog data that maps affected components to their criticality tier and owning team.

Do not use this prompt when the incident is still being triaged and impact is entirely unknown—severity classification requires at least a preliminary symptom description and some signal from monitoring systems. It is also inappropriate for non-production environments where severity tiers carry no operational consequence, or for classifying customer-reported issues that have not yet been confirmed as platform incidents. The prompt is not a replacement for your on-call engineer's judgment; it is a decision-support tool that produces a structured assessment with evidence alignment checks. In regulated environments where misclassification carries compliance risk, always route the prompt's output through a human reviewer before it triggers paging or external notifications. The classification must be traceable to specific evidence in the input, and the prompt includes explicit checks for missing information that would make a severity determination unreliable.

Before integrating this prompt into your incident response pipeline, ensure you have a well-defined service catalog with criticality mappings and documented on-call alerting thresholds for each severity tier. The prompt's effectiveness depends on these reference data being accurate and available at classification time. Start by testing against a golden dataset of 20-30 historical incidents where severity was correctly assigned and confirmed in postmortems, then measure classification agreement and identify systematic errors such as over-severity on noisy alerts or under-severity on silent failures. The next section provides the copy-ready prompt template with all required placeholders and adaptation guidance.

This prompt template is designed to be pasted directly into your AI system. It expects a defined severity taxonomy (e.g., SEV0-SEV4) and a service catalog as pre-loaded context. Replace all square-bracket placeholders with your organization's specific values before execution. The prompt instructs the model to produce a structured classification that includes the severity tier, a justification grounded in the provided incident description, the scope of impact, and any evidence of user-facing degradation.

textCopy
You are an SRE incident classifier. Your task is to analyze the provided incident description and assign a severity level based on the defined taxonomy.

[SEVERITY_TAXONOMY]
[SERVICE_CATALOG]

Incident Description:
[INCIDENT_DESCRIPTION]

Classify this incident and return a single JSON object with the following keys:
- "severity": The assigned severity level (e.g., "SEV1").
- "impact_scope": A string describing the scope of impact (e.g., "Global", "Single Region", "10% of Users").
- "affected_service": The primary service from the catalog that is affected.
- "user_degradation_evidence": A boolean indicating if there is explicit evidence of user-facing degradation in the description.
- "justification": A concise explanation linking the incident details to the specific criteria in the severity taxonomy.

[CONSTRAINTS]
- If the incident description is insufficient to determine severity, set "severity" to "UNKNOWN" and explain why in the "justification".
- Do not invent details not present in the incident description.
- Prioritize user-facing impact over internal system metrics when determining severity.

To adapt this template, replace the placeholders with your actual data. [SEVERITY_TAXONOMY] should contain the full text of your severity definitions. [SERVICE_CATALOG] should list your known services. [INCIDENT_DESCRIPTION] is the raw text of the alert or incident report. The [CONSTRAINTS] section is critical for high-risk operations; it forces the model to acknowledge uncertainty rather than hallucinate a severity level. Before deploying, run this prompt against a golden dataset of historical incidents to calibrate its alignment with your on-call alerting thresholds and to ensure the UNKNOWN fallback triggers appropriately on ambiguous inputs.

This prompt is designed to be called as part of an automated triage step when a new incident is declared or an alert fires. The typical integration point is a webhook receiver or a messaging bot that listens for incident creation events from PagerDuty, Opsgenie, or a custom monitoring system. The application layer should extract the raw incident title and description, populate the [INCIDENT_DETAILS] placeholder, and inject your organization's specific severity definitions into [SEVERITY_DEFINITIONS] before calling the model. Do not pass raw alert payloads with unredacted secrets, API keys, or internal hostnames directly into the prompt; strip those at the application layer first.

The model's output must be validated against a strict schema before any downstream action is taken. Expect a JSON object with severity_level, impact_scope, affected_service, and user_facing_evidence fields. Implement a validation guard that rejects any response missing these fields or containing a severity_level outside your defined enum (e.g., SEV1-SEV5). If validation fails, retry once with the same prompt and a stronger instruction to output valid JSON. If the second attempt also fails, escalate to a human on-call responder with the raw incident details and a note that automated classification failed. Log every classification attempt, including the raw model response and validation result, for postmortem analysis and prompt improvement.

For high-risk environments, add a human approval gate for any classification of SEV1 or SEV2 before the incident is broadcast or paged. The system should post the classification result to a review channel and wait for a human to confirm or override. This prevents a misclassification from waking up the wrong team or under-prioritizing a critical outage. For lower-severity classifications (SEV3-SEV5), you can auto-route to the appropriate queue, but always include the classification evidence in the incident ticket so responders can challenge it if needed. Avoid wiring this prompt directly to paging automation without a confirmation step for top-tier severities.