Minute 0 to 2: confirm and assess
- Look at the alert’s evidence. What did each location see: timeout, DNS error, certificate error, status code? A pattern already points to a layer.
- Is it one region or both? If only one region sees a failure, the site may be fine for most visitors (see Two-region confirmation). Keep watching, but you have time.
- Load the site yourself from a different network, such as a phone on mobile data, not your office. Note exactly what you see.
- Check what changed. A deploy, a plugin update, a DNS edit, a certificate renewal, a hosting move in the last hour is the most likely cause. A timeline of changes saves minutes here.
- Tell someone you are on it. Post in your incident channel so two people do not duplicate the work.
Minute 2 to 8: walk down the stack
Work in this order. Each layer has a quick test and a likely fix.
1. Is the name resolving? (DNS)
Test: dig +short example.com A and the same against the authoritative nameserver. A DNS answer comes back with a TTL in seconds (RFC 1035).
- No answer or a different address than expected: a record changed, deleted or the zone disappeared. Compare to your exported copy. See DNS changes that break client sites.
- Answer is right at the authoritative server but wrong elsewhere: propagation; the old TTL is still running.
- Domain not found at all: check whether the domain has expired (see Domain expiry and RDAP).
2. Can you connect, and is the certificate valid? (TLS)
Test: curl -vI https://example.com and read the certificate lines.
- “certificate has expired” or a name mismatch: see SSL certificate expiry.
- Connection refused or timed out: the server or firewall is not accepting connections; go to the next layer.
3. What does the server say? (HTTP)
Test: curl -sI https://example.com/ and read the status code. RFC 9110 groups them: 5xx means the server failed to fulfil a valid request.
| What you see | Likely layer | First move |
|---|---|---|
| Timeout, no response | Server down, firewall, overloaded host | Check the hosting panel and provider status; check whether the server is up |
| 500 | Application error | Read the application and web server error logs; look at the last deploy |
| 502 or 504 | Proxy or load balancer cannot reach the app | Check the app process and upstream health |
| 503 | Overloaded or in maintenance | Check for a maintenance mode left on; check load |
| 403 | Blocked by a firewall or permission change | Check the web application firewall, IP blocks and file permissions |
| 404 on the home page | Wrong document root, deleted files, bad rewrite rules | Check the web server configuration and deployment |
| 200 with a wrong page | Parked page, default host page, error page with 200 | See What a 200 response hides |
| Redirect loop | Conflicting redirect rules | Check redirect and HTTPS settings; see Redirect chains |
4. Is it the CDN or the origin?
If a CDN sits in front, test the origin directly (using its address and the Host header, or the hosting provider’s temporary URL). If the origin works and the CDN does not, check the CDN’s status page, its cache and its origin settings. If the origin is down and the CDN serves cached pages, visitors may see an old site for a while: “up” is not the same as healthy.
5. The application and its dependencies
If the server is fine and the app errors: database connection, disk full, out of memory, expired credentials, a failing third-party API, a plugin conflict. The logs name it in most cases. Do not fix by guessing; read.
Minute 8 to 12: restore service
Choose the safest move, not the cleverest.
- Roll back the last change if the problem started at a deploy or an update. A rollback you can verify is better than a fix you cannot.
- Restore the missing record or file from your copy of the zone or the backup.
- Restart the failed service only after reading why it failed; a restart can hide the cause and lose the evidence.
- Switch to a maintenance page that returns 503 if the fix will take long, so visitors and search engines know the condition is temporary.
- Escalate to the hosting provider with the facts you have: times, errors, what you tried.
Verify from outside after each move, not from your own browser, which may be cached.
Minute 12 to 15: communicate
- Send the client the first message with what visitors see, what you know, what you are doing and when the next update comes (see Incident communication to clients).
- Update the status page, if the client has one.
- Write in the incident log: time of the alert, time of confirmation, what you checked, what you changed.
Afterwards
- Confirm recovery from several locations and over a few minutes, not once.
- Find the cause, not only the trigger. A full disk was filled by something.
- Write down what prevents a repeat and who does it by when.
- Put it in the monthly report.
- Keep a short runbook per client with the host, the DNS provider, the contacts and the usual first moves. The fifteenth minute is easier when it is written.
Common wrong turns
- Fixing before looking. Restarting, clearing caches or changing settings before you know the layer.
- Testing from the same network that cached the problem.
- Assuming the last change is guilty without checking that the failure started after it.
- Not telling the client until the fix is done.
- Not leaving a record. The next incident will thank you.
How Beamfar helps
Beamfar’s alert shows what each region saw, and the incident page it links to holds the status code, timings and DNS answer; the site’s what-changed timeline shows a DNS, certificate, redirect or SEO change in the hour before the incident. That answers steps 1 to 4 of this checklist before you open a terminal. It does not read server logs, restart services or roll anything back.
Questions
What should I check first when a client’s site goes down?
What the alert’s evidence says about each location, whether it is one region or both, and what changed in the last hour. Then walk down the layers: DNS, certificate, server response, CDN, application.
How do I tell a DNS problem from a server problem?
Query the domain’s A record at the authoritative nameserver and at a public resolver. If the address is missing or wrong, it is DNS. If it is right and connecting fails, move to the TLS and HTTP layers.
Should I restart the server straight away?
Not before reading the logs. A restart can restore service and destroy the evidence of the cause. Roll back the last change if there was one, and restart deliberately.
What does a 503 response mean?
Service Unavailable: the server cannot handle the request now, often from overload or maintenance. Intentional maintenance pages should use 503 so visitors and crawlers know the condition is temporary.
Sources
Read on . Standards and vendor pages change; confirm the current text before you rely on it.
- RFC 9110, HTTP Semantics (status codes) (www.rfc-editor.org)
- RFC 1035, Domain names: implementation and specification (www.rfc-editor.org)