The worst way for an agency to learn that a client’s site is down is from the client. The second worst is to know, stay quiet while you fix it, and then explain afterwards. Both leave the client feeling that they were the last to find out about their own business.
Outages are not always avoidable. Hosts have bad days, plugins ship broken updates, DNS changes go wrong, certificates expire. What clients remember is how the hour felt: whether someone told them early, whether the updates made sense, and whether the explanation afterwards was honest. This post gives you a sequence for those messages, with wording you can adapt, so nobody has to improvise while the site is still down.
First, agree what “down” means
Clients and developers use the word differently. To a developer, a site with a broken contact form is “up”. To a client whose leads come entirely through that form, it is down. Before you write a single message, sort the problem into one of these:
- Fully unavailable. The site does not load, shows a server error, a database connection error, a critical error message, or a browser security warning.
- Partly broken in a way that costs money. Checkout fails, bookings do not go through, forms submit but nothing arrives, logins fail for members.
- Degraded. Very slow, layout broken on mobile, images missing, but people can still do what they came to do.
The first two get the full sequence below. The third usually deserves a heads-up but not an incident. If your agency has a triage policy, this sorting should match it.
The sequence: four messages, not one
Think of outage communication as a short series rather than a single email. Each message has a job.
Message one: we know, and we are on it
Send this as soon as you have confirmed the problem is real, before you know the cause. Its only purpose is to make sure the client hears it from you. It should be short, plain and free of speculation.
Hi Priya, a quick heads-up: your website is not loading at the moment. We spotted it and are already working on it. You do not need to do anything right now. We will send you another update soon, even if it is only to say we are still on it.
Notice what is missing: a guess at the cause, a promised fix time, and any technical terms. You can add those later when they are true. Also notice the promise of another update. That is the one commitment worth making early, and you must keep it.
Message two: what we know so far
Once you have a likely cause, tell the client in a sentence or two. If you know the next step and roughly what it involves, say that too. If you do not know how long it will take, say so rather than inventing a figure.
Update: the problem is with the hosting server your site runs on, not with the site itself. The host has confirmed they are working on it. We are watching it and will check everything on your site as soon as the server is back. Next update when it is back, or sooner if anything changes.
Or, if the cause is on your side:
Update: an automatic plugin update this morning is causing the error. We are rolling that plugin back to the previous version now, which should bring the site back. We will confirm when it is working and then look at why the update failed.
Owning a mistake early, in plain words, costs far less trust than having the client discover it later.
Message three: it is back
When the site is working, say so, and say what you checked. Then tell the client what to do if they notice anything odd.
Good news: your site is back up. We have checked the homepage, the contact form and the booking page, and all are working. If you or your customers notice anything that looks wrong, reply here and we will look at it straight away. We will send a short note later explaining what happened.
Message four: what happened and what changes
This is the message most agencies skip, and it is the one that turns a bad morning into a reason to trust you. Send it once you have had time to understand the cause properly, while the client still remembers the outage.
Keep it to a few short paragraphs:
- What happened, in one or two plain sentences.
- How long the site was affected, from when to when, as far as you can tell.
- What you did to fix it.
- What you are changing so it is less likely to happen again, or, honestly, why it could happen again and what you will do if it does.
- Anything you need from the client, such as a decision about upgrading hosting.
If turning the technical cause into plain language is the hard part, our guide to explaining technical problems in client-friendly terms has examples for the common ones.
How often to update during an outage
There is no perfect interval. What matters is that the client knows when to expect the next message and that you send it, even if nothing has changed. An update that says “still working on it, nothing new yet” is better than silence, because silence gets filled with worry.
Agree the interval in your support terms or care plan, and match it to the severity of the problem. A site that takes payments may warrant more frequent check-ins than a brochure site. Whatever you choose, do not promise an interval you cannot keep when your team is asleep or busy with another fire.
Choosing the channel
Use the channel the client actually watches. For some that is email, for others a shared Slack channel or WhatsApp. During an outage, a quick message on the channel they read is better than a polished email that sits unopened.
- Agree the outage channel in advance, and note it on the client’s record.
- Send the first message where the client will see it fastest.
- Send the final “what happened” note by email as well, so there is a written record they can forward to their boss or keep on file.
- If the client’s business email runs on the same hosting account as the site, assume email may be down too, and use another channel.
Things not to say
- “It is just the host.” Even if it is true, it sounds like deflection. Say what the host is doing and what you are doing.
- “It should be back in five minutes.” Unless you are certain, do not put a number on it. A missed estimate becomes the story.
- “Nothing was lost.” Only say this after you have checked, especially on a store or a site with forms.
- “This never happens.” The client has just watched it happen.
- Error codes and jargon. “A 503 from the upstream” means nothing to most clients. “The server is overloaded and refusing visitors” does.
- Blame on the client’s team. If someone on their side caused it, explain the cause neutrally in the follow-up and suggest a safeguard. Do not do it mid-outage.
When you are the one who notices last
Sometimes the client spots the outage first. Do not pretend otherwise. Thank them, confirm what you see, and move straight into the sequence:
Thanks for flagging this. You are right, the site is down, and we are looking at it now. We will update you shortly.
Then fix the reason you did not know. Usually that means monitoring was missing, or alerts were going to an inbox nobody reads. Our explainer on what uptime monitoring should watch covers what to set up so you hear about problems first.
When an outside team is doing the fixing
If your agency uses a partner for support or development, the partner may be the first to see the problem and the one fixing it. The client still expects to hear from you. That needs a small amount of planning:
- Agree how the partner alerts you. A specific channel, with enough detail for you to write message one immediately: which site, what is broken, what they are doing.
- Agree who writes to the client. Usually you. Ask the partner for updates in plain language you can pass on with light editing.
- Plan for the hours your team is offline. If a partner works while you sleep, decide in advance whether they may send a short holding message on your behalf, or whether the client simply waits for your morning. Both are acceptable; the client should know which.
- Get a written summary afterwards. The partner’s notes on cause and fix become the basis for your message four.
If the fix itself needs more hands than you have, our page on getting a down WordPress site back online explains what that emergency work involves. For the bigger picture of how support fits with outsourced builds and maintenance, see our overview of WordPress outsourcing for agencies.
Prepare the messages before you need them
An outage is a bad time to write from scratch. Store the four messages as templates in whatever tool your team uses for client communication. Keep them short and leave clear blanks for the site name, the problem and the next step. With them ready, anyone on the team can send the first message within moments of confirming a problem, and the client hears a calm, consistent voice regardless of who is on duty.
Alongside the templates, keep a small outage card for each client site:
- The client contact for outages and their preferred channel.
- Hosting provider, how to reach their support, and who holds the login.
- Where the latest backup is and how to restore it.
- Any business hours or events when an outage would hurt most, such as a sale or a booking rush.
After the outage: the short review
Once the follow-up is sent, spend a few quiet minutes as a team on three questions. How did we find out? How long did it take to send the first message? What one change would make the next outage shorter or less likely? Write the answers in the client’s record. Over time, those notes are what make your outages rarer and your messages better.
If you would like outage tickets like these picked up by a team that writes the updates for you to send, our outsourced help desk for agency client sites may suit, and the client conversation stays yours.
Next in this series: What Is an SLA? A Plain Guide for Web Agencies
