A website that went down for a morning: handling it

2 days ago
3 min read

Introduction

A client rings at nine to say their site is showing an error. It comes back at half past eleven. Nothing is permanently broken and, on most sites, the commercial loss is modest. But the client spent two and a half hours unable to answer the question of what was happening, and that is the part they will remember.

Outages are not really a technical event from the client's perspective. They are a period of uncertainty during which somebody is asking them questions they cannot answer, and the agency's job is to remove that uncertainty. Everything else is secondary.

1. A website that went down for a morning is judged on communication

The technical recovery matters less than the client thinks it does. Presence is what they buy.

Acknowledge within minutes

Even before you know the cause. "We are on it, I will update you within thirty minutes" transforms the client's morning. Send it immediately.

Update on a rhythm, whether or not there is news

Every half hour, briefly. Silence during an outage is what makes clients ring hosting companies and consider other agencies. Set a timer.

2. Find the cause properly, not just the fix

A restart that works is not a diagnosis. It will happen again.

Establish what actually happened

Host incident, a plugin or dependency update, an expired certificate, a traffic spike, a deployment, a DNS change, exhausted resources. Each has a different prevention. Check the logs properly.

Check whether it was foreseeable

An expired domain or certificate is a diary failure. Saying so honestly is uncomfortable and it is what separates a professional from a supplier. Own the diary failure.

3. Report afterwards in writing

Clients need something to show their own people. They are being asked internally.

Send a short incident summary

What happened, when it started, when it was resolved, root cause, and what will prevent it. One page, plain language, within a day. No jargon at all.

Quantify the impact honestly

Downtime duration, affected pages, lost form submissions if you can tell. Estimate rather than omit. Understating it is worse than the outage. Give the actual minutes.

4. Fix the underlying exposure

An outage without a change is a preview. Change something concrete.

Add monitoring if there was none

Uptime monitoring that alerts you before the client notices is inexpensive and it changes the relationship entirely. Learning about an outage from your client is the real failure. Set it up this week.

Address the specific weakness

Certificate auto-renewal, backups tested rather than assumed, staging before deployment, resource headroom. All four are cheap. Pick the ones that applied. Then tell the client.

5. Be honest about hosting and responsibility

Ambiguity here damages trust badly. Clarify it in writing.

Say plainly whose responsibility what is

If the client hosts elsewhere and declined a care plan, that context is relevant — but lead with resolving it, not with the contract.

Do not blame the host and stop there

Even when it is true. Clients hear it as deflection. Say what happened and then say what you will do to reduce the impact next time. Own your part.

Conclusion

An outage is a period of uncertainty rather than a technical event, so acknowledge within minutes even before you know the cause, and then update every half hour whether or not there is news — silence is what makes clients ring hosting companies and look at other agencies.

Find the actual cause rather than accepting a restart that worked, and be honest where it was foreseeable, because an expired certificate is a diary failure. Send a one-page incident summary within a day with honest impact figures. Then change something: add uptime monitoring so you learn about outages before the client does, and address the specific weakness that caused this one.