What should be communicated during an outage?

State affected services, known symptoms, useful actions and the next update. Avoid unconfirmed causes or restoration promises. Separate public information from sensitive technical details and keep a decision timeline for review.

Prepare a response to a website incident

Estimated reading time : 6 min · Published September 28, 2026

Classify incidents by observable impact

List essential journeys: read an offer, make an enquiry, book, pay or obtain service information. For each, describe a recognisable failure and its effect on visitors. A slow page differs in urgency from a purchase confirmed but not recorded.

Name who can detect, assess and decide on action. An alert, customer report or manual check can all reveal a problem. Record the time, URL, symptom and recent changes before guessing the cause.

Critical journeys known.
Severity tied to real impact.
Time and symptoms recorded.

Plan the first actions

Assign a coordinator and backup technical contact. Point to deployment history, backups, provider documentation and external status pages without placing secrets in the plan. Avoid simultaneous undocumented edits that make diagnosis harder.

For a security or personal-data event, follow the organisation’s specialist procedure and seek the relevant expert help. This guide covers coordination at the website level; it cannot replace an incident-specific technical or legal assessment.

Coordinator and deputy named.
One action and decision log.
Escalation route understood.

Communicate without inventing a deadline

Prepare a factual message: affected function, consequence for the visitor, workaround where available and time of the next update. Publish it through a channel that still works and offer another contact route if the website form is affected. Do not present a technical hypothesis as a confirmed cause.

Tailor the notice to the people affected. If public information was wrong, identify pages and messages to correct. Keep the same facts across the languages actually published.

Alternative channel identified.
Dated, understandable message.
Next update stated without a made-up restoration time.

Verify recovery and learn

After a fix, complete affected journeys on the live site: forms, payments, emails, redirects, content and mobile access as relevant. Check whether enquiries arriving during the incident were found or handled. An alert clearing does not show that the journey is fixed.

Write a brief note with timeline, impact, cause established or still uncertain, useful actions and a preventive change. Test the recovery plan and update contacts and procedures before the next incident.

Fictional timeline on 22 October 2026 in UTC: an incident is observed at 10:00 and the previous release is reinstalled at 10:05. At 10:08 the homepage again returns status 200; at 10:12 a test enquiry still fails. A recovered page therefore does not justify announcing recovery of the form. Only at 10:20 does the agreed journey obtain a reference that has actually been saved.

Record observations, actions and causal hypotheses separately. Reverting a release does not prove that the newer release was the sole cause. After the 10:20 check, keep enquiry reconciliation and the owner's decision on the follow-up list; do not turn one successful test into automatic closure. The example times are not a service recovery commitment.

Real production journeys retested.
Missed enquiries sought.
Plan and responsibilities updated after review.

Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.

Four fictional checkpoints before declaring recovery
UTC time	Observed item	Justified decision
10:05	Previous release reinstalled	Action completed; business recovery still to verify
10:08	Homepage accessible with status 200	Partial recovery observed; form not validated
10:12	Test enquiry not saved	Keep the incident open for the contact journey
10:20	Test enquiry saved with its reference	Checked journey recovered; enquiry reconciliation and closure decision remain

Google SRE : Managing Incidents
Google SRE, consulted 22 October 2026: incident coordination and tracking. The timeline and acceptance decisions are fictional.

Decide in a concrete situation

Fictional example: downtime coincides with an update without a confirmed cause. Prepare contacts, observations and recovery decisions; rollback alone does not establish that the incident is understood.

Separate observed facts, actions and hypotheses in a timeline. Keep evidence limited to analytical needs and identify decision authority; avoid destructive steps that erase useful evidence.

Inform visitors during a service outage
Prepare an interruption notice, a fallback contact and recovery checks without promising an unconfirmed restoration time.

Reference documents

ANSSI : Anticiper et gérer une crise cyber

When a visitor cannot open the site, this diagnostic helps compare devices, networks and services before concluding that the server is down. It complements incident communication by distinguishing a local access issue from a website issue. Server evidence and journey results still require separate review.

Connexion Internet France : isolate a connection fault (French)

Content updated on October 22, 2026

Documented reference points for this topic

Documented reference points for this topic
Reference	Value or syntax	Scope
HTTP · 503 2026-10-31	`503 · Retry-After`	Temporary unavailability; a delay may be indicated without guaranteeing recovery.

Dates indicate when references were consulted. These facts are neither a site audit nor an overall compliance statement.

Read an HTTP response before fixing the page

Choose a situation to separate the status meaning, the useful check and the pitfall. This reader explains cases; it does not test any address.

200Available page

What it means: The request succeeded. For an HTML page, also examine the returned content.
What to check: Check the title, main content and language, then the canonical and indexing directives.
Watch out for: A “not found” page returning 200 may become a soft 404. HTTP success does not guarantee indexing.

301 / 308Permanent move

What it means: 301 and 308 indicate a permanent new address. 308 explicitly preserves the method and body; with 301, a client may change POST to GET.
What to check: Open the old URL and check Location, a relevant destination and the absence of chains or loops.
Watch out for: Do not redirect every old page to the home page. For a form, also check the method expected at the destination.

302 / 307Temporary move

What it means: 302 and 307 indicate a temporary change. 307 preserves the method and body; with 302, a client may change POST to GET.
What to check: Check that the destination is available and that a return to the original address is planned.
Watch out for: A temporary redirect does not describe permanent removal. Do not replay a payment or order without checking its state.

404 / 410Missing or removed resource

What it means: 404 does not say whether the absence is temporary or permanent. 410 indicates a likely permanent removal.
What to check: Look for a broken link, a changed URL or deliberate removal. Offer a replacement only when it meets the same need.
Watch out for: A helpful error page must retain the actual 404 or 410 status. An error message with 200 does not fix the absence.

429Too many requests

What it means: 429 indicates request rate limiting. A Retry-After header may say when to try again.
What to check: Examine the limit’s scope and Retry-After. Slow down requests and bound retries.
Watch out for: Avoid immediate retry loops. Without an HTTP response, a network failure is not a 429 status.

503Temporarily unavailable service

What it means: 503 fits temporary unavailability, such as maintenance or overload. Retry-After may provide a delay or date.
What to check: Check the actual status, affected scope and return to normal service. Remove the notice after recovery.
Watch out for: Do not replace all pages with an error indefinitely. Persistent 5xx responses can eventually cause Google to remove URLs from its index.

Acceptance matrix to adapt to your project

These proposed checks use synthetic cases. Decide the required behaviour with the team, record the result and assign unresolved gaps before release.