--- title: What to Tell a Client During a Website Outage — Templates description: Copy clear website outage messages for acknowledgement, investigation, mitigation, recovery, delayed resolution, and post-incident follow-up. source: https://pingvera.com/blog/client-website-outage-communication-templates.html --- # What to Tell a Client During a Website Outage: Templates A useful outage message tells the client what is affected, what users can still do, what the agency is doing, any safe workaround, and when the next update will arrive. It separates confirmed facts from hypotheses and never waits for a root cause before acknowledging material impact. The agency should appoint one communications owner. Engineers provide facts; the owner turns them into consistent updates across email, the help desk, and the status page. ## At a glance Every incident update should answer: 1. What is affected? 2. Who or which regions are affected? 3. When did impact start, if known? 4. What remains available? 5. Is there a safe workaround? 6. What action is in progress? 7. When is the next update? Do not include an unverified cause, blame a vendor, expose security details, or promise a restoration time without evidence. ## Template 1: first acknowledgement **Subject:** Investigating an issue with [website/journey] We have confirmed an issue affecting [specific website or user journey]. Current impact: [what users cannot do]. Still available: [what remains usable, if relevant]. Workaround: [safe alternative or “none confirmed”]. Our team is [specific action: investigating, rolling back, working with provider]. We will send the next update by [time + time zone], even if the status has not changed. Template 2: impact still being assessed We are investigating reports of [symptom]. We have confirmed [known fact], but the full scope is not yet established. We are checking [relevant paths/regions/dependencies] and have paused unrelated production changes. The next update will be sent by [time + time zone]. Avoid “the website is down” if only one function is affected. Precision reduces unnecessary panic and later correction. ## Template 3: ongoing incident, no ETA The incident affecting [journey] is ongoing. Since the last update, we have: - [action and result]; - [action and result]. Current impact remains [impact]. [Workaround] remains available. We do not yet have a reliable restoration estimate. The next update will be sent by [time + time zone]. “No reliable ETA yet” is more credible than a repeated estimate that moves every 20 minutes. ## Template 4: mitigation in place We have applied a temporary mitigation for [incident]. [Affected journey] is now available through [normal path/workaround]. We are monitoring recovery and reconciling [orders/messages/data] created during the incident. This is not yet the final resolution. Next update: [time + time zone]. Template 5: third-party dependency The issue affecting [journey] is linked to [provider/dependency], based on [confirmed evidence or provider acknowledgement]. We have opened incident [reference] with the provider and are [testing a workaround/monitoring recovery]. Our agency remains responsible for coordination and updates under the support agreement. Current impact: [value]. Next update: [time + time zone]. Do not write “it is not our fault.” The client needs coordination, not a boundary dispute during the incident. ## Template 6: service recovered, observation continues [Website/journey] recovered at [UTC timestamp]. We have successfully tested [critical checks] and are monitoring the service for [observation window]. We are still checking [queue, email, orders, integrations, data consistency]. Please continue to use [workaround] until we confirm final resolution. Next update: [time + time zone]. Template 7: final recovery notice The incident affecting [journey] is resolved. Impact window: [start–end, with time zone]. Customer impact: [plain-language summary]. Recovery validation: [journeys, regions, downstream systems]. Remaining action: [none / planned follow-up]. We will provide [a short incident report / postmortem] by [date] because [trigger]. Template 8: missed detection discovered by the client Thank you for reporting this. We have now confirmed that [journey] has been affected since at least [earliest evidence]. Our monitoring did not detect this condition, and we are treating that as part of the incident. We are working on [mitigation] and checking the impact on [leads/orders/users]. The next update will be sent by [time + time zone]. After recovery, our report will include both the service failure and the monitoring gap. Do not invent an earlier detection time. Accuracy matters more than saving face. ## Template 9: potential security incident We are investigating a potential security issue affecting [system]. We have taken precautionary steps to [contain access/protect transactions] and activated the agreed security response contacts. At this stage, [confirmed impact]. We will not speculate about cause or affected data until the assessment is complete. The next authorised update will be provided through [channel] by [time + time zone]. Security, privacy, insurance, contractual, and regulatory notifications require the client's designated decision-makers and appropriate counsel. Do not reuse a normal outage template blindly. ## Short status-page templates ### Investigating > We are investigating failures affecting [journey] on [service]. The next update will be posted by [time UTC]. ### Identified > We have identified [confirmed technical component, not speculative blame] as the source of the [journey] disruption. Mitigation is in progress. Next update: [time UTC]. ### Monitoring > A mitigation has restored [journey]. We are monitoring stability and reconciling delayed work. Next update: [time UTC]. ### Resolved > [Journey] has remained healthy since [time UTC], and recovery checks are complete. The incident is resolved. [Report link or delivery date]. ## Update cadence by severity These are operational examples, not universal SLA targets. Choose a cadence the agency can actually sustain. ## Internal fact sheet for the communicator Incident ID: Approved severity: Confirmed impact: Unconfirmed hypotheses (internal only): Start time / earliest evidence: Mitigation status: Safe workaround: Security/privacy involvement: Client audience and channel: Last message sent: Next message due: Approver if required: Language and time-zone rules publish operational timestamps in UTC and optionally show the client's local zone; write the zone, not “at 3 PM”; use approved translations for high-impact multilingual services; keep the factual status consistent across languages; do not machine-translate sensitive legal or security notifications without review; identify which client contact may approve public statements. Common communication mistakes waiting for root cause before acknowledging impact; sending “we are investigating” with no next update time; copying internal logs into a client email; changing terminology between email and status page; promising “fixed” before downstream reconciliation; publicly naming an attacker or vendor without evidence; hiding a missed monitoring signal; letting five engineers answer the client independently. FAQ How soon should an agency tell the client? Follow the agreed trigger and severity policy. For confirmed material impact, acknowledge early with facts and a next update time. ### Should the agency apologise? A concise acknowledgement of impact is appropriate. Do not make legal admissions or assign liability without authorised review. ### What if nothing changed by the next update? Send the update. State that impact continues, what was attempted, and the next checkpoint. ### Should every outage appear on a public status page? No. Define which services and severities are public, private-client, or internal. Keep the policy consistent. ## Sources and further reading - [Google SRE: Managing Incidents](https://sre.google/sre-book/managing-incidents/) - [NIST SP 800-61 Rev. 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final) Reviewed: **8 August 2026**. Next: [Website maintenance SLA template](https://pingvera.com/blog/website-maintenance-sla-template.html) and [client-facing incident report](https://pingvera.com/blog/website-incident-report-template.html). Pingvera alerts can provide the timestamp, failed check, region, and recovery evidence used in these messages. A human communications owner should still approve meaning and client impact.