Degraded-Mode User Communication Prompt

This prompt is for product engineers and SREs who need to generate clear, honest status communications when a service or feature is degraded. The primary job-to-be-done is translating structured incident data—such as affected components, error rates, latency percentiles, and estimated recovery timelines—into user-facing messages that maintain trust while accurately conveying impact. Use this when your monitoring system, circuit breaker, or agent health check has detected a degradation event and needs to communicate it to end users through in-app banners, status pages, email notifications, or support channels. The ideal user is someone who understands the technical details of the incident but needs a reliable, automated way to convert that understanding into calibrated, audience-appropriate language without manual drafting during high-pressure incidents.

Do not use this prompt when the incident is still being diagnosed and no structured data is available—communicating uncertainty requires a different template that explicitly flags unknowns rather than synthesizing partial information. Do not use it for internal incident response coordination, where technical detail and raw telemetry are more valuable than polished user communication. Avoid this prompt when the degradation is security-sensitive and requires legal or executive review before any external communication; the prompt enforces tone calibration but cannot replace human judgment for disclosure timing and regulatory compliance. The prompt is designed for confirmed degradations with known scope, not for speculative early warnings that might cause unnecessary alarm or for post-resolution root cause analyses that belong in postmortems.

Before wiring this prompt into your incident communication pipeline, ensure your upstream systems can provide the required structured inputs: a list of degraded components, a list of components confirmed to be fully functional, an evidence-backed recovery timeline, and any available workarounds. The prompt's value comes from its enforcement of honesty constraints—it actively prevents overpromising recovery times and requires explicit acknowledgment of what remains functional. Test it against your historical incidents to verify that the tone calibration matches your organization's communication standards for different user audiences. The next step is to integrate this prompt into your agent's tool-calling flow so that degradation detection automatically triggers appropriate user communication without requiring manual intervention during incidents.

This prompt template is designed to be the single instruction you send to a model when a tool or service dependency has been degraded and you need to communicate the situation to end-users. It forces the model to synthesize technical incident data into a message that is transparent about the impact, clear about what still works, and free of corporate hedging. The template uses square-bracket placeholders that you must replace with live incident data from your monitoring systems, runbooks, or on-call engineer before sending it to the model.

textCopy
You are a technical communications specialist writing a user-facing status message during an active service degradation. Your goal is to be clear, honest, and helpful without causing unnecessary alarm.

Generate a status communication using the following incident data:

INCIDENT SUMMARY: [INCIDENT_SUMMARY]
AFFECTED FEATURES: [AFFECTED_FEATURES]
UNAFFECTED FEATURES: [UNAFFECTED_FEATURES]
USER WORKAROUNDS: [USER_WORKAROUNDS]
ESTIMATED RECOVERY TIME: [ESTIMATED_RECOVERY_TIME]
TARGET AUDIENCE: [TARGET_AUDIENCE]

Your response must follow this structure exactly:
1. A one-sentence headline summarizing the impact in plain language.
2. A "What's Happening" section (2-3 sentences) explaining the degradation without technical jargon.
3. A "What Still Works" section (bullet list) highlighting unaffected functionality.
4. A "What You Can Do" section (bullet list) with concrete user workarounds, if available.
5. A "Next Update" statement with the expected recovery time or next communication time.

CONSTRAINTS:
- Do not use phrases like "we apologize for any inconvenience."
- Do not minimize the impact or overpromise recovery.
- If no workaround exists, state "There is no workaround at this time" rather than omitting the section.
- Match the tone to the [TARGET_AUDIENCE]: for developers, be precise about affected endpoints; for end-users, use non-technical language.
- If [ESTIMATED_RECOVERY_TIME] is "unknown," state "We do not yet have an estimated recovery time" and commit to a specific next update time.

To adapt this template, replace each bracketed placeholder with data from your incident management system. The [INCIDENT_SUMMARY] should come from your on-call engineer's initial assessment. The [AFFECTED_FEATURES] and [UNAFFECTED_FEATURES] lists should be derived from your service dependency graph or health-check dashboard to avoid overstating or understating the blast radius. The [TARGET_AUDIENCE] field is critical: set it to "developers" if the message is going to a status page API, or "end-users" if it will appear in an in-app banner. Before sending the model's output to users, validate that the message does not promise a recovery time you cannot meet and that the unaffected features list is accurate. For high-severity incidents where the message will be customer-facing, route the generated text through a human review step before publication.

This prompt is not a standalone chatbot message; it is a function in a reliability pipeline. It should be called by an agent or backend service only after a degradation decision has been made upstream—by a circuit breaker, a load shedder, or a health check monitor. The caller must provide the structured degradation context as input, and the prompt's output should be treated as a candidate message that requires validation before it reaches a user. The implementation harness is responsible for supplying the right context, enforcing output contracts, and deciding whether the generated message is safe to send.

Wire the prompt into a service function that accepts a DegradationEvent object containing the required placeholders: [DEGRADED_SERVICE_NAME], [DEGRADATION_DESCRIPTION], [AVAILABLE_FUNCTIONALITY], [ESTIMATED_RECOVERY_TIME], [USER_WORKAROUNDS], and [AUDIENCE_TONE]. The function should call the LLM with response_format set to a strict JSON schema that includes subject_line, message_body, tone_label, and accuracy_flags. After receiving the response, run a validator that checks: (1) the tone_label matches the requested [AUDIENCE_TONE] using a lightweight classifier or keyword match, (2) the message_body does not promise a recovery time more specific than the input [ESTIMATED_RECOVERY_TIME], and (3) no functionality listed in [AVAILABLE_FUNCTIONALITY] is described as broken. If validation fails, retry once with the validation errors appended to the prompt as [PREVIOUS_VALIDATION_ERRORS]. If the retry also fails, escalate to a human reviewer and log the full prompt, response, and validation trace for postmortem analysis.

For high-stakes user surfaces such as status pages, authenticated dashboards, or regulatory-facing communications, insert a human approval step before the message is published. The harness should push the validated candidate message to a review queue with the originating DegradationEvent and the model's accuracy_flags. Do not bypass this gate based on confidence scores alone. For lower-stakes channels like non-critical email notifications, you may auto-publish after validation passes, but always log the decision for audit. Avoid wiring this prompt directly to a user-facing chatbot without the validation and approval harness; a raw model response that hallucinates recovery timelines or misstates available functionality will erode user trust faster than the original outage.