uptime

Why your website goes down (and why you're usually the last to know)

Most outages don't get found by the owner. They get found by a customer hitting a broken page — and then quietly leaving. Here are the most common reasons sites go down, and why a human glancing at the homepage once a day is no defense.

MyUptimeBot Team · December 1, 2025 · 3 min read · For site owners

Outages are surprisingly mundane

When you imagine your website going down, you probably picture something dramatic — a hacker, a viral spike of traffic, a server fire. The reality is much more boring. Most outages are caused by small, predictable things that nobody noticed until someone hit a 404 trying to buy something.

Here’s what actually takes sites offline, in roughly the order we see them most often.

1. The SSL certificate quietly expired

Browsers no longer give visitors a polite warning when your certificate has expired. They show a full-screen red error that says, in effect, “this site might be trying to steal your information.”

Most certificates auto-renew. The ones that don’t tend to be the ones you set up two years ago and forgot about. Then one Tuesday morning the renewal silently fails — wrong domain, payment card expired, DNS verification didn’t go through — and from that moment on, every single visitor sees the scary screen.

You won’t see it yourself, because your browser remembers you’ve trusted the site before.

2. Your hosting provider had a bad night

Even the big names go down. AWS, DigitalOcean, Cloudflare, Vercel — they all have incident pages, and those incident pages have history. Most of the time the outage is short and regional. Sometimes it’s two hours long and it takes out a whole rack of customers.

Your hosting dashboard will eventually tell you. The signal you actually need is “are visitors getting through right now?” — and that requires checking from somewhere that isn’t your server.

3. A deploy broke something

You pushed a small change. Maybe you updated a plugin. Maybe you changed an environment variable. Three minutes later, the homepage returns a 500 error and your blog index returns a blank page.

This is where downtime detection saves the most embarrassment. The bot will see the bad deploy within a minute. You will see it when a customer emails you on Saturday morning.

4. The database connection pool maxed out

Less common for static sites, but if you have anything dynamic — login, checkout, anything that hits a database — connection pool exhaustion is a classic. The site loads for a few people, then stops loading for everyone.

The symptom is usually slow responses first, then timeouts. Response time monitoring catches this one before it becomes a full outage.

5. DNS

DNS issues are rare but devastating. Someone in your team (or your registrar) made a change. Maybe a TTL got too aggressive, maybe a record pointed to the wrong place. The result is the site appears to “not exist” for everyone trying to reach it for the first time.

Hard to detect from a single location — you need checks from multiple regions, because DNS propagates unevenly.

Why a human eyeball check doesn’t work

A lot of people we talk to say something like, “I check the site every morning when I sit down with coffee.” That’s fine. It catches an outage that happens between 8 AM and 9 AM on a weekday.

The other 23 hours of the day are the ones where customers are quietly bouncing.

A monitoring bot doesn’t have coffee mornings. It checks every 30 or 60 seconds, from a location that isn’t your laptop, and it tells you the moment something stops working — not on the next business day.

What good monitoring looks like

You don’t need a complicated setup. The minimum that catches most outages:

  • An external check every minute or so, hitting your homepage and any critical page (login, checkout).
  • SSL expiry monitoring that warns you weeks before expiration.
  • A notification channel you’ll actually see — push notifications on your phone usually beat email for urgency.

That’s the bare minimum. Everything else (content change detection, multiple regions, response time tracking, team notifications) is gravy that helps you debug faster once you know something broke.

The honest pitch

This is the part of every blog post where the company pretends they aren’t selling something. We’re going to skip that. The bot we’re describing is the one we built — MyUptimeBot — and the free plan covers exactly the minimum we just laid out: one monitor, checked every three minutes, with push and email notifications, no credit card required.

If your site is small and you’re not currently monitoring it: do something. It doesn’t have to be us. But finding out from a customer is the worst possible way to learn your site is down.

MyUptimeBot
Watching the internet

We build a friendly bot that watches your websites every 30 seconds and alerts you the moment something breaks. Notes here come from running that infrastructure, talking to the people who depend on it, and reading the postmortems no one publishes.

Stop finding out from customers.

One monitor, free forever. A friendly bot doing the worrying for you.