What do you actually need to find out?
Each of these pages answers one question in full, with the file in the engine that does the work. This page only exists to point you at the right one.
The symptom, and the page that answers it
| What happened to you | What is actually going on | Where it is answered |
|---|---|---|
| A client called to tell you their site was down. | You found out last, which is a reporting problem before it is a monitoring problem. The fix is that the client sees the same thing you do, without an account. | Client access |
| The site answers 200 and looks wrong anyway. | Something changed in the page: a string that vanished, an error printed inside a valid response, a layout that lost its stylesheet. A status code cannot see any of it. | Page changes |
| It works on your laptop and fails on a phone. | Almost always a certificate whose intermediate the server never sends. Desktop browsers repair it silently, which is why it reaches production. | Certificate monitoring |
| The API answers 200 and returns an HTML login page. | Valid HTTP, useless JSON, and every check that stops at the code calls it healthy. Reading a field and its value is what tells an integration apart from a transaction. | JSON endpoints |
| An advisory came out and you do not know which client it touches. | The pages already say which versions each site runs, so the question is answerable across the whole estate at once. A published flaw and a version merely behind are never reported with the same word. | Security watch |
| You know the page is slow. You do not know what to remove. | A score never contains the answer, because the answer is a filename. The causes are read out of the page already downloaded, with the weight of each blocking file. | Speed and its causes |
| The site answers 200 and shows a database error. | The web server succeeded, so every check built on status codes calls this healthy. Three readings tell the difference, and the third is the only one a page cache cannot cover for. | Database down |
| The backup has not run for three weeks and nothing said so. | Nothing could: a job that stops being scheduled produces no request and no error, so every check built on asking a server a question is blind to it. The test has to be inverted. | Cron monitoring |
| You cannot decide between installing it and paying for it. | Nothing is held back in the free version, so it is not a feature question. Three things self-hosting genuinely does better, and the one arrangement to avoid whichever you pick. | Hosted or self-hosted |
| The site that keeps breaking is a WordPress. | Then the failure has a known shape rather than an unknown one: its own database error is served with a 200, in six wordings the body is matched against, and the API is watched because a page cache cannot answer it. | WordPress, no plugin |
| You just want a date, right now, on one name. | Then you do not need any of the above. The free tools answer in one second, no account, and they say what the answer hides. | SSL certificate checker |
These are not three products
Every reading above happens on the same pass, on the same check, at the same interval. There is no certificate add-on and no reporting tier: a site you monitor is read once, and everything on this page is part of that one reading. It is also why the price does not depend on how many of these you use.
What separates monitoring tools, and how to test one goes through the whole pass in order, and the pricing page says what you pay for and what you do not.
Coming from a tool you already pay for? The seven usual suspects in one table, including the rows where they win.
One check, read properly
Unlimited monitors, one price, and the same engine whether we run it or you install it yourself.