Client Site Down? A 10-Minute Freelancer Triage Checklist

The message always arrives the same way. “Hey, is the site down? A customer just called me.” No details, no timestamp, no idea what “down” even means yet. Your heart rate goes up, you open fifteen tabs, and if you’re not careful you spend the first ten minutes flailing instead of diagnosing.

This is the order to work in. It’s fix-first: confirm the problem, narrow down where it lives, then act — instead of guessing and re-checking the same thing three times under pressure.

Step 1: Confirm it’s actually down — for everyone, not just them

Before you touch DNS records or SSH into a server, rule out the boring explanations. A shocking number of “the site is down” messages are actually the client’s wifi, a stale browser cache, or a corporate firewall blocking the domain.

• Load the site yourself, on a network the client isn’t on (phone data works if you’re on the same wifi as your desk).
• Ask the client to try a different device or network if you can’t reproduce it — a lot of “down” reports turn out to be one laptop with a bad DNS cache.
• Use a checker that hits the site from outside both your networks. Something like downforeveryoneorjustme tells you whether the outage is global or local to the client, but it won’t tell you why.
• Run curl -I https://example.com from your terminal to see the raw HTTP response — status code, headers, redirect chains — without a browser getting in the way and silently “helpfully” retrying or caching something.

This is genuinely the point where a proper uptime and health check pays for itself, because it answers “is it actually down, and since when” in one shot instead of you reconstructing a timeline from a panicked client message. If you want a fast, no-login way to check this, SitesRadar’s free checker will tell you in about ten seconds whether the site is reachable, whether SSL is valid, and whether DNS is resolving — which conveniently sets you up for step 2.

If the site loads fine for you and from an external checker, the “outage” is local to the client (their network, their cache, their browser extension blocking something) and you can close the loop in two minutes instead of two hours. Say so, kindly, and move on with your day.

If it’s genuinely unreachable, keep going.

Step 2: Bisect the failure by layer

Don’t just start poking randomly. Work down the stack in this order — DNS, then TLS, then hosting, then application, then CDN/WAF — because each layer’s failure mode looks different, and checking them out of order wastes time re-diagnosing symptoms that were actually caused by a layer below.

DNS: does the domain even resolve?

dig example.com
nslookup example.com

You’re looking for:

• No answer at all, or NXDOMAIN. The domain may have expired. This happens more often than anyone wants to admit — a client’s card on file expired, or a renewal email went to a spam folder for eleven months. Check the registrar directly; don’t assume auto-renew worked.
• An A record pointing somewhere unexpected. Someone changed nameservers or DNS records recently — a new hosting migration, a marketing tool that “helpfully” asked for a CNAME, a developer testing something in production. dig shows you the current answer; compare it against what it should be.
• Slow or inconsistent resolution. Different resolvers giving different answers usually means a recent DNS change that hasn’t fully propagated, or a misconfigured TTL that’s making the rollout messier than it needs to be.

If DNS resolves correctly and points at the right IP, move on.

TLS/SSL: is the certificate the problem?

An expired certificate is one of the most common causes of “the site is down” reports, because browsers show a big scary warning page instead of the site — which reads as “down” to anyone non-technical, even though the server is perfectly healthy underneath.

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

If notAfter is in the past, that’s your answer. Certificate expiry is common enough, and annoying enough to diagnose blind, that it’s worth reading in full if you haven’t dealt with it before — see why SSL certificates expire without warning for the renewal-automation failure modes that cause this and how to stop it recurring. For the ongoing prevention process, use SSL certificate expiration monitoring.

Hosting/server: is the box itself okay?

If DNS and TLS check out, move to the server layer.

• Check the host’s status page first — shared hosting providers, VPS platforms, and PaaS services (Railway, Render, Vercel, etc.) all publish incident pages, and a five-second check here can save you an hour of debugging a problem that isn’t yours to fix.
• SSH in if you can. Check disk space (df -h) — a full disk is a classic silent killer, especially on servers that log aggressively or auto-backup without cleanup. Check memory and load (free -h, top or htop) for resource exhaustion, particularly after a traffic spike or a cron job gone wrong.
• Check whether the web server process is actually running — systemctl status nginx / systemctl status apache2, or the equivalent for whatever’s serving the site. A crashed or OOM-killed process is common enough to check early rather than assuming.
• Resource limits on managed/shared hosting — some hosts silently throttle or suspend sites that exceed a plan’s CPU or bandwidth quota, often with no obvious error page, just a generic “resource limit reached” message.

Application layer: did something just change?

If the server is up and serving requests but the site itself is broken (500 errors, blank pages, a WordPress “critical error” notice), the cause is almost always something that changed recently.

• Check for a recent deploy. Git log, deployment platform history, or just “did anyone push anything today” in the team chat.
• Check for a recent plugin, theme, or dependency update — WordPress auto-updates are a frequent culprit, especially plugin updates that ship without adequate testing against the site’s specific combination of other plugins.
• Read the actual error logs — PHP error log, application log, whatever’s relevant to the stack — instead of guessing from the symptom. The error message almost always names the offending file or plugin directly.
• If this follows a migration, especially to new hosting or a new server, check for broken links after a WordPress migration — partial breakage after a move (some pages fine, others 404 or erroring) is a distinct pattern from a clean full outage and points at incomplete URL rewrites or missed database references rather than a server problem.

CDN/WAF: is something in front of the origin blocking traffic?

If the site works when you hit the origin server directly but not through the public domain, or the outage seems specific to certain regions or requests, the culprit may be sitting in front of the actual server.

• Check the CDN or WAF provider’s status page and dashboard (Cloudflare, Fastly, whatever’s in use) for active incidents or triggered security rules.
• A WAF rule change or an aggressive rate limit can start blocking legitimate traffic after a “security tightening” someone did without testing it against real usage.
• Cache misconfiguration can also serve stale error pages long after the underlying issue is fixed — worth a hard cache purge as a cheap thing to rule out.

By this point you should know which layer failed. That’s the actual diagnosis; everything after this is execution and communication.

Step 3: What to tell the client while you’re working

Clients don’t need a technical debrief mid-triage. They need to know you’re aware, you’re on it, and roughly when to expect an update. Silence during an outage is what turns a technical problem into a trust problem.

A message like this covers it:

Hi [name] — thanks for the heads-up, I’m on it. I’ve confirmed the site is down and I’m working through the cause now. I’ll update you within [30/60] minutes whether that’s a fix or just a status update. No action needed on your end right now.

Keep it honest. If you don’t know the cause yet, say “still diagnosing,” not a guess dressed up as an answer. If it turns out to be an expired domain or a missed certificate renewal, say that plainly once you know — clients generally handle “here’s what happened and here’s the fix” far better than a vague explanation that reads as evasive later.

Step 4: After it’s back — post-mortem and monitoring

Once the site is live again, resist the urge to close the tab and move on. Two things are worth ten minutes each.

Write down what actually happened, while it’s fresh: what broke, when, why, and what fixed it. Even three sentences in a notes doc is enough — you or a future contractor will need this exact information again someday, usually at 11pm, and “I think it was something with the cert” six months later is a lot less useful than a dated note.

Check whether you’d have caught this before the client did. If the honest answer is “no, they told me first,” that’s the real problem to fix — not the individual outage. A domain expiry, a cert renewal failure, DNS drift, and slow response times are all things that are detectable well before a customer notices, if something is actually watching. That’s the whole point of uptime, SSL, and DNS monitoring: not that outages stop happening, but that you’re the one sending the first message instead of receiving it.

Set up monitoring on the sites you manage if you haven’t — check interval, SSL expiry warnings, and DNS change alerts cover most of what turned this particular fire drill into a fire drill in the first place. The next “is the site down” message should be one you send, with a fix already in progress, not one you receive cold.