A Client's Site Is Down: What to Do in the First 15 Minutes

· 7 min read

Guides on "website down, what to do" are almost all written for people who have one site: their own. If you manage other people's sites, the problem changes shape. The technical part is the same — hosting, DNS, application — but there's a second part that nobody explains and that weighs more on the relationship with the client: what you tell them, when you tell them, and what happens if you don't tell them at all.

Below is a checklist for the first fifteen minutes, divided into blocks of time, written to be followed while the site is down.

The first problem isn't technical: it's the head start you lose

Before the diagnosis, there's an uncomfortable question: how many minutes pass, today, between the moment the site goes down and the moment you find out?

If the answer depends on someone at the agency opening that site by chance, or on the client noticing and writing in, the delay isn't measured in minutes — it's measured in hours, and on weekends it's systematically worse. Keep this in mind for the rest of the article: the fifteen minutes that matter aren't the first fifteen from when you know, they're the first fifteen from when it happened.

[0-2 min] Is it down for everyone or just for you?

The first step isn't working out why it's down. It's working out whether it's really down.

This phase exists for one reason only: to avoid alarming a client over a problem that only your office has. It's the most embarrassing mistake possible, and it happens more often than people admit.

[2-5 min] Isolate: hosting, DNS or application?

Three quick checks almost always narrow it down:

Does the domain resolve? If DNS resolution fails, the problem isn't the site: it's DNS or — worst case — an expired domain registration.

Does the server respond? If the domain resolves but the connection times out, the level is infrastructure: a server that's off, a firewall, a hosting outage. The host's status page is the first place to look, before even opening a ticket.

Does the site respond, but badly? 500 errors, a blank page, "error establishing a database connection": here the level is the application — a plugin update gone wrong, disk space exhausted, a connection limit reached.

One special case is recognisable at once: if the browser shows "your connection is not private," the site is not down, the SSL certificate has expired. Technically it's a minor incident, but in visitors' eyes it's the worst of all, because it speaks of security.

[5-10 min] The first mitigation step

You don't need the final fix. You need the fastest thing that reduces the damage while you work:

Put a time limit on this phase. If at ten minutes you have neither a cause nor a mitigation, take the next step anyway — this is where most agencies go wrong, because they keep working in silence hoping to fix it before they have to write.

[10-15 min] The message to the client

By the fifteenth minute the client must have received something from you. Not the solution: the news that you're already on it.

A message that works contains four things and nothing else:

Hi [name], [site name] has been unreachable since about [time]. We noticed at [time] and are already working on it: right now it looks like a [hosting / certificate / application] problem. I'll update you by [time + 60 minutes], even if it isn't fixed yet.

What's in it: since when, how you found out, what you're doing, when they'll hear from you again. What isn't: long apologies, technical jargon, and above all no promise of a resolution time. "I'll update you by 3:30 p.m." depends only on you and is easy to keep; "we'll fix it by 3:30 p.m." depends on a host you don't control.

And then the part almost everyone skips: the closing message. When it's resolved, write it, with the duration and a line on what happened. An incident communicated well and closed well can leave a client more reassured than before, because for once they've seen the work that is usually invisible.

The mistakes that cost more than the outage

Waiting until you have the solution before alerting. It's the natural instinct — nobody wants to write "I don't know yet why" — and it's the worst mistake: if in the meantime the client notices on their own, the conversation starts from "how long have you known?"

Alerting without a time estimate. "There's a problem, we're working on it" leaves the client waiting indefinitely, and people waiting indefinitely call back. An estimate, even just for the next update, closes the question.

Not closing the loop. If the last message the client received is "we're working on it," then in their memory the incident never ended — even if the site came back twenty minutes later.

The status page does the work that doesn't scale

With one client, manual communication works very well. With fifteen clients on the same host going down together, fifteen personalised messages are an hour of work right when you should be fixing things.

A public status page takes the repetitive part out of the way: anyone wondering "is it just me?" opens a page and sees the current status, the time of the last check and recent disruptions, without calling anyone. It doesn't replace the message — that remains your job, and it's the part the client remembers — but it eliminates the requests for confirmation, which during an incident are the majority. And outside incidents it does a second job: it's continuous proof that someone is watching, even in the months when nothing happens.

The cost of finding out from the client instead of from an alert

An hour of downtime discovered in two minutes and an hour of downtime discovered the next day aren't the same incident: in the second case the hour became a day. It's the calculation we worked through in full in the article on what an hour of e-commerce downtime costs — the summary is that, for a small store, the cost of a single hour is modest, whereas the cost of the hours in which nobody noticed anything is anything but.

Then there's the cost that doesn't appear in any spreadsheet: the position you speak from. A client alerted by you is facing an agency that's at work; a client who alerts you is facing a distracted agency, even if you fixed it in ten minutes.

How to compress minute zero

Of the checklist above, the [0-2 min] phase is the only one that can be fully automated — and it's also the one that, done by hand, requires the most unlikely condition of all: that someone is looking at that site at exactly the moment it goes down.

That's where Statuo comes in: sites are checked continuously from multiple independent locations, and an outage is declared only when at least two locations confirm it. When the alert arrives — by email or Telegram — the question "is it down for everyone or just for me?" already has an answer, and a single failed check from one point on the network never generates a false alarm to pass on to the client. Diagnosis and repair remain your work: what changes is that the fifteen minutes start immediately, not from when someone notices.

Along with the alert there's the status page with your agency's branding, already online, which clients check during the incident. The free trial lasts 14 days, no credit card required: long enough to activate it on the sites you look after and see where the first alert comes from.

What One Hour of E-commerce Downtime Costs (and How to Justify It to the Client)

A formula to estimate what an hour of downtime costs a small online store, with a full worked example, and how to use it with a client without selling fear.

Status Pages: Why Every Client of Your Agency Should Have One

What a status page is, why even a brochure site needs one and not just big services, and what changes when every client has one on their own domain.