What to do when your website goes down: monitoring and response

The customer notifies first

A customer writes on WhatsApp: “the page won't open for me.” Someone tests it on their phone, another on a computer, someone calls the provider, another looks for the hosting password. Half an hour later nobody knows yet whether it's the domain, the server or an update. An outage cannot always be prevented, but the disorder can.

Detect before the customer

A basic monitoring checks every few minutes that your site responds and alerts if it doesn't. Google's SRE book recommends that alerts be based on symptoms that affect the user, such as the site not responding or responding with errors, and not on any internal metric. Define who receives the alert and by which channel.

Five steps

1. Detect: an alert or a customer report arrives. Note the time.
2. Verify: check from another connection and another device. Note what is seen: blank page, certificate error, HTTP error code like 500 or 503, or the domain not resolving.
3. Communicate: notify internally that there is an incident and who is coordinating it. If it affects customers, prepare a brief and honest message.
4. Escalate: contact the technical responsible or provider according to your contract, with what was verified. If they do not respond within the agreed time, follow the escalation list.
5. Close: when service is restored, verify it works, note the time and schedule the post-incident review.

Roles

In a small company, one person can cover two roles. The important thing is that this is clear before the incident, as incident management in the SRE book recommends.

What to tell customers

Do not promise a resolution time you do not control.

Post-incident review

After the incident, write what happened, when it was detected, what was done and what can be improved. The blameless postmortem culture seeks to learn, not to point at a person.

Monitoring and contracts

The response and resolution times you can demand are those stated in your contract. At RealStack, Continuity operates with an availability objective of 99.0% for Web, App and System. It is an objective, not a universal SLA, and does not cover customer-owned infrastructure; the specific coverage is that of the active plan. No service can guarantee that a site will never go down.

Applied example

How to use the downloadable checklist

1. Fill in the preparation before any incident.
2. During the incident, tick each step with its time.
3. When closing, complete the post-incident review.

Severity criteria

Full synthetic example

Synthetic example. On a Tuesday at 10:05, a company's monitoring alerts that its store is not responding. The person on duty confirms from another network at 10:08 and opens the incident log.

At 10:12 the technical lead identifies that the certificate expired: the automatic renewal had failed without notice. At 10:15 the communications person posts a brief message on social media and WhatsApp: the store is experiencing an issue, it is being addressed and orders can be placed by phone. At 10:40 the certificate is renewed and the store responds. At 10:50 it is confirmed that payments work and a notification is posted that service has been restored.

In the post-incident review, the team agrees to configure a certificate expiration alert 30 days in advance to a shared email. Fictitious example.

Common mistakes, explained

Waiting to have the cause before notifying customers generates more calls and distrust. A brief, honest notice without promised times is better than silence. And closing an incident without a post-incident review guarantees it will repeat: the review does not seek culprits, it seeks the action that prevents the next outage.

How to know if it worked

• Monitoring alerts before customers.
• Each role knows what to do.
• Each incident has a post-incident review.

Plan for the first four weeks

1. Week 1: enable external monitoring.
2. Week 2: assign roles and escalation.
3. Week 3: prepare customer messages.
4. Week 4: simulate an incident.

Diagnosis before starting

• Ask who would know today if the website goes down and how.
• Check if you have the provider's support contact.
• Look for a prepared message for customers.

A second example, in contrast

Synthetic example. A fictional company detects an outage at midnight; because its store sells little at night, it decides not to activate the full procedure and to handle it first thing in the morning. It was a valid decision because it had written severity criteria. Unlike the first example, not every incident required immediate response. Fictitious example.

What to do when something fails

• If you cannot restore service, communicate progress at regular intervals without promising times.
• If the cause is the provider's, escalate and document.
• If it repeats, prioritize the action from the post-incident review.

How to measure it with your own data

• Log the start, detection, notification and restoration times of each incident.
• Note who detected it first: monitoring, the team or a customer.
• Count how many post-incident actions were completed.
• Compare detection times across incidents.

With those records you can calculate your own detection and restoration times without relying on external figures. If monitoring detects before customers and times decrease with each review, the procedure works. If the same type of incident repeats, the agreed action in the review was not completed or did not address the cause.

Common mistakes

• Finding out from customers.
• Not noting times or what was verified.
• Multiple people calling the provider at once.
• Promising resolution times.
• Not doing the post-incident review.

Checklist

• Active monitoring.
• Roles assigned.
• Escalation documented.
• Customer message ready.
• Post-incident review done.