Rollback Impact Communication Prompt

This prompt is for incident commanders and reliability engineers who need to translate a completed rollback into a clear, multi-audience stakeholder notification. The job-to-be-done is not deciding whether to roll back; it assumes the rollback has been executed and verified. The task is to take raw incident data—timestamps, affected services, error budgets, customer impact metrics—and produce a structured communication that gives engineering teams the technical depth they need, product managers the user-impact summary they require, customer support the language to use with affected users, and executives the high-level impact and resolution timeline. Use this prompt when the technical work is done and the remaining risk is miscommunication or misaligned expectations across the organization.

This prompt is not a substitute for an incident management tool, a status page update, or a postmortem document. It is a drafting aid that produces a structured notification ready for human review and approval before distribution. Do not use this prompt while the rollback is still in progress, when the full impact is unknown, or when you lack verified data on the scope and duration of the incident. The prompt requires concrete inputs: a verified incident timeline, a confirmed list of affected components, measured customer impact (error rates, latency, availability), and the current state after rollback. Without these inputs, the output will be speculative and should not be distributed. For high-severity incidents involving regulated data, financial loss, or safety impact, always route the draft through legal and communications review before sending.

Before using this prompt, gather your incident data and identify your audience list. The prompt template expects placeholders for [INCIDENT_SUMMARY], [TIMELINE], [IMPACT_METRICS], [AUDIENCE], and [NEXT_STEPS]. Each audience segment receives a tailored version of the notification, so you will run the prompt once per audience or use a batch variant that produces all versions in one structured output. After generation, validate the output against the raw incident data for factual accuracy, check that the tone matches each audience's expectations, and confirm that no speculative language has been introduced. The next section provides the copy-ready template you can adapt to your incident communication workflow.

This template produces a structured communication tailored to a specific audience—engineering team, executives, or affected customers—after a production rollback. It takes raw incident data, rollback details, and audience context as inputs and generates a message with an impact summary, timeline, and next steps. The prompt is designed to be copied directly into your AI system, with bracketed variables replaced by real incident data from your monitoring, ticketing, or incident management tools.

codeCopy
You are an incident communication specialist generating a stakeholder notification after a production rollback.

Generate a structured communication for [AUDIENCE_TYPE: engineering/executive/customer] based on the incident data below.

## Incident Context
- Incident ID: [INCIDENT_ID]
- Service Affected: [SERVICE_NAME]
- Rollback Trigger: [ROLLBACK_REASON]
- Rollback Start Time: [ROLLBACK_START_TIME]
- Rollback Completion Time: [ROLLBACK_COMPLETION_TIME]
- Deployment Version Rolled Back From: [FAILED_VERSION]
- Deployment Version Rolled Back To: [STABLE_VERSION]
- Duration of Impact: [IMPACT_DURATION_MINUTES] minutes
- User Impact Summary: [USER_IMPACT_DESCRIPTION]
- Error Rate During Incident: [ERROR_RATE_PERCENT]%
- Current Status: [CURRENT_STATUS]
- Root Cause Summary (if known): [ROOT_CAUSE_SUMMARY]
- Mitigation Steps Taken: [MITIGATION_STEPS]
- Next Steps Planned: [NEXT_STEPS]
- Links to Monitoring Dashboard: [DASHBOARD_URL]
- Links to Incident Ticket: [INCIDENT_TICKET_URL]

## Output Requirements
Generate a message with the following structure:
1. **Subject Line**: Clear, factual, includes service name and status.
2. **Impact Summary**: 2-3 sentences on what happened and who was affected. Use plain language appropriate for [AUDIENCE_TYPE].
3. **Timeline**: Key events in chronological order with times in [TIMEZONE].
4. **Current Status**: Confirmation that the rollback is complete and service is restored.
5. **Next Steps**: What the audience should expect or do next. For engineering: investigation details. For executives: business impact and timeline for RCA. For customers: any residual effects or actions required.
6. **Contact/Resources**: Where to get updates or ask questions.

## Constraints
- Tone: [TONE: factual/empathetic/urgent] based on audience and severity.
- Length: Keep total message under [MAX_WORD_COUNT] words.
- Do not speculate beyond the provided facts. Mark any unknown information as "Under investigation."
- Do not assign individual blame. Use system-level language.
- If [AUDIENCE_TYPE] is "customer," avoid internal tool names, version numbers, and technical jargon.
- If [RISK_LEVEL] is "high," include a statement about what is being done to prevent recurrence.

## Output Format
Return the communication as plain text with clear section headers. Do not use markdown formatting.

To adapt this prompt, replace each bracketed variable with data from your incident management system. The [AUDIENCE_TYPE] variable controls tone, technical depth, and what details are included or excluded. For high-severity incidents, set [RISK_LEVEL] to "high" to trigger the recurrence-prevention statement. Wire this prompt into a post-rollback workflow that triggers automatically when a rollback completes, pulling fields from your deployment tracker, monitoring dashboards, and incident ticket. Always route the generated communication to a human reviewer before sending, especially for executive or customer audiences where tone errors carry reputational risk.

This prompt is designed to be called by an incident management system or a chatops bot after a rollback has been executed and verified. The primary integration point is a webhook or API call that fires when a rollback event is marked as complete in your deployment tracker. The harness should supply the prompt with structured incident data—rollback start/end times, affected services, user-facing impact, and the current remediation status—pulled from your monitoring and ticketing systems. Do not call this prompt during an active incident before the rollback is confirmed; it is a post-action communication tool, not a real-time status update generator.

The implementation should enforce a two-stage validation pipeline. First, validate the input schema: ensure [INCIDENT_TIMELINE] contains at least a start time, rollback trigger time, and resolution time; [SERVICE_IMPACT] includes affected components and user-facing symptoms; and [AUDIENCE] is explicitly set to one of internal-engineering, internal-stakeholder, or external-customer. Reject the request with a structured error if required fields are missing. Second, validate the generated output before delivery. Check that the communication contains all required sections (Impact Summary, Timeline, Current Status, Next Steps), that the tone matches the audience profile, and that no placeholder tokens remain. For external-customer audiences, add a mandatory human review step in the pipeline—route the draft to an on-call communications lead or incident commander for approval before publishing to a status page or customer email.

Model choice matters here. Use a model with strong instruction-following and tone control, such as Claude 3.5 Sonnet or GPT-4o, because the prompt requires precise audience adaptation and structured output. Set temperature to 0.2 to reduce stylistic variance while preserving natural phrasing. For the retry strategy, implement a single automatic retry if the output fails schema validation (malformed JSON, missing sections). If the retry also fails, escalate to a human drafter and log the failure with the raw prompt context for debugging. Log every generated communication to an audit table with the incident ID, audience, reviewer, and final published text. This audit trail is critical for post-incident review and for demonstrating communication discipline to stakeholders. Avoid wiring this prompt directly to a public-facing publishing endpoint without the human review gate for external audiences—an automated apology with the wrong tone or incomplete information can compound the incident's impact.