Incident Severity Upgrade Approval Prompt

This prompt is designed for incident commanders and SRE teams who need a formal, evidence-based proposal to escalate the severity of an already-declared incident. The core job-to-be-done is generating a structured, auditable request that justifies the upgrade by linking it to concrete impact metrics, SLA implications, and resource mobilization needs. The ideal user is an on-call engineer or incident manager who has observed a material change in the incident's scope or customer impact and must secure explicit human approval before expanding the response. Required context includes the current incident record, the proposed severity level, and the specific triggering evidence that warrants the change.

Use this prompt when your incident management workflow requires a formal approval gate before taking actions like expanding the notification scope to executive stakeholders, pulling in additional on-call teams, or invoking higher-tier SLA commitments that carry financial penalties. The prompt forces the AI to structure the proposal with a direct comparison of current versus proposed severity, a quantification of customer impact, and a clear statement of the additional resources required. For example, if a P2 incident affecting a single region begins to show cascading failures across multiple availability zones, this prompt will generate a proposal that cites the new error budget burn rate, the number of newly affected users, and the specific teams that must be mobilized, rather than a vague request for more help.

Do not use this prompt for the initial severity assignment during triage; it is specifically designed for upgrade proposals on active incidents. It is also inappropriate for downgrade proposals, routine status updates, or post-incident reviews. The output should be treated as a draft for human review, not an automatic execution command. Before relying on this prompt in production, validate its output against your organization's specific severity definitions, SLA contracts, and escalation policies to ensure the AI's justification language matches your internal runbooks.

This prompt template is designed to be pasted directly into your AI system when an on-call engineer or monitoring system flags a potential need to escalate an incident's severity. It forces the model to act as a disciplined SRE assistant, producing a complete, evidence-backed request rather than a casual suggestion. The template uses square-bracket placeholders that you must replace with live incident data from your monitoring, ticketing, and communication tools before sending the request to the model. The output is a structured approval payload intended for a human incident commander to review and sign off on before any severity change is applied in your incident management platform.

codeCopy
You are an SRE incident response assistant. Your task is to draft a severity upgrade approval request for a human incident commander. You must not execute any changes. You must only produce a structured request for review.

Use the following inputs to construct the request:
- Current Incident ID: [INCIDENT_ID]
- Current Severity Level: [CURRENT_SEVERITY]
- Proposed Severity Level: [PROPOSED_SEVERITY]
- Incident Title: [INCIDENT_TITLE]
- Time of Initial Detection: [DETECTION_TIME]
- Affected Service(s): [AFFECTED_SERVICES]
- Current Impact Summary: [CURRENT_IMPACT_SUMMARY]
- New Evidence Triggering Upgrade: [ESCALATION_EVIDENCE]
- Customer Impact Metrics (e.g., error rate, p99 latency, affected user count): [CUSTOMER_IMPACT_METRICS]
- Affected SLA/SLO Commitments: [AFFECTED_SLA_COMMITMENTS]
- Proposed Notification Scope Expansion: [NOTIFICATION_SCOPE_EXPANSION]
- Additional Resources or Teams to Mobilize: [RESOURCE_MOBILIZATION]
- Relevant Monitoring Dashboard Links: [DASHBOARD_LINKS]
- Current Incident Commander: [INCIDENT_COMMANDER]

Generate a JSON object with the following schema. Do not include any text outside the JSON object.

{
  "request_id": "string, a unique ID for this upgrade request",
  "incident_id": "string, the [INCIDENT_ID]",
  "timestamp": "string, ISO 8601 timestamp of this request",
  "requested_by": "AI SRE Assistant",
  "severity_change": {
    "current": "string, [CURRENT_SEVERITY]",
    "proposed": "string, [PROPOSED_SEVERITY]",
    "justification_summary": "string, a concise 2-3 sentence summary of why the upgrade is necessary based on [ESCALATION_EVIDENCE]"
  },
  "impact_analysis": {
    "customer_impact": "string, a quantified description of user-facing impact from [CUSTOMER_IMPACT_METRICS]",
    "sla_impact": ["list of strings, each describing a specific SLA/SLO at risk from [AFFECTED_SLA_COMMITMENTS]"],
    "affected_services": ["list of strings from [AFFECTED_SERVICES]"]
  },
  "required_actions": {
    "notification_scope": "string, description of who needs to be notified from [NOTIFICATION_SCOPE_EXPANSION]",
    "teams_to_mobilize": ["list of strings from [RESOURCE_MOBILIZATION]"]
  },
  "evidence_links": ["list of strings, URLs from [DASHBOARD_LINKS]"],
  "approval_required_from": "string, the [INCIDENT_COMMANDER] or their designated alternate",
  "risk_of_not_escalating": "string, a clear statement of the consequences if severity remains at [CURRENT_SEVERITY]"
}

Constraints:
- If [ESCALATION_EVIDENCE] does not contain a quantifiable change in customer impact, set "risk_of_not_escalating" to "Insufficient quantitative evidence to assess risk. Human review required."
- Do not fabricate metrics. Use only the data provided in [CUSTOMER_IMPACT_METRICS]. If data is missing, state "Data not provided" for that field.
- If [PROPOSED_SEVERITY] is not a higher severity than [CURRENT_SEVERITY], set "severity_change.justification_summary" to "ERROR: Proposed severity is not an upgrade. Request invalid."

To adapt this template, start by integrating it with your incident management API. The placeholders like [INCIDENT_ID] and [CURRENT_IMPACT_SUMMARY] should be populated programmatically from your ticketing system (e.g., PagerDuty, Opsgenie, ServiceNow) and observability platforms (e.g., Datadog, Grafana). The [ESCALATION_EVIDENCE] field is the most critical; it should be a pre-processed summary of the alert or log that triggered the review, not raw log lines. Before sending this prompt, validate that all required fields are non-null in your application layer to prevent the model from receiving an incomplete request. After receiving the JSON output, your system should validate it against the schema, check for the ERROR: string in the justification, and then post the structured request to the incident commander's review queue—never automatically applying the severity change.

Integrating the Incident Severity Upgrade Approval Prompt into a production system requires treating it as a gated decision point, not a free-text generator. The prompt should be invoked by an incident management agent or an automated monitoring pipeline when a potential severity mismatch is detected—for example, when the number of affected users, error budget consumption, or customer-reported impact exceeds the thresholds defined for the current severity level. The calling application must assemble the required inputs: the current incident record, the proposed severity level, the evidence of impact (metrics, logs, customer reports), the affected SLA commitments, and the expanded notification scope. These inputs populate the [CURRENT_SEVERITY], [PROPOSED_SEVERITY], [IMPACT_EVIDENCE], [AFFECTED_SLAS], and [NOTIFICATION_SCOPE] placeholders in the prompt template.

The model's output must be validated against a strict JSON schema before any action is taken. Define a schema that requires fields such as approval_decision (enum: APPROVE, REJECT, NEED_MORE_INFO), justification_summary, customer_impact_quantification, resource_mobilization_needs, and risk_of_not_upgrading. If the model's response fails schema validation, implement a retry loop (maximum two retries) that feeds the validation error back into the prompt as additional context. If validation continues to fail, escalate the raw output to the on-call commander via the incident channel without automated action. For model choice, use a model with strong instruction-following and structured output capabilities (e.g., Claude 3.5 Sonnet or GPT-4o with response_format set to json_object). Do not use a small or fast model for this task; the cost of a hallucinated severity upgrade—unnecessary paging, misallocated resources, SLA confusion—far outweighs the latency or token savings.

Log every invocation, including the full prompt, the model's raw response, the validation result, and the final action taken, to your incident audit trail. This is critical for post-incident review and for tuning the prompt's thresholds over time. Wire the approved upgrade into your incident management tool (e.g., PagerDuty, Opsgenie) via API, but only after the approval payload has been validated. Never allow the model to directly call the severity-change API; the application layer must be the sole executor of state changes. If the prompt returns NEED_MORE_INFO, the application should pause the escalation workflow and post a structured request for the missing data into the incident's communication thread, tagging the incident commander. The next step is to build a set of evaluation cases—both clear upgrades and borderline scenarios—and run them through this harness before deploying to production.