Your host monitors its servers. We monitor your website.
Those are not the same job. A server can be running perfectly while your site returns a 500 to every visitor, and a status page that says "all systems operational" is describing the host's network, not your application. Every site we host is checked continuously from outside, and when something breaks the alert goes to people who can log into production and fix it.
"The server is fine" is not the same as "the site works."
Standard hosting monitors the things a host is responsible for. That is reasonable of them, and it is not what you needed to know.
What a standard host watches
Whether the machine is running
The server responds, the disk is mounted, the web service has not crashed. All true, all compatible with your site being completely broken.
Their infrastructure, not your application
A host status page reports on their network and their hardware. Your site is not on it, and an incident that affects only you will never appear there.
Nobody is watching on your behalf
Even where alerting exists, it fires into a support queue that opens on Monday. The first person to notice an outage on Saturday night is usually a customer.
What we watch
Whether the page actually returns
Checked continuously from outside your network, the way a visitor experiences it, rather than from inside the machine that may itself be the problem.
Your site specifically
Per site, with its own record. An outage that affects one of your properties and nothing else on the network is exactly the kind that gets missed.
An alert that reaches someone who can act
This is the part free checkers cannot solve. An email to an inbox is not a response. On managed plans the alert reaches engineers with production access and a mandate to use it.
Nothing to configure, nothing to remember.
Your sites are checked from outside
01Continuously, from beyond your own infrastructure, so a network or DNS problem between your visitors and your servers is caught rather than hidden by checking from inside.
A failure raises an alert
02To our team, not just to a dashboard nobody is looking at. On managed plans that alert is the start of an incident response rather than the start of a support ticket.
The record lives in your portal
03Availability over time, per site, in the same portal as your vulnerability reporting. Evidence you can put in front of a board, an auditor or a client.
Most outages never touch the server.
In more than ten years of running production websites, the failures that cost clients money have very rarely been a server falling over. They look like this.
The site is up and broken
A deploy half-succeeds, a database connection pool exhausts, a cache fills. The machine is healthy and every visitor gets an error page.
Something expired
A certificate, a domain, an API credential. Nothing crashed — a date passed, and the browser now shows a security warning instead of your homepage.
Somebody else's problem became yours
A third-party script, payment gateway or API stalls, and the page hangs waiting for it. Your infrastructure is faultless and your site is unusable.
The tools most hosts charge extra for, or simply do not have.
Both of these come with hosting. Not as a trial, not as a tier upgrade, not as a line item that appears at renewal.
Continuous external checks on every site, alerting engineers with production access, with the availability record kept per site in your portal.
Every package on your servers matched continuously against NVD and Ubuntu Security Notices, so you know what is vulnerable before somebody else finds out for you.
The reason the first two are worth having. A finding nobody can act on is a notification, and notifications do not keep websites online.
Standard web hosting sells you infrastructure and leaves the operating of it to you. That is a legitimate product, and it is the reason so many organisations discover their monitoring gap during the outage rather than before it.
Both tools come with every managed hosting plan and every website support SLA.
The questions worth asking your current host.
Isn't this the same as UptimeRobot or Pingdom?
The checking part is not difficult, and those tools do it well. The difference is what happens when a check fails. A standalone monitor sends you an email; you still have to diagnose the fault, find someone with production access and get it fixed, usually at the least convenient hour. Here the alert reaches engineers who already run the infrastructure. Monitoring is the cheap half of the problem.
Do I need to set anything up or pay extra?
No. It is configured as part of hosting and included at no additional cost, alongside CVE scanning. There is no separate subscription and no tier that unlocks it.
How is this different from the uptime percentage in an SLA?
An SLA is the commitment; monitoring is the measurement that makes the commitment meaningful. An uptime guarantee with no independent record behind it is a sentence in a contract. The monitoring record is what turns it into something either party can point at.
What happens when it detects an outage?
On managed plans it raises an alert to our engineers rather than a notification to a dashboard, and severity determines the response. On hosting-only plans the alert and the record are yours, and remediation is handled as break/fix work.
Why doesn't my current host already do this?
Because they are monitoring what they are accountable for, which is their infrastructure. Watching your specific application, alerting a human, and having that human able to log in and fix it is an operational cost that does not fit the economics of volume hosting. It is the difference between hosting and managed hosting.
Can I see historical uptime for reporting?
Yes. Availability is recorded per site over time in the client portal, which is what you need when a board, an auditor or a client asks you to substantiate a reliability claim rather than assert one.
Does this replace having an SLA?
No. Monitoring tells you something is wrong. An SLA defines how quickly somebody is obliged to do something about it, at what severity, and outside what hours. Organisations that need a contractual response commitment need both.
How did you find out about your last outage?
If the answer is "a client rang", the monitoring gap is already costing you something. It is included with every plan we run.