Alert Severity Classification Rubric Prompt

This prompt is for SREs, incident commanders, and platform engineering leads who need to replace ad-hoc severity calls with a consistent, defensible classification rubric. The job-to-be-done is producing a structured taxonomy that maps observable incident signals—user impact, data loss risk, blast radius, time sensitivity—to defined severity levels (SEV-1 through SEV-5), each with explicit response time expectations, escalation paths, and notification channels. Use this when your organization lacks a shared severity vocabulary, when cross-team incidents produce conflicting severity assignments, or when you are codifying an incident response program and need a reference document that survives an audit.

Do not use this prompt for real-time incident triage during an active outage. It is a design-time tool for creating the rubric, not a runtime classifier for live alerts. It is also not a replacement for an incident management platform's automation rules; the output is a policy document that humans and systems reference, not executable code. The prompt assumes you can provide context about your organization's scale, team structure, regulatory obligations, and existing incident tooling. Without that context, the model will produce a generic rubric that may not fit your operational reality. If you need a runtime severity classifier that acts on incoming alerts, pair this rubric output with a separate classification routing prompt that references the finalized taxonomy.

After generating the rubric, treat it as a draft for stakeholder review. Engineering managers, product owners, and customer support leads should validate that the severity definitions align with actual business priorities and that response times are achievable given on-call staffing. The next step is to load the rubric into your incident management tool, runbook system, and on-call training materials, then test it against a set of historical incidents to verify that classification is consistent across responders.

This prompt template is designed to produce a standardized severity classification rubric for your organization. It forces the model to define clear, mutually exclusive SEV levels, map them to operational response expectations, and provide concrete examples. The output is intended to be a starting point for an SRE team to debate, calibrate, and operationalize, not a final policy to be adopted without review.

textCopy
You are an SRE architect designing an alert severity classification rubric for an engineering organization.

Your task is to produce a clear, actionable rubric that incident commanders and on-call engineers can use to consistently classify incidents.

[CONTEXT]
The following is information about our system and organizational requirements:
- System Description: [SYSTEM_DESCRIPTION]
- User Base: [USER_BASE_DESCRIPTION]
- Existing SLO/SLI Targets (if any): [SLO_TARGETS]
- Regulatory or Compliance Requirements: [COMPLIANCE_REQUIREMENTS]
- On-Call Team Structure: [ON_CALL_STRUCTURE]

[OUTPUT_SCHEMA]
Produce a JSON object with the following structure:
{
  "rubric_name": "string",
  "version": "1.0",
  "severity_levels": [
    {
      "level": "SEV-0 | SEV-1 | SEV-2 | SEV-3 | SEV-4",
      "label": "string (e.g., Critical, Major, Minor, Warning, Info)",
      "definition": "string (a precise, testable definition of the impact)",
      "user_impact": "string (description of what users experience)",
      "response_sla": {
        "acknowledge": "string (e.g., 5 minutes)",
        "resolve_or_mitigate": "string (e.g., 1 hour)"
      },
      "escalation_path": "string (who is paged and when escalation occurs)",
      "notification_channel": "string (e.g., PagerDuty, Slack #incidents, email)",
      "examples": ["string (a specific, realistic scenario for this system)"],
      "post_incident_action": "string (e.g., Requires postmortem, Requires root cause analysis, Logged for trend analysis)"
    }
  ],
  "classification_guidelines": [
    "string (a rule to resolve ambiguity between levels)"
  ]
}

[CONSTRAINTS]
- Severity levels must be mutually exclusive. No incident should fit two definitions.
- The rubric must cover the full spectrum from "no user impact" to "complete service outage."
- Response SLAs must be realistic for the on-call structure provided.
- Examples must be specific to the system description, not generic.
- If regulatory requirements exist, ensure at least one severity level captures compliance-reportable events.
- Do not invent SLOs if none are provided; base definitions on user impact instead.

To adapt this template, replace the placeholders in the [CONTEXT] block with your specific system details. The more precise you are about your user base and compliance requirements, the more tailored the examples and definitions will be. After generating the rubric, treat it as a draft for a collaborative review session with your on-call team. The classification_guidelines field is critical for resolving edge cases; if the model's suggestions are insufficient, add your own based on past incident ambiguity. Always run the output through the evaluation checks described in the "Testing and Evaluation Criteria" section before considering it production-ready.

This prompt is designed to be called programmatically, not used as a one-off chat interaction. The primary integration point is within an incident management or alerting platform where a raw alert payload or incident description needs to be classified into a consistent severity taxonomy. The application should construct the prompt by injecting the specific alert context into the [ALERT_PAYLOAD] placeholder and the organization's operational constraints into [ORG_CONTEXT]. The model's response must be parsed as structured JSON and validated before any downstream action, such as paging an on-call engineer or updating an incident ticket, is taken.

A robust implementation harness requires strict output validation. The model's JSON response must conform to a predefined schema that includes the severity level, a justification grounded in the provided rubric, and a confidence score. Implement a validation layer that checks for: (1) the presence of all required fields, (2) the severity level matching one of the allowed enum values from the rubric, and (3) the confidence score being a number between 0 and 1. If validation fails, implement a retry loop with a maximum of two additional attempts, feeding the validation error message back into the prompt as [PREVIOUS_ERROR] to guide self-correction. For high-severity classifications (e.g., SEV0 or SEV1), the system should bypass automatic execution and instead route the classification and justification to a human incident commander for explicit approval before triggering the notification workflow.

Logging is critical for auditability and debugging. Log the full prompt, the raw model output, the validated classification, and any retry attempts to a structured logging system, ensuring that any sensitive data within the alert payload is redacted according to your telemetry data governance policies. Model choice involves a trade-off between latency and reasoning quality; a faster model may suffice for clear-cut cases, but a more capable model should be used when the initial classification confidence is below a threshold (e.g., 0.85). To prevent alert fatigue, integrate a deduplication check before classification: if an active incident with a similar fingerprint already exists, the harness should attach the new alert as a note to the existing incident rather than creating a new one and re-running the classification prompt.