Why your host will not tell you your site is down

Your server has not moved. The disk is fine, the network answers, the CPU is idle. And your homepage has been returning a 500 to every visitor for six hours.

Both statements are true at the same time, and that is the whole misunderstanding. Your host is not lying to you and not neglecting you: they are watching something other than what you think they are watching.

What they watch, what they cannot see, who sees it

The right-hand column is the one that counts: in five cases out of eight, the only person who knows is a visitor, and a visitor does not write to you.

Two different objects

A hosting provider watches the machine: is it powered, reachable, does it have disk space, is the network up. Their monitoring exists to honour their own commitment, which concerns the infrastructure.

Your site is an application running on that machine. A PHP error, a plugin update gone wrong, an expired certificate, a database that stopped: none of that makes the machine unhealthy. From the host's point of view everything is normal, and factually, they are right.

The five failures a host will never report

The expired certificate. The server answers perfectly, the browser refuses to display. No infrastructure indicator moves, and that failure leaves no trace in your logs.

The failed deployment. The document root points at the wrong place, a route is wrong, a config file is missing. The machine dutifully serves an error page, which is exactly its job.

The application error. A plugin update, an incompatible dependency, a database refusing connections. The web server answers, and it answers a 500.

Slowness. Eight seconds per page is a valid response as far as infrastructure monitoring is concerned. To a visitor, it is a broken site.

The partial outage. The homepage is fine, the checkout is dead. No tool that only tests the root of the domain will see it, including yours if you set it up that way.

What a host genuinely cannot know

Even with the best intentions, a provider does not know:

• what your homepage is supposed to display;
• whether a 302 redirect is deliberate or a broken deployment;
• whether an empty page is a design choice or a fatal error caught too late;
• whether your certificate covers the subdomain your customers actually use;
• whether the contact form still sends anything to anyone.

Answering those questions means loading your pages and knowing what to expect. That is not their job, and honestly, it should not be: a host inspecting the content of your pages would raise other problems, considerably more awkward ones.

Reading a status page without being caught out

A green status page does not say "your site works". It says "we have not declared an incident on our services". Three nuances are worth having.

It is declarative. An incident appears when somebody writes it there, often after internal confirmation, sometimes an hour after the moment you saw it.

It is global. An incident affecting three hundred servers out of fifty thousand may never appear at all, which is understandable and no comfort if you are one of the three hundred.

It does not cover the neighbours. The registrar, the mail provider, the CDN, the payment gateway each have their own, and a failure at one of them shows on your site without appearing anywhere at your host.

The managed hosting case

Contracts do exist that genuinely cover the application: managed hosting, managed support, offers with an application-level availability commitment. They cost more and they sometimes keep their promise.

Two checks before relying on one. Read what the contract actually monitors: "24/7 supervision" usually means the infrastructure, not your pages. And ask what triggers an intervention: a load threshold is not the same thing as an unexpected HTTP status on your homepage.

The test that settles it is one question for support: if my homepage returns a 500 for two hours on a Sunday, does anyone at your end notice? The answer is instructive, whatever it is.

What you can reasonably expect from your host

The point of this article is not to put them on trial. They provide a specific service, and it is useful to know which one, if only to avoid paying twice for the same thing.

Expect from them the availability of the machine, a network that answers, backups that genuinely exist and genuinely restore, an honest status page, and support able to say whether the incident is at their end.

Do not expect knowledge of your application, verification of your application-level certificates, review of your deployments, or an alert when your content changes shape.

A fair way to put it: your host answers for the building, you answer for what happens inside it. Both are necessary, and confusing the two perimeters is the most common cause of a long outage.

The one-evening test

If you are unsure what your current setup actually covers, run the experiment rather than the theory. On a staging environment, deliberately cause three failures and see who tells you, and how fast.

Stop the application service: you should receive something. Let a test certificate expire: this is where most setups discover their blind spot. Finally, break a single page while leaving the rest of the site up: that is the most frequent failure in production, and the one almost no monitoring detects by default.

The result of that exercise is worth more than any commercial promise, including mine.

The blind spot in the middle

Between "the machine is up" and "the site works", there is a gap where most outages live. Not spectacular failures: those get noticed. The quiet ones: an error on one page, a certificate expiring on a Sunday, a form that stops submitting after an update.

Nobody watches that gap by default. Not your host, whose job stops earlier. Not your visitors, who leave rather than write. And that gap is exactly where the cost of an outage is decided, since it depends less on the failure itself than on how long it stayed on screen.

Watching from where your visitors stand

The only viewpoint that matches reality is the outside one: load the page like a visitor, read the status code, check the certificate, and compare with what should happen.

That is the exact difference between infrastructure monitoring and website monitoring. They are complementary, not interchangeable, and only one of the two will tell you your homepage has been broken since this morning. Which leaves the question of who sets it up: your own script or an outside service, and how often the check should run.

The rule does not stop at your server, either. The links other sites gave you disappear in exactly the same way, with nobody writing to tell you and no report showing it: the same blind spot, one layer further out.

And on the day the alert arrives, it will not tell you what to do: the first fifteen minutes are the same, with or without a host on the phone.