Detect Website Outages and Problems

The worst way to learn your site is broken is an email that opens with “hey, is your website down?” By the time that message lands, the visitor already gave up, and probably a few dozen others did too without saying anything.

That gap between “something broke” and “someone told me” is the only part of an outage you actually control. You can’t stop your host from having a bad afternoon. You can’t stop a CDN provider from pushing a config change that withdraws your routes. What you can control is how quickly you find out, and whether you find out from a tool or from a customer.

CheckSiteStatus exists for that first minute. You paste a URL, and you get a real answer about whether the site is reachable, how fast it responds, and what the server sends back: no account, no setup, no waiting.

What counts as an outage, and what doesn’t

Most people picture downtime as a blank page. In practice, full hard-down failures are the minority. The messier cases are the ones that cost money quietly:

• The homepage loads fine, but checkout throws a 500.
• The site responds in 14 seconds instead of 800 milliseconds, so visitors leave before it finishes.
• Users in Germany can’t reach you while everyone in the US is fine.
• The page loads, but an expired SSL certificate makes the browser throw a full-screen security warning.
• The server returns a 200 OK while serving a defaced page or a blank template.
  
  

That last one matters more than people expect. A status code of 200 only means the server answered. It says nothing about whether the answer was correct. This is why checking content, not just availability, is worth doing on pages that generate revenue.

Then there’s the oldest question in support tickets: is it down for everyone, or just me? Your own browser is a terrible witness. Cached DNS, a stale service worker, an office firewall, a VPN route, or a single ISP having a bad day can all convince you the site is dead when it’s perfectly healthy for everyone else. An external checker answers this in one step because it isn’t sitting on your network.

How fast you actually need to know

The numbers here are blunt. ITIC’s 2024 downtime survey found that more than 90% of mid-size and large enterprises put the cost of an hour of downtime above $300,000, and 41% put it between $1 million and $5 million. The Uptime Institute’s 2026 outage analysis reported that roughly one in five significant outages now exceeds $1 million. Gartner’s much older $5,600-per-minute figure gets quoted constantly, and even that dated benchmark works out to $336,000 an hour.

Small sites don’t lose $300,000 an hour. But the math scales down without getting less painful. Take your annual revenue, divide by 8,760, and you have a rough hourly figure before you add support time, ad spend burning on dead landing pages, and the customers who don’t come back.

There’s a second reason speed matters, and it has nothing to do with revenue. Long outages hurt search rankings. If Googlebot hits repeated 5xx responses over days rather than hours, crawling slows and pages start dropping. A 20-minute blip is noise. A 20-hour blip is a problem you’ll still be paying for in six weeks.

Uptime Institute’s 2026 report also flagged a shift in causes: networking and connectivity problems now account for about 23% of IT service outages, edging ahead of power at 21%, and network incidents have more than doubled against the 2020 to 2025 average. Facilities have gotten better at keeping the lights on. The network layer has gotten more fragile. That means more of your failures will come from something you don’t own, which makes external monitoring more useful, not less.

The signals worth watching

Availability is one signal. Five others tell you more about why.

Response time is the early warning system. Sites rarely fall over without warning. They get slow first, usually because a database query is stacking up or the server is running out of workers. If your typical response is 600ms and you’re seeing 4 seconds, you have maybe an hour before that becomes a 504.

HTTP status codes tell you which layer broke. More on this below, because it’s the single most useful diagnostic you get for free.

DNS resolution is the failure nobody checks until it’s the problem. Expired domains, a nameserver change that didn’t propagate, a registrar lock, a deleted A record after a migration. The site is fine. Nobody can find it.

SSL certificate expiry is the most preventable outage in existence, and it still happens to large companies every year. Auto-renewal fails silently, nobody notices, and one morning every visitor gets a browser interstitial telling them your site is dangerous. Certificates have a date on them. There is no excuse for being surprised.

Content integrity catches the cases where the status code lies. If a critical phrase disappears from your pricing page, or unfamiliar text shows up, you want to know without reading the page yourself every morning.

Geography catches the rest. Routing problems, regional cloud incidents, and country-level blocks all produce outages that only exist for part of your audience. Checking from a single location gives you a single location’s opinion.

Reading the error your visitors see

When a check comes back red, the status code narrows the cause fast:

The two you’ll meet most often on WordPress and other PHP stacks are 502 and 504, and they’re easy to confuse because both point at the layer behind your web server. The difference is whether that layer answered badly or didn’t answer in time. If you want the full diagnostic path for each, we’ve written them up separately: what a 502 bad gateway actually means and how to fix it, and the causes and fixes for a 504 gateway timeout.

One thing worth internalising: a 5xx is your problem; a 4xx is usually a request problem. Teams waste hours debugging application code for what turns out to be a firewall rule.

Checking a site in seconds

The immediate workflow is short:

1. Paste the full URL, including https, into CheckSiteStatus.
2. Read the status code and the response time together. A 200 with a 9-second response is not a healthy site.
3. If the check says the site is up and you still can’t reach it, the fault is between you and the server. Flush your DNS cache, try mobile data, try an incognito window.
4. If the check says the site is down, look at what came back. A 503 and a DNS failure send you to completely different places.
5. Check your host’s status page before you start debugging your own code. If their platform is having an incident, there is nothing in your application to fix.
   
   

Step five saves more time than the other four combined. During a large provider incident, thousands of sites go down simultaneously, and none of them have a bug.

Stop checking manually

Manual checks answer “is it down right now.” They can’t answer “was it down at 3 am on Sunday,” which is when most quiet outages happen and when nobody is watching.

Continuous monitoring solves that, but only if the alerting is configured with some restraint. Get this wrong, and you build an alarm nobody reads. A few rules that hold up in practice:

Check often enough to matter. A 60-minute interval means you can be down for 59 minutes before the first ping. One to five minutes is the range where alerts arrive while the incident is still small.

Require confirmation from a second location before alerting. Single-probe failures are frequently the probe’s fault, not yours, and one false alarm at 4 am costs you credibility for every real alert afterwards.

Route alerts to a channel people actually see. Email at night is functionally a log file. SMS, push, or a paged Slack channel is an alert.

Alert on slowness too, not only on hard failures. Degradation is the warning shot.

Monitor the paths that make money, not just the homepage. Login, search, checkout, and the API endpoint your mobile app depends on can each fail while the front page looks perfect.

The setup takes about ten minutes if you follow a structured walkthrough. Ours is here: how to set up uptime alerts, step by step.

Mistakes that keep teams blind

Monitoring from inside your own network is the classic one. If your check runs on the same server, both go down together and you learn nothing.

Trusting a 200 as proof of health is the second. Add a keyword check on pages that matter so you’re validating content and not just connectivity.

Ignoring SSL and domain expiry dates is the third, and it’s the one that ends careers in small hosting teams. Both are calendar problems with a known date. Put them in a calendar.

And the quiet one: never recording anything. If you don’t keep a history, you can’t tell your host “this is the fourth time this month,” and you can’t tell whether your uptime is improving or slowly rotting.