Incident Response Runbook Prompt for Third-Party Outages

This prompt is designed for on-call engineers and SRE teams who need to convert raw incident signals and tribal knowledge into a structured, auditable incident response runbook when a critical third-party service dependency fails. The primary job-to-be-done is eliminating the scramble of assembling ad-hoc Slack threads, scattered monitoring alerts, and mental checklists during a live outage. Instead, it produces a single source of truth that covers detection, severity classification, internal communication templates, and step-by-step mitigation actions. The ideal user is a senior on-call engineer or SRE lead who has already identified the affected third-party service and has access to concrete operational inputs: monitoring data, service dependency maps, escalation contacts, and known failure signatures.

You should use this prompt when you need to formalize a repeatable procedure for a known class of external dependency failure—such as a payment gateway timeout, an identity provider outage, or a cloud storage API degradation. The prompt assumes you can provide specific context, including the [AFFECTED_SERVICE_NAME], [OBSERVED_SYMPTOMS], [DEPENDENCY_MAP], and [ESCALATION_CONTACTS]. It is not a generic incident commander or a root-cause analysis tool for unknown failures. Do not use this prompt for first-party service incidents where your own code is the root cause, security breach response requiring forensic evidence handling, or physical infrastructure failures like power or cooling events. The output is a runbook, not a postmortem; it focuses on immediate response actions rather than long-term remediation.

Before using this prompt, gather the required inputs: the exact third-party service status page URL, relevant monitoring dashboard links, the internal service dependency graph showing upstream and downstream impacts, and the current on-call rotation contacts. The prompt will produce a runbook with detection criteria (what alerts fire), severity classification (how to determine SEV1 vs SEV2), internal communication templates (what to post in the incident channel), and mitigation steps (both automated failover actions and manual intervention paths). After generating the runbook, validate it against a tabletop exercise or a recent historical incident to ensure the steps are actionable and the escalation paths are current. Store the validated runbook in your incident management platform and link it to the corresponding monitoring alerts.

This prompt is designed to produce a complete incident response runbook in a single generation pass. Replace every square-bracket placeholder with details specific to your third-party dependency and internal operational context. The prompt instructs the model to generate detection criteria, severity classification, internal communication templates, and step-by-step mitigation actions—covering both automated checks and manual intervention paths. For complex dependency chains or services with many distinct failure modes, consider breaking the work into separate detection, communication, and mitigation prompts to keep each output focused and reviewable.

textCopy
You are an incident response documentation specialist. Your task is to produce a complete incident response runbook for when the third-party service [SERVICE_NAME] experiences an outage or degradation that impacts our product [PRODUCT_NAME].

## CONTEXT
- Service provider: [PROVIDER_NAME]
- Service documentation URL: [SERVICE_DOCS_URL]
- Service status page URL: [STATUS_PAGE_URL]
- Our integration surfaces that depend on this service: [LIST_DEPENDENT_FEATURES_OR_ENDPOINTS]
- Internal alerting channels: [ALERT_CHANNELS]
- Internal incident management tool: [INCIDENT_TOOL]
- On-call rotation contact: [ONCALL_CONTACT]
- Customer-facing status page URL: [CUSTOMER_STATUS_PAGE_URL]
- Support communication templates location: [TEMPLATES_REPO]

## CONSTRAINTS
- Every detection criterion must include a specific observable signal, not a vague symptom.
- Every severity level must include concrete user impact and a maximum time-to-acknowledge.
- Every mitigation step must specify whether it is automated or requires manual execution, and who is authorized to perform it.
- Communication templates must include placeholders for incident ID, timestamp, and estimated resolution time.
- Do not include actual credentials, secrets, or internal IP addresses in the output.
- If a mitigation step involves toggling a feature flag or circuit breaker, include the exact flag name and the rollback verification step.

## OUTPUT STRUCTURE
Produce the runbook with the following sections, using Markdown headings:

### 1. Detection Criteria
List observable signals that indicate [SERVICE_NAME] is degraded or unavailable. For each signal, include:
- Signal description
- Monitoring source (e.g., metric name, log query, health check endpoint)
- Threshold that triggers investigation
- False positive risk and how to rule it out

### 2. Severity Classification
Define severity levels (e.g., SEV1, SEV2, SEV3) specific to [SERVICE_NAME] outages. For each level, include:
- User-visible impact description
- Example scenario
- Maximum time-to-acknowledge
- Escalation path

### 3. Internal Communication Templates
Provide copy-pasteable templates for:
- Initial incident declaration in [INCIDENT_TOOL]
- Status update to internal stakeholders
- Handoff notes for on-call rotation
Each template must include placeholders for [INCIDENT_ID], [TIMESTAMP], [SEVERITY], and [ESTIMATED_RESOLUTION].

### 4. Customer-Facing Communication Template
Provide a template for updating [CUSTOMER_STATUS_PAGE_URL]. Include:
- Incident title format
- Initial notice language
- Update cadence recommendation
- Resolution notice language

### 5. Mitigation Steps
List step-by-step actions ordered by priority. For each step, include:
- Step number and description
- Execution type: AUTOMATED or MANUAL
- Required authorization level
- Expected outcome
- Rollback or verification step
- If the step involves a feature flag or circuit breaker, include the exact flag name

### 6. Post-Incident Actions
List actions required after [SERVICE_NAME] recovers, including:
- Verification that all dependent features are functional
- Customer communication confirming resolution
- Internal postmortem scheduling
- Any data reconciliation or backfill steps

### 7. Dependency and Escalation Map
List internal teams and external contacts relevant to this service, including:
- Team name and responsibility
- Escalation path (primary, secondary)
- Contact method during business hours and after hours

## RISK_LEVEL
[RISK_LEVEL: HIGH / MEDIUM / LOW]

If RISK_LEVEL is HIGH, add a section titled "8. Emergency Shutdown Procedure" with step-by-step instructions for disabling all [SERVICE_NAME]-dependent features, including feature flag names, circuit breaker manual trip commands, and user communication template for the shutdown.

After copying the template, replace every bracketed placeholder with your actual operational context. The [LIST_DEPENDENT_FEATURES_OR_ENDPOINTS] placeholder is critical—be exhaustive here, because any undocumented dependency surface becomes a blind spot during an incident. Set [RISK_LEVEL] to HIGH if the third-party service is in the critical path for revenue, user authentication, or data integrity; this triggers the emergency shutdown procedure section. Before putting the generated runbook into production, have the on-call team review it against at least one past incident for that service and verify that every detection signal maps to a real monitoring alert. Store the final runbook alongside your other incident response documentation, not as a one-off artifact.

This prompt is designed to be called from an incident management workflow, not a chat interface. Wire it into your incident declaration pipeline so that when an on-call engineer acknowledges a third-party alert, the harness assembles the context and generates a draft runbook automatically. The harness should pull dependency maps from your service catalog, feature flag names from your configuration store, and monitoring alert details from your observability platform.

Validate the generated runbook against a schema that requires every mitigation step to include an owner, a command or action, and a verification method. Flag any step that references a feature flag or circuit breaker not present in your configuration store. Log every runbook generation with the incident ID, the prompt version, and the model used. Store the generated runbook in your incident management tool as a comment or attached document. Require human review before the runbook is published to the broader response team.

The harness should also support a retry path: if the output fails schema validation, re-prompt with the validation errors appended as [CONSTRAINTS] and request a corrected runbook. Do not silently discard failed generations—log the failure and the validation errors so the team can improve the prompt or schema over time. Avoid using this prompt for incidents where the third-party outage is already fully documented with a known runbook; instead, surface the existing runbook directly.