Detecting website outages and informing clients the right way

For an agency, an outage is rarely just a technical problem. Whether the client ends up annoyed or feels well looked after depends mainly on who knew first and how it was communicated. This guide describes a lean process that also works for small teams.

1. Detect: from a signal to a confirmed incident

A single failed request is not an outage yet. Networks have brief hiccups, servers restart after updates, timeouts happen. If you forward every single error, you train your team to ignore alerts.

Three rules have proven themselves:

• Confirm instead of alerting immediately. Only when a second check shortly afterwards also fails does the page count as down.
• Filter out your own problems. If the check server itself has no internet connection, every website appears to be offline. Good monitoring recognises that and does not alert.
• One message per incident. One email when it starts and one when it’s over. No repeats every five minutes.

D3bris works exactly like this: after a failed check, a second one follows one minute later. Only then is the outage email with the cause sent, and later a recovery email with the incident’s duration. If our own connection fails, no alert is triggered.

2. Triage: the first ten minutes

When a confirmed alert arrives, a few fixed questions help:

1. Is it really broken? Open the page in a browser, ideally also over mobile data.
2. What does the cause say? The alert usually points in the right direction:
   • Domain not found → DNS, domain renewal, recent changes at the registrar.
   • No response / connection refused → server or hosting.
   • HTTP status 500 → application error, often after an update.
   • HTTP status 503 → maintenance mode or an overloaded server.
   • Certificate invalid or expired → TLS renewal, see TLS monitoring.
   • Expected text missing → content or template changed, plugin deactivated.
3. What changed recently? Updates, deployments, DNS changes, work by the client.
4. Is it us or a third party? Host, domain registrar, external booking service.

3. Escalate: who does what?

Even in small teams it should be settled in advance:

• Who looks first? One person or a shared inbox that is reliably read during business hours.
• When is it handed on? For example: if the cause is unclear after 30 minutes, the technical lead takes over.
• What applies outside business hours? Agree honestly on what the maintenance contract covers. Many agencies only respond on weekdays – that’s fine as long as the client knows.

4. Inform: when and how the client hears about it

Principle: early and short beats late and detailed. A client who hears from you that you are already working on it is in a completely different position from one who has to call you.

A good client update contains:

• what is affected (which page, which function),
• since when,
• what you already know – without speculation,
• what happens next and when you’ll be in touch again.

Template: first update

Subject: Issue on www.client.com – we’re on it

Dear Ms Example,

since 9:40 this morning the contact form on your website has been unavailable. All other pages are working. Our monitoring picked up the problem and we are investigating the cause.

We’ll update you by 11:00 at the latest.

Kind regards

Template: resolved

Subject: Resolved: issue on www.client.com

Dear Ms Example,

the contact form has been working again since 10:25. The cause was a faulty update of the form plugin, which we have rolled back. Unfortunately, enquiries attempted during this time did not arrive.

To prevent this in future, we will test updates of this plugin on a staging site first.

Kind regards

The last paragraph matters: it shows that you learn from the incident.

5. Follow up

After each incident, write down two or three sentences: what happened, how long did it last, what will we change? After a few months you’ll see patterns – a particular host, a particular plugin, a website that keeps causing trouble. That is also a good basis for talking to clients about maintenance contracts or switching hosts.

D3bris keeps an incident history for each website with start, end and cause; details of individual checks are kept for 30 days.

What to agree in advance is summarised in the checklist for agencies.