Website down: what to do in the first 15 minutes

The message arrives at an inconvenient time: “the site is down”. You have a few minutes before the question changes from “what happened” to “why did nobody notice”. This is the order we work in. It is written for people who look after several sites and cannot afford to improvise.

The whole routine fits in fifteen minutes if you resist the urge to fix things before you know which layer is broken.

Minutes 0 to 2: confirm it

Before you touch anything, make sure the site is down for other people and not only for the person who reported it.

1. Open it on your phone with Wi-Fi off. If it loads, the problem is the reporter’s network, a stale DNS cache or a browser extension.
2. Use a checker that is not on your network. The free is-it-down tool requests the URL from our checker and shows the status code and the response time, which tells you more than “it does not load”.
3. From a terminal, get the status code and timing:

curl -sS -o /dev/null -w '%{http_code}  total %{time_total}s  connect %{time_connect}s\n' https://example.com

A 000 means the connection never completed (DNS, firewall or the server is off). A number means the server answered, and the number tells you where to look; the HTTP status codes reference explains each one in plain language.

Ask one more question before you move on: what changed in the last hour? A deployment, a plugin or theme update, a DNS edit, a firewall or Cloudflare rule, a server reboot, a renewed or expired certificate. Most outages follow a change, and undoing the change is usually the fastest fix.

Minutes 2 to 6: find the broken layer

Work from the outside in. Each command rules out one layer.

DNS. Does the name resolve, and to the address you expect?

dig +short example.com
dig +short NS example.com

No answer, or an address you do not recognise, means DNS or an expired domain. A quick check of the registration date is worth ten minutes of guessing: use the domain expiry tool.

TLS. Is the certificate valid right now?

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

A notAfter in the past is an expired certificate. The SSL checker shows the same thing with the chain, and the post on what to do when the certificate has expired covers the recovery.

HTTP. What does the server say? Use the table below.

Server. If you can log in, three commands cover most causes:

df -h            # full disk is a classic
free -m          # out of memory, swapping
systemctl status nginx php8.3-fpm   # or apache2, your app service
tail -n 100 /var/log/nginx/error.log

Application. A white page or a 500 right after a deployment points to the code. For WordPress, rename the plugins directory over SFTP to rule plugins out in one move; the WordPress monitoring guide lists the usual suspects.

Minutes 6 to 12: fix the cause, smallest change first

Pick the cheapest action that undoes the most likely cause, and do one thing at a time so you know what worked.

• A deployment: roll back to the previous release before you try to debug forward.
• A plugin or theme update: disable the last updated plugin.
• A full disk: clear old logs and backups, then find the thing that fills it.
• A crashed process: restart it, then read why it crashed. A restart without a log read is an outage that repeats at 3 a.m.
• An expired certificate or domain: renew first, argue about whose job it was later.
• A DNS change: restore the old record; propagation takes as long as the TTL says.
• Traffic spike: if the server is simply overloaded, turn on a cache or put the site behind a CDN, and scale after the incident.

If nothing works in twelve minutes, stop and escalate to the host or the person who made the last change. Fifteen minutes of solo debugging is worth it; the sixteenth is usually a conversation you should already be having.

Minutes 12 to 15: tell the client and write it down

Send this before you have the final cause:

We know the site is unavailable since 14:07. We are working on it and will update you by 14:45. No action needed on your side.

Update the message when you have a cause, and again when it is fixed: what happened, how long it lasted, what you changed. If the client has a status page, update it so they stop asking.

Then write four lines for yourself: start time, detection time, fix time, cause. They become the incident entry in the monthly report, and the gap between “started” and “detected” is the number that decides whether you need better monitoring.

Make sure you hear first next time

An outage you learn about from the client is a monitoring gap. The minimum setup:

1. An HTTP check on the home page every minute, with a keyword check for a phrase that only appears when the page renders properly.
2. A check on the page that earns money (checkout, booking, contact form).
3. SSL and domain expiry checks, which alert before the date rather than after it.
4. An alert channel you read at night. Email works on every plan. Telegram, with a one-tap acknowledge button, needs a paid plan.
5. A second check before an alert is sent, so one dropped packet does not wake you.

On Tenium, 30 monitors with 5 min checks are free; Starter ($7) checks every 1 min and adds Telegram, SSL and domain expiry checks. The website monitoring page describes the checks, and the Tenium vs UptimeRobot comparison shows how the plans line up if you already use another tool.

A short checklist to keep

• Confirm from a second network and a checker
• Ask what changed in the last hour
• curl status and timing; dig the name
• Certificate and domain dates
• Disk, memory, process, error log
• Undo the last change
• Message the client within 15 minutes
• Write down start, detection, fix, cause

Frequently asked questions

Related

Related Tenium pages

• Website monitoring
• Free is-it-down tool
• Tenium vs UptimeRobot
• All blog posts
• Pricing