Website down: the checklist for when it happens.
Updated July 11, 2026 · 7 min read
When your own website is unreachable, order beats haste. This checklist walks you from the first alert to the follow-up, so you forget nothing in exactly the situation where things get forgotten.
Contents
Step 1: verify instead of guessing
First make sure it is a real outage and not a local problem: open the site from a second network (a phone off Wi-Fi is enough) and check your monitoring. A good monitor tells you not just "down" but HOW down: timeout, DNS error, certificate error or a concrete status code. That failure type is the signpost for everything that follows.
Step 2: the quick checks, in this order
- Open your host or cloud provider status page: if it is a known incident, you save yourself the debugging.
- Think back to the last change: deployment, config change, plugin update, DNS migration in the last hours? The most common culprit is the most recent change.
- Check DNS (dig/nslookup on your domain): does the A/AAAA record still point to the right server? Has the domain expired?
- Check the certificate: the browser error or your monitoring tells you directly. Expired certificate means: inspect the renewal job.
- Server reachable? SSH in: is the web/app process running, is the disk full (df -h), is memory exhausted?
- Read the logs: web server error log and application log of the last minutes. Do not guess, look.
Failure pattern and most likely cause
| Failure pattern | Most likely direction |
|---|---|
| DNS error | Domain/nameserver: record changed, domain expired, incomplete migration |
| Certificate error | Renewal failed (certbot etc.), wrong certificate after a migration |
| Timeout / no response | Server down or overloaded, firewall, hanging process |
| 502 / 504 | Reverse proxy cannot reach the app: process dead, deployment gap |
| 500 | Application error: last deployment, config, database |
| 503 | Maintenance mode active (intended?) or overload protection kicking in |
| 200 but page wrong/empty | Soft failure: CMS/database returns nothing, CDN cache, half-finished deployment |
Step 3: communicate before people ask
As soon as you know THAT there is an outage (not once you know the cause): update the status page. An honest "we are seeing an incident and are on it" early beats a perfect explanation an hour later.
Be careful with time promises: an ETA you miss is worse than none. Better: short regular updates ("next update in 30 minutes"), even if nothing changed.
Step 4: the follow-up, the actually valuable part
After the all-clear: document the cause in two or three sentences (what, why, how fixed), record the outage window, and answer the one question that matters: which change makes sure this exact thing does not happen again, or gets noticed faster?
For client projects, an exportable record of the window is worth a lot. With Clesk Uptime, check logs are cryptographically signed, so you can later prove when checks ran and what they found.
Frequently asked questions
How fast should I communicate?
Rule of thumb: within a few minutes of confirming the outage yourself, and definitely before the first customers call. Updating the status page with two sentences takes 60 seconds.
What do I tell clients if I do not know the cause yet?
Exactly that: incident confirmed, team on it, next update at time X. Customers forgive outages far more easily than silence.
How do I practice for the real thing?
Walk the checklist once as a dry run: do you have SSH access at hand, do you know your host status page, can everyone on the team update the status page? Better to find the gaps now than at 2 a.m.
The first step happens before the outage.
Set up monitoring in two minutes, including a status page for incident communication.
Monitor for free