Incident Severity Classification Prompt

This prompt is designed for incident commanders and on-call engineers who need to assign a consistent severity level during an active incident. The primary job-to-be-done is to evaluate observable signals—such as user impact breadth, data loss or corruption risk, revenue exposure, and SLA breach potential—against your organization's predefined severity definitions. Use this prompt when the incident is declared and initial signals are available but before the incident response team commits to a severity-driven escalation path. The ideal user has access to monitoring dashboards, alert context, and the organization's severity matrix, and needs a structured, defensible classification to guide response urgency and resource allocation.

This prompt requires several concrete inputs to function correctly. You must provide [SEVERITY_DEFINITIONS] that clearly articulate each level's criteria (e.g., SEV1: complete outage affecting all users, SEV2: degraded performance for a subset, SEV3: minor cosmetic issue). You also need [OBSERVABLE_SIGNALS] describing the current incident's symptoms, including affected user count or percentage, geographic or tenant scope, error rates, latency degradation, and any data integrity concerns. Optionally, include [REVENUE_IMPACT] estimates and [SLA_CONTEXT] to strengthen the classification. The prompt does not diagnose root cause or suggest remediation steps; it classifies severity and provides justification plus escalation triggers.

Do not use this prompt when the incident is still a vague alert without confirmed user impact, when you lack a documented severity matrix, or when the primary need is root cause analysis rather than classification. This prompt is also inappropriate for post-incident review or postmortem analysis—it is designed for the active triage window. If your organization uses dynamic severity levels that shift based on business hours or affected customer tier, ensure those rules are embedded in [SEVERITY_DEFINITIONS] before invoking the prompt. Using this prompt without clear definitions will produce inconsistent, untrustworthy classifications that undermine incident response.

Before using this prompt, confirm that your severity definitions are current, mutually exclusive, and understood by the entire on-call rotation. If your definitions have gaps—such as no clear boundary between SEV2 and SEV3 for partial outages—resolve those gaps first. The prompt's output includes a severity recommendation, a structured justification mapping signals to criteria, and escalation triggers that indicate when to reclassify. Treat this output as a decision aid, not an automated command. In high-stakes incidents involving data loss or regulatory exposure, a human must review and approve the classification before it drives paging or external communications.

This prompt template standardizes severity assignment during active incidents. It evaluates user impact, data loss risk, revenue exposure, and SLA breach potential against your defined severity levels. Replace every square-bracket placeholder with live incident data before execution. The prompt is designed to produce a structured severity recommendation with justification and explicit escalation triggers, not a free-text opinion.

textCopy
You are an incident severity classifier for [ORGANIZATION_NAME]. Your task is to assign a severity level to the active incident described below. Use only the severity definitions provided. Do not invent new severity levels.

## SEVERITY DEFINITIONS
[SEVERITY_DEFINITIONS]

## INCIDENT DATA
- Incident ID: [INCIDENT_ID]
- Title: [INCIDENT_TITLE]
- Start Time: [START_TIME]
- Detection Time: [DETECTION_TIME]
- Affected Services: [AFFECTED_SERVICES]
- User Impact Description: [USER_IMPACT]
- Error Rate (current vs baseline): [ERROR_RATE]
- Latency p95 (current vs baseline): [LATENCY_P95]
- Data Loss or Corruption Risk: [DATA_LOSS_RISK]
- Revenue Impact Estimate (hourly): [REVENUE_IMPACT]
- SLA Status: [SLA_STATUS]
- Workaround Available: [WORKAROUND_AVAILABLE]
- Recent Deploy or Config Change: [RECENT_CHANGE]
- Current Mitigation in Progress: [MITIGATION_IN_PROGRESS]

## OUTPUT SCHEMA
Return a single JSON object with these fields:
- severity_level: string (must match one of the defined severity levels)
- confidence: number (0.0 to 1.0)
- justification: string (cite specific evidence from the incident data)
- escalation_triggers: array of strings (conditions that would raise severity)
- recommended_responders: array of strings (teams or roles that should be paged)
- sla_breach_risk: string ("none", "warning", "imminent", "active")

## CONSTRAINTS
- If user impact is unclear or data is missing, set confidence below 0.7 and note what information is needed.
- If the incident meets criteria for multiple severity levels, choose the higher one.
- Do not downplay revenue impact or data loss risk.
- If a workaround exists but requires manual intervention, treat it as partial mitigation, not full resolution.

Before wiring this into a production harness, validate that your severity definitions are unambiguous and mutually exclusive. Ambiguous severity boundaries produce inconsistent classifications regardless of prompt quality. After each classification, log the prompt version, incident ID, model response, and the human-confirmed severity for audit and eval dataset construction. If the incident involves regulated data or safety-critical systems, require a human incident commander to confirm or override the classification before it becomes the official severity.

This prompt is designed to be the first deterministic step in an incident management pipeline, not a standalone chatbot. It should be called immediately after an incident is declared and before any remediation runbook is executed. The application layer must supply structured incident context—user impact counts, affected services, data loss indicators, and revenue exposure estimates—because the model cannot reliably infer these from raw alerts alone. Without this structured input, severity classification becomes guesswork and loses operational trust.

Wire the prompt into your incident response tool (e.g., PagerDuty, FireHydrant, or a custom Slack bot) as a synchronous API call with a strict timeout of 10 seconds. On success, parse the JSON output and validate that severity_level matches one of your predefined enum values (e.g., SEV1 through SEV5) and that confidence_score exceeds a configurable threshold—typically 0.7. If validation fails, retry once with the same payload; if it fails again, escalate to the human incident commander with the raw model output and validation errors logged. Log every classification attempt, including input context, model response, validation result, and final severity assignment, to an immutable audit table for postmortem review.

Model choice matters here. Use a model with strong instruction-following and JSON mode support, such as Claude 3.5 Sonnet or GPT-4o, because the output schema must be strictly parseable. Avoid smaller or older models that may drift the severity definitions or hallucinate escalation triggers. Do not use this prompt with streaming responses—the full structured output is required before any downstream automation acts on the severity. If your incident pipeline includes a RAG step for historical incident similarity, inject the retrieved similar incidents into the [CONTEXT] placeholder before calling the model, but keep the total prompt under 4,000 tokens to maintain low latency during active incidents.