"My hosting company already monitors my site. I don't need uptime monitoring."

I've heard this from several people recently, and it deserves a straight answer, because it's half true. The half that's true is worth knowing. The half that's false is the half that ends with a client telling you your site is down.

What your host is actually watching

When a hosting company says it monitors your site, it means it monitors its infrastructure. The server is powered on. The hypervisor is healthy. The network is passing traffic. Maybe a probe confirms the box answers HTTP at all.

That monitoring is real and it matters. It's also not for you. It exists so the host can meet its own SLA, and its alerts go to the host's ops team, about problems in the host's scope, on the host's schedule. You're not the audience. You're the person the SLA is quoted at.

The tell is simple: when was the last time your host called you about downtime before you noticed it? The monitoring exists. The phone call doesn't.

The homework-grading problem

There's a structural issue underneath, and it has nothing to do with any particular host being good or bad: the company that causes the downtime is also the company reporting it.

Nobody documents their own outages generously. Provider status pages updating to "investigating" an hour into an incident is an industry meme for a reason. And if you build sites for clients, this gets concrete fast: when a client asks how long their site was down, "the host says it was brief" is not an answer you can put your name on. A timeline recorded by a third party, timestamped from multiple regions, is.

Independent monitoring isn't about distrusting your host. It's about the difference between an audit and a self-report.

Most outages don't happen in the server

Here's the bigger problem with relying on infrastructure monitoring: the failures that actually bite are usually somewhere the host's checks can't see.

  • An SSL certificate expires and browsers start showing security warnings
  • The domain registration lapses, which no server metric anywhere will notice
  • A DNS edit goes wrong and traffic quietly routes to nothing
  • A CDN misconfiguration serves errors while the origin hums along
  • A deploy breaks the app, and the server keeps happily serving the broken build
  • WordPress white-screens after a plugin update, often with a healthy 200 status
  • The checkout errors out while the homepage your host's probe hits stays perfect

The server is up through every one of these. The host's dashboard is green through every one of these. Your site, for the purposes of anyone actually trying to use it, is down. (The 200-but-broken family is its own topic, covered in a website that returns 200 can still be down.)

Uptime monitoring worth the name checks the things on that list: certificate expiry, domain expiry, DNS records, page content, specific API responses. Not because the server doesn't matter, but because the server is the one part somebody's already watching.

"Up from the datacenter" isn't up

Host checks run from inside the host's own network, next door to your server. That answers one question: does the box respond to a neighbor?

Whether someone in Singapore, or Frankfurt, or on the other side of a routing incident can reach your site is a different question, and it's the one your visitors are asking. Checking from the outside, from several places at once, is the only way to answer it. It also protects you in the other direction: Sentinel needs agreement from multiple regions before it calls something an outage, so one flaky network path doesn't page you at 2am for nothing.

When the objection is right

Being fair about it: if you run a static brochure site on a genuinely proactive managed host, the kind that notices problems and fixes them without being asked, the marginal value of independent monitoring is smaller. That's real, and I'd rather say it than pretend otherwise.

But notice what that concession covers. Even the best managed hosts monitor their platform, not your particular site's behavior. They'll catch their fleet-wide outage. They won't catch your expired domain, your broken checkout, or the plugin conflict that only whitescreens your site. And the moment anyone pays you for a website, the calculus flips entirely, because the question stops being "is somebody watching a server?" and becomes "who finds out first, and whose name is on it?"

"The host was watching" has never once satisfied a client who found the outage themselves.

Who finds out first

That's the whole subject, compressed. Downtime isn't rare, it's just usually short, and the difference between a non-event and an embarrassment is who notices. If your host notices first, their ops team fixes their problem on their timeline. If your client notices first, you have a relationship problem. If you notice first, you have a maintenance win you can point to, backed by data a third party recorded.

Sentinel's free plan does this for 10 sites: 5-minute checks from four regions, SSL and domain expiry warnings, email and Discord alerts, and a public status page. No credit card, and commercial use is allowed, so client sites count. Your host will keep monitoring their server either way. Someone should be monitoring your site.