Principles
- Tell them before they have to ask. The best message arrives before the client notices. The second best arrives within minutes of their first message.
- Lead with impact, not cause. “Your checkout is not working” before “a plugin update conflicts”.
- Say what you know, what you do not and when you will say more. All three, every time.
- One owner, one channel. The client should know who writes to them and where.
- Do not guess in writing. A wrong cause is worse than an unknown one.
- Do not blame the client, the host or a colleague. Facts only.
- Close the loop. Every incident ends with a message that says it is over, how long it lasted and what changes.
Who to tell and how
| Severity | Examples | Who | Channel |
|---|---|---|---|
| Critical | Site down, checkout broken, data exposed | Decision-maker and operations contact | Phone or chat first, then email |
| Major | Site slow, form not delivering, some pages broken | Operations contact | Email or chat |
| Minor | A broken image, a cosmetic error, a short regional issue | Operations contact | In the monthly report, or email if they will notice |
Agree this table with each client when you set up the retainer, with names and numbers. It is much easier to follow than to invent at 02:00.
When to send
- First message: within 15 minutes of confirming a critical incident, within an hour for a major one, during office hours. If the retainer includes out-of-hours cover, say how it works.
- Updates: at the interval you promise, even if nothing changed. “No change; next update at 11:30” is a valid update.
- Resolution: as soon as you have verified the fix from outside.
- Wrap-up: within one working day for a major incident, in the monthly report for the rest.
The first message
Short, factual and free of jargon. Template:
Subject: [Site] is currently unavailable / not working properly
Hello [Name],
At [time, time zone] our monitoring confirmed that [what visitors see:
the website is not loading / the checkout shows an error / the contact
form does not send].
What we know: [one or two facts, e.g. "the server is not responding";
"it started after the update at 10:05"].
What we do not know yet: [the cause].
What we are doing: [rolling back the update / contacting the host].
Next update: [time]. You do not need to do anything. If customers ask,
you can tell them [one sentence they can use].
[Name], [role], [phone]Notes: say “confirmed” only if it is (see Two-region confirmation), give a sentence the client can reuse with their own customers, and say whether they need to act.
The update
Subject: Update: [Site] [state]
[Time]: [Status: still investigating / cause identified / fix applied,
monitoring].
Impact now: [what visitors see].
Change since the last update: [or "none"].
Next update: [time].The resolution
Subject: Resolved: [Site] is working again
The site has been working normally since [time]. It was affected from
[start] to [end] ([duration]).
What happened: [plain-language cause, or "we are still confirming the
cause and will send a summary by [date]"].
What it affected: [pages, orders, forms; anything that may need follow-up,
such as orders placed in that window].
What we have done: [fix].
What we will do to prevent it: [change, test, monitoring].
I will include this incident in the [Month] report.The wrap-up (major incidents)
A short post-incident note, within a working day, containing:
- a timeline with times (start, detection, first message, fix, verification);
- the cause, stated plainly, and what changed just before;
- the impact, with numbers if you have them (minutes, failed orders);
- what you changed to prevent a repeat, and by when;
- any decision you need from the client (budget for a better host, a staging environment).
Honesty about causes that were yours is the single best trust-builder.
Special cases
- Security-relevant changes. If you suspect a compromise (injected content, unknown users, an unexpected DNS change), tell the client promptly and factually. Do not wait to be certain. Say what you will do to investigate, and what they should do (change passwords, tell their customers if data may be involved). Legal duties depend on country and facts; get advice, and do not promise more than you know.
- A false alarm. If the client saw an alert and the site was fine, say so briefly, and say what you changed to avoid it. Do not hide it.
- The cause is the client’s provider. State the fact and what you did (opened a ticket, chased). Offer options; do not argue.
- Planned maintenance. Announce it beforehand with a window and what visitors will see. A temporary unavailability on purpose should answer with 503 Service Unavailable, not an ordinary page (RFC 9110).
What not to say
- “It’s fixed” before you have checked from outside.
- “It was probably...” in writing.
- “This never happens” when it has.
- Technical detail that the client cannot use, or that exposes security weaknesses.
- Promises you cannot keep (“it won’t happen again”).
Make it a habit
Keep these templates in your ticket system. Add each client’s names, channels and severity table to their record. Run a drill once a year: a fake incident, a first message sent to a test address. Review every real incident at the end of the month, and ask what the client would have wanted to know sooner.
How Beamfar helps
Beamfar alerts you by email, Slack or signed webhook when two regions confirm a site is down, with what each region saw, which makes the “what we know” line of the first message quick to write. Its what-changed timeline shows a DNS, certificate, redirect or SEO change that happened just before the incident, and the public status page for the client shows confirmed incidents only. The words to the client are yours; Beamfar does not send messages to your clients on its own.
Questions
How quickly should I tell a client about an outage?
Aim to send the first message within about 15 minutes of confirming a critical incident, and to agree the target with each client in advance. Then update at the interval you promised.
Should I tell the client the cause before I am sure?
Say what you know and what you do not. A wrong cause stated early costs more trust than an honest “we are still investigating”.
What should a post-incident summary include?
A timeline, the cause, the impact, what you changed to prevent a repeat and any decision you need from the client.
Do I have to tell the client about a false alarm?
Yes, briefly, if they saw an alert or noticed. Say what caused it and what you changed. Hiding it makes the next real alert harder to believe.
Sources
Read on . Standards and vendor pages change; confirm the current text before you rely on it.
- RFC 9110, HTTP Semantics (503 Service Unavailable) (www.rfc-editor.org)