It’s 2:14 PM. Someone drops “is the site down for anyone else?” into your team Slack, and your stomach already knows the answer before you’ve even opened a new tab.
Every minute after that message costs something. A widely cited 2014 Gartner study puts the average cost of downtime at roughly $5,600 a minute for larger companies; more recent industry surveys put small and midsize businesses closer to $400–$1,700 a minute once you factor in lost sales, support overhead, and staff time. Either way, a ten-minute outage is not a rounding error. It’s real money, real customers, and if it drags on a quiet hit to how Google treats your site.
That last part surprises people. Google has said plainly that short bursts of server errors mostly just slow down how often Googlebot crawls you, and pages usually bounce back fine once things stabilize. But multi-day outages are a different story — Google’s own guidance is that persistent server errors can eventually get pages dropped from the index, and earning that visibility back takes far longer than losing it.
So the ten minutes right after you discover an outage matter more than almost any other ten minutes in your week. The problem is that most “website down” articles are recycled fluff: check your internet connection, try refreshing, contact your host. That’s not a plan. That’s a shrug dressed up as advice.
Here’s an actual plan — the same mental model sysadmins, DevOps engineers, and agency owners run when a client site goes dark. It works because it’s built on one idea: a website never “just breaks.” It breaks at one of three specific layers DNS, network, or server — and once you know which layer, the fix (or the phone call) becomes obvious.
The 90-Second Version
If you only have time to skim, do these five things, in this order:
- Check the site from a different network (phone data, not Wi-Fi) and on a third-party down-checker rule out “it’s just me.”
- Read the exact error message or status code. It’s a diagnosis, not noise.
- Run one DNS lookup and one domain-expiration check dead DNS and expired domains cause more “mystery outages” than anything else.
- Check your host’s status page and your server’s resource usage CPU, RAM, and especially disk space.
- If you can’t identify which layer is broken within ten minutes, stop guessing and escalate. That’s not failure. That’s the correct call.
Now let’s walk through it properly, minute by minute.
Minute 0–2: Prove It’s Actually Down (Not Just You)
A shocking number of “outages” never touch the server at all. They’re a stale DNS cache on your laptop, an ISP having a bad afternoon, or a VPN and ad blocker on your own machine quietly blocking the page. Before you touch anything server-side, rule yourself out.
- Use a third-party down-checker like downforeveryoneorjustme.com. These ping your site from external servers, completely bypassing your local network, so you get an unbiased answer in seconds.
- Switch off Wi-Fi and load the site on mobile data. If it loads fine, the problem is local — your router, your ISP’s DNS resolver, or a corporate firewall — not your website. This single test saves more wasted panic than any other step on this list.
- Open an incognito window or a different browser entirely. Cached redirects, stale cookies, and browser extensions (especially ad blockers and security plugins) cause a surprising number of false alarms.
- If you’re comfortable with a terminal, run:
curl -I https://yourdomain.com
The -I flag fetches only the response headers. A healthy site returns something like HTTP/2 200. Anything else — or nothing at all — is your first real clue, and it’s more reliable than what a browser shows you, because it skips caching entirely.
Minute 2–4: Read the Error Like a Diagnosis, Not Noise
Most people see “This site can’t be reached” and start panic-refreshing. But the specific message or status code almost always tells you exactly which layer failed. Screenshot it before you do anything else — if you end up calling for help later, this one detail can cut diagnosis time in half.
| Error / Code | What it actually means | Most likely cause |
|---|
| 500 Internal Server Error | The server ran your code and it crashed | A PHP fatal error, a bad code deploy, or a broken plugin/theme update |
| 502 Bad Gateway | The proxy/CDN got no valid response from the app server behind it | The app process (PHP-FPM, Node, etc.) crashed or isn’t running |
| 503 Service Unavailable | Server is up but can’t or won’t handle the request | Resource limits hit, maintenance mode left on, or sudden overload |
| 504 Gateway Timeout | The backend took too long to respond | A hung database query, an infinite loop, or an overloaded DB |
| 521 / 522 / 523 (Cloudflare-specific) | Cloudflare can’t reach your origin server at all | Origin server is down, a firewall is blocking Cloudflare’s IP ranges, or DNS points to the wrong place |
| 526 (Cloudflare-specific) | SSL handshake with your origin failed | Expired or invalid SSL certificate on the origin server |
| DNS_PROBE_FINISHED_NXDOMAIN | The domain doesn’t resolve to anything | DNS misconfigured, nameservers changed, or the domain has expired |
| ERR_SSL_PROTOCOL_ERROR / NET::ERR_CERT_DATE_INVALID | Browser refuses to connect over HTTPS | Certificate expired, mismatched, or a renewal failed silently |
| ERR_CONNECTION_TIMED_OUT | Nothing answered the request at all | Server down, a firewall dropping traffic, or DNS pointing to a dead IP |
| “Error establishing a database connection” (common on WordPress) | The app loaded but can’t reach its database | DB server down, wrong credentials, corrupted tables, or max connections reached |
| 403 Forbidden | Server is up and deliberately refusing access | A WAF or security plugin false positive, a bad .htaccess rule, or a file permissions issue |
Minute 4–6: Work the Chain, Starting With DNS
Here’s the mental model that makes everything else fast: a page load is a chain. Your browser asks DNS “where does this domain live?” → DNS points to an IP address, which might sit behind a CDN or proxy → that network layer forwards the request to your actual server → the server runs your application and sends back a page. A break at any link takes down everything downstream of it, and misdiagnosing which link broke is exactly why people waste 45 minutes restarting a server that was never the problem.
Start at the beginning of the chain, not the end:
dig yourdomain.com +short
dig NS yourdomain.com
If the first command returns nothing, DNS itself is broken nobody on earth can find your site right now, and no amount of server-restarting will fix that. If the second command shows nameservers you don’t recognize, someone (or something) changed them recently — an unfinished migration, an accidental edit, or in rarer cases, unauthorized access to your domain registrar account.
While you’re here, check the domain’s expiration date through a WHOIS lookup. This sounds almost too simple to matter, but it’s one of the single most common causes of a total, sudden outage: a domain bought years ago on auto-renew, tied to a credit card that quietly expired, with the renewal notice buried in an inbox nobody checks.
Minute 6–8: Check the Network Layer, Then the Server — and Look for What Changed
Network / CDN layer:
- Check your CDN or proxy provider’s status page for a regional incident this rules out your infrastructure entirely.
- Confirm the DNS record’s proxy setting is correct. A record accidentally switched to “DNS only” can expose a firewalled origin IP directly; one wrongly routed through a broken proxy config does the opposite.
- Check your firewall or WAF’s recent block log. A “security hardening” pass from last week sometimes doesn’t cause problems until a specific rule finally triggers days later and it’s just as happy to block Googlebot as it is to block an attacker.
Server / origin layer:
- Check your host’s own status page and account dashboard.
- Check resource graphs: CPU, RAM, and — this is the one people forget disk space. A server can be perfectly healthy in every other way, but a full disk (from log files, a growing database, or a backup job that never cleaned up after itself) will silently stop database writes and take the entire site down. It rarely shows up as an obvious error, which is exactly why it’s so often the culprit nobody checks first.
- If you have shell access, confirm the key processes are actually running: your web server, your app process (PHP-FPM, Node, etc.), and your database.
- Check billing status on the hosting account. Suspensions from a failed payment are far more common than anyone likes to admit, and like the domain renewal the notice usually lands in an inbox nobody’s watching.
Then ask the only question that actually matters: what changed? Servers don’t spontaneously break. Something shifted. Run through this list:
- A recent code deploy or push
- A plugin, theme, or CMS core update
- A DNS record edit
- An SSL certificate renewal Let’s Encrypt auto-renewals fail silently more often than people expect
- A server or hosting migration
- A sudden traffic spike (a viral post, an ad campaign that just went live, or a bot/scraper flood)
- A cron job or scheduled task that ran overnight
Minute 8–10: Try the Safe, Reversible Fixes Only
- Purge the CDN cache.
- Restart the web server or app process through your host’s control panel, if available.
- If a plugin or theme update is the suspect, disable it by renaming its folder over SFTP or file manager — don’t try to log into a broken admin panel to do it the normal way.
- Turn off maintenance mode if it’s stuck on.
- Renew or reissue an expired SSL certificate.
- Revert any DNS record someone on your team changed today.
The rule for this window: don’t do anything you can’t undo, and don’t do anything you couldn’t explain to the person you might need to call next.
When to Stop and Call for Help No Exceptions
Some situations aren’t a ten-minute problem. They’re a “stop touching things right now” problem. Escalate immediately if you see any of the following:
- Signs of a hack, defacement, or injected content strange redirects, spam pages suddenly indexed under your domain, files you didn’t create. Don’t try to “clean it up” yourself and don’t reinstall over the top of it. Doing so can destroy the exact evidence a security professional needs to figure out how the attacker got in and whether they’re still inside.
- Ransomware or encrypted files. Disconnect the server from the network if you’re able to, and get an incident responder involved immediately. Don’t attempt decryption or negotiation yourself.
- Database corruption that survives a restart. If it crashes again within minutes, or repair tools fail outright, you’re past the safe DIY zone a rushed manual repair can quietly corrupt data further.
- No backups, and you can’t answer “what was different an hour ago.” At that point, guessing isn’t troubleshooting. It’s gambling with your only copy of the site.
- The site is revenue- or compliance-sensitive right now mid-sale ecommerce, healthcare, finance, anything touching payment data or personal information. The cost of a wrong guess outweighs the cost of a support call, every single time.
- The traffic pattern looks like an attack the server is maxed out despite normal-looking visitor numbers, or a graph spikes vertically with no marketing event behind it. This needs rate limiting and traffic scrubbing, not a server restart.
- You’ve used the full ten minutes and still can’t tell which layer broke. That uncertainty is the signal. The people who resolve outages fastest aren’t the ones who never need help they’re the ones who recognize the exact moment to ask for it.
Build Your “Break-Glass” List Before You Need It
The worst time to find your host’s support number is during an outage. Before the next one hits, have on hand: your hosting provider’s priority support line (not just the general contact form), your DNS/CDN provider’s status and support channels, a developer or agency you can call on short notice, and if you handle anything sensitive a security incident responder. Keep account logins accessible to more than one trusted person; a single point of failure in “who has the password” turns a ten-minute outage into a two-hour one.
Prevention: Make This Checklist Shorter Every Time
- Uptime monitoring with phone or SMS alerts (UptimeRobot, Pingdom, StatusCake, Better Uptime) checking from multiple regions every one to five minutes so you find out before your customers tell you.
- A public status page, even a simple one. It cuts the support-ticket flood during an incident and does more for customer trust than any apology email.
- Offsite, tested backups. A backup you’ve never actually restored isn’t a backup it’s a hypothesis.
- A staging environment, so updates get tested somewhere other than production.
- Centralized tracking of domain, SSL, and hosting renewal dates. A calendar reminder thirty days out is cheaper than any outage it prevents.
- A written incident runbook honestly, this article, customized with your actual host, DNS provider, and emergency contacts filled in.
