Website monitoring tools, and what separates them
A website monitoring tool calls your pages on a schedule and warns you when the answer changes. Nearly all of them do that much. What separates them is how much of the answer they read, where they measure from, and whether the alert tells you what to fix.
Facts about the other tools were read on their own pages on 2026-07-29. Our own figures come from the engine source, which is public. Page updated on 2026-07-31.
The loop is always the same. The tool requests a URL at a fixed interval, compares the answer with what it expects, keeps the result, and notifies someone when the two stop matching. Keeping the result is what makes it monitoring rather than a checker: without history you cannot say whether last night was an incident or a hiccup.
Three settings decide most of your daily experience with any of them. The interval sets how long a failure stays unknown. The confirmation rule, a second failing pass before the alert goes out, decides how often the tool cries wolf. The channel decides whether the message reaches a human on a Saturday morning.
The vocabulary is where this market gets slippery. A tool reporting 99.98 percent is describing how often a server answered, not how often the site worked. The two figures can disagree for weeks without either being wrong.
The checks, and where a status code stops
Every tool in this market answers one question well: did the server reply, and how fast. The differences all live in whether it then reads the body of the reply, and in what it looks for there.
- Availability and response time. Universal. Status code, redirect chain, how long the answer took. This is the part every pricing page describes at length.
- A string that must be there. Common, and useful: if the word disappears, the page changed even though it still answers. The reverse test, a string that must never appear, is rarer, and it is the one that catches "Fatal error" printed at the top of a page that is otherwise perfectly valid.
- Certificate and domain expiry. Widely offered, sometimes only on the paid tiers. Worth checking which, because an expired certificate takes a site offline for every visitor at once.
- Cron and backup heartbeats. A URL your scheduled task calls when it finishes, where silence is the failure. It covers the jobs nobody watches, which is why a broken nightly backup is usually discovered on the day it was needed.
- The rendered layout. Rare. Our engine crosses nine signals here: whether each referenced stylesheet and script answers, whether the returned body really is CSS rather than an error page, MIME and blocking rules, an SRI hash that no longer matches, CSS volume against a learned fingerprint, whether the classes used in the page still find a rule, layout primitives, dead theme scripts, and blocks left invisible because the animation script that reveals them has gone. No single one of those is conclusive, which is exactly why there are nine. All nine are countable in src/Check/Css.php.
- The page as visitors would see it. Rare, and we have not found it anywhere else in this category. Not a screenshot: the block structure is read from the HTML, laid out according to what the stylesheets that actually loaded allow it to do, then compared against the shape the page had when it worked. Opening a real browser is out of the question for a collector that has to run on shared hosting, and it turns out not to be needed: when the CSS falls away, the silhouette changes exactly as the page changes. A stylesheet that died is then visible in one glance, without opening the site. The reconstruction lives in src/Check/Silhouette.php.
- Components with a published flaw. Rare, and it belongs with the deadlines rather than with the outages: an outdated plugin carrying a published exploit is a date coming at you too, and it is the one that ends badly. Our engine inventories the components it can read in the page, then crosses each detected version against public advisories. It keeps two findings strictly apart: a published flaw, where an identified advisory covers the exact version detected, and a version merely behind the latest, which is a debt and not a hole. Saying the first when you only know the second would cost the check the credibility it exists to earn. The rule and its sources are in src/Vuln.php.
- An application error inside a 200. Rare, and it is the failure clients notice first. Our engine matches the top of the page against 41 signatures, 35 for database and application errors and 6 for PHP fatals, with nothing to configure. Both tables sit in src/Check/Database.php.
- A noindex that shipped by accident. Rare, and the most expensive of the lot precisely because nothing breaks. The site is fine, the traffic just leaves, and the cause is a checkbox someone forgot on a staging copy.
- A JSON path and its value. For an endpoint rather than a page. Same idea as the required string, applied to an API answer.
The first four you can take for granted on any shortlist. The last six are where the list gets short.
Six layers, and what each one costs your server
| Layer | What it checks | Network cost |
|---|---|---|
| Availability | HTTP code, detailed timings, redirects, retries | The page request |
| Layout | Nine signals over CSS, scripts and fonts, plus the silhouette | The page resources, at most every 15 minutes |
| Data | Forty-one signatures, CMS probe, proof string, forbidden string | No extra call, except the CMS probe |
| Speed | Response time, render-blocking files, top-of-page image | One HEAD request on an image |
| Deadlines | Certificate, domain expiry, published advisories | One pass a day, cached |
| Silence | Dead-man heartbeat for cron jobs and backups | None: your script does the calling |
That third column is the one to ask any candidate about before you point it at thirty sites you did not build, and it is the hardest figure to find on a pricing page.
Hosted, or installed on your own server
Hosted means someone else runs the watcher and measures from outside your network, which is the correct place to stand. Installed means the measurements stay on a machine you control, and the watcher becomes one more thing you keep alive.
What actually decides between the two is the install requirement, not the licence. Uptime Kuma, the self-hosted tool everybody recommends, needs Docker or Node.js 20.4 and up under PM2, which rules out the shared hosting most small agencies already pay for.
Ours needs PHP 8.2 and a database. There is no composer.json and no package.json in the repository, so there is nothing to build and nothing to keep up to date but the files themselves. That constraint is the whole reason it runs on the kind of shared hosting the sites it watches already live on. The repository root shows it at a glance: github.com/coeurduweb/uptimeez.
One rule holds whichever family you pick, and it is the one people learn the hard way: do not run the monitor on the machine it watches. A server that falls over takes its own alerting with it, and it does so in silence.
UptimeEZ exists in both families on purpose: the same engine, either installed by you or run by us, under the MIT licence in both cases. Which one you choose changes who gets woken up when the monitoring server needs a reboot, and nothing else.
Seven things these tools do better than UptimeEZ
Seven capabilities we do not have, and none of them is small. If one of them is the reason you are shopping, take the tool that has it: there is no setting of ours that gets you there.
| What you might need | Who does it, per their own pages | UptimeEZ |
|---|---|---|
| Measuring from several places at once | Advantage: them. Site24x7: up to 16 locations, plus pollers behind a firewall. UptimeRobot: four regions | One place, the server running the engine |
| On-call rotation and escalation | Advantage: them. Better Stack, where it is a core feature, with incident management alongside | Nothing of the sort. Email, Discord, Slack, webhook |
| Real User Monitoring, from actual visitors | Advantage: them. Pingdom, plus scripted journeys through a multi-step flow | Not at all. We read the page, not your visitors |
| Network probe types beyond HTTP | Advantage: them. Uptime Kuma: TCP ports, ping, DNS records, Docker containers, ten types in all | HTTP pages, JSON endpoints and heartbeats |
| Driving a real browser through the page | Advantage: them. Hyperping, from its middle tier upwards | No. HTTP reading only, which is the limit of our layout signals |
| Server resources: processor, disk, memory | Advantage: them. StatusCake and Site24x7, in the same account as the uptime checks | No. We watch websites, not the machines under them |
| A polished public status page on your domain | Advantage: them. Hyperping, better than anyone here | No |
| A free hosted tier | Advantage: them. UptimeRobot: 50 monitors at five minutes. Hyperping: 20. Site24x7: 5 from 3 locations | None hosted. The engine itself is free forever, installed by you |
Every cell was read on their own pages on 2026-07-29. Where a page says nothing about a feature we write "not announced" rather than "cannot do it", and where they are ahead we say so on the page they compete on.
Each one, line by line
Or all seven in one table, with a guide to choosing including when the answer is not us
- UptimeEZ vs UptimeRobot The default choice, and the one most people outgrow
- UptimeEZ vs Uptime Kuma The self-hosted favourite, and the honest comparison
- UptimeEZ vs Better Stack Built for engineering teams, priced for them too
- UptimeEZ vs StatusCake A long-standing checker with a small free tier
- UptimeEZ vs Pingdom The historical name, priced for the enterprise that inherited it
- UptimeEZ vs Site24x7 A whole observability suite, if that is what you came for
- UptimeEZ vs Hyperping Beautiful status pages, and real browser checks
Choosing one when the sites are not yours
When the sites belong to clients, the tool gets judged on a second question: not whether it noticed, but whether the message says enough for you to act before the phone rings. That question barely matters when you watch your own service, and it decides everything when you watch thirty that you did not build.
Start with the billing unit, because it bites later. Almost everyone counts monitors, and a monitor is one check on one URL: an ordinary WordPress site with a page check, a certificate check and a nightly backup heartbeat spends three. Thirty sites is ninety monitors, which is a tier or two above where you thought you were.
Then three things that matter more for a portfolio than for a single site: an alert that names a cause instead of a status code, a read-only link you can hand a client without buying them a seat, and a report the client can read in their own language. Our engine ships 25 causes, each with a title, what it means and the first thing to check, in 10 interface languages including the client report. Both are countable: src/Diagnose.php for the causes, and the catalogue list in lang/ for the languages.
The read-only link is the one of those three that changes what a portfolio costs, so it is worth being precise about. Tick their sites, copy their link, done: no invitation to chase, nothing they can change, and nothing of anybody else's on the page. It is what you send when a client asks whether it is fixed yet, which is the message that otherwise interrupts whatever you were doing.
Reading the layout earns its place here for an unglamorous reason. The failures that reach a client before they reach you are plugin updates and lapsed certificates, not servers falling over. A server that falls over gets noticed by everyone at once, including the host.
What one costs, and what the price is counting
Entry prices for a paid plan sit roughly between 9 and 17 EUR a month, and what they buy is a number of monitors rather than a number of sites.
UptimeRobot asks 9 EUR a month for 10 monitors, and gives 50 away at a five minute interval on its free tier. StatusCake starts at 16.66 EUR a month billed annually. Pingdom starts at 14.33 EUR for 10 uptime checks and one advanced check, with a trial instead of a free plan. Better Stack bills 50 extra monitors at 25 USD a month on top of the plan. Site24x7 and Hyperping both set the count by tier, from 25 to 2,500 and from 20 to 1,000.
Ours is 9.90 EUR a month and does not count monitors, which answers the paragraph above rather than undercutting it. The engine is free forever and is not a trial: it is the same code, under the MIT licence, with the same checks.
What the hosted plan includes, and what it deliberately does not
How to test a tool before you trust it
Break something on purpose on a copy you own, then read the alert that arrives. Until you have done that, everything on a pricing page is a claim, including ours.
- Rename the theme stylesheet on a staging copy. The page still answers 200 and is unreadable. Most tools will say nothing at all, and that silence is the single most useful thing you will learn during a trial.
- Point a check at a page that prints a database error inside otherwise valid HTML. Same test, different failure: the status code is fine, the page is not.
- Let a scheduled task miss its window on purpose and see how long it takes before anyone hears about it.
- Set the certificate warning window and check that you are warned days ahead rather than on the morning it expires.
- Read one alert as if it were seven in the morning and you had four clients. Does it name a cause, or does it say "down" and leave the diagnosis to you?
- Price the tier you would actually end up on, with every site and every certificate and every heartbeat counted, not the entry tier on the pricing page.
Steps one and two take about two minutes each on our demo instance, which is wiped on the hour and never sends a message to anyone.
Questions a comparison rarely answers
How often should a monitoring tool check a site?
The interval is your worst case delay before anyone knows, so pick it against what an hour of silence costs on that site. One minute for a shop taking orders, five minutes for a brochure site, and remember that the real alert delay is the interval plus the confirmation pass most tools run before they wake you. Checking every thirty seconds mainly buys you more false alarms on a flaky network.
What is the difference between uptime monitoring and website monitoring?
Uptime monitoring answers whether the server replied, and reports it as a percentage. Website monitoring covers what the reply contained: the certificate, the layout, an error message printed inside a valid page, a noindex. A site can hold 99.99 percent uptime for a month while its checkout has been broken the whole time, and both numbers are correct.
Is a free website monitoring tool enough?
For a handful of sites where a status code is genuinely the answer you need, yes, and UptimeRobot gives away 50 monitors at a five minute interval. Free tiers usually cap the interval, count monitors rather than sites, and put certificate expiry and cron heartbeats on the paid plans. The moment you are answering to someone else for a site, the thing you outgrow first is not the monitor count, it is the alert that says nothing but "down".
Can one tool monitor sites hosted in different places?
Yes, and it is the normal case. These checks are made over HTTP from outside, so the host, the stack and the country make no difference: what the tool needs is the URL. The one exception is the cron heartbeat, which needs a line added to the scheduled task on each server, because silence is what it measures.
Does a monitoring tool need access to my server or my admin account?
No, and it should not ask. Everything on this page is read from the public response: the HTML, the response headers, the certificate chain, the stylesheets and scripts the page itself references. No plugin, no FTP, no WordPress account. A tool that asks for credentials to watch a public page is asking for more than the job needs.
What happens if the monitoring tool itself goes down?
Nothing warns you that nothing warned you, which is the quiet failure of this whole category. Two consequences worth acting on: never install a self-hosted monitor on the machine it watches, because a server takes its own alerting down with it, and before signing with a hosted one, read its public status page history rather than its marketing.
Try the two tests nobody passes
Take a site you own, break its stylesheet, and see which of your candidates says anything at all. Our demo instance is wiped on the hour, or install the engine yourself and read the code that runs the checks.