Website monitoring software, from a single uptime check to a whole user journey

Website monitoring software is a set of machines outside your infrastructure that open your site on a schedule, on your behalf, and tell you the moment the answer stops being the one you expect. That is the entire idea. Everything else on this page is a detail about what counts as the answer: a status code, a piece of text on the page, a response time, a JSON field, a certificate expiry date, a CPU reading, or the outcome of a five-step checkout.

The reason it has to run from outside is that the failures you most need to hear about are invisible from inside. A server whose disk is full still reports itself healthy to its own dashboard. A DNS record that points at a decommissioned address resolves perfectly well from the office where the cache is warm. A certificate that expired at 2am breaks every browser on earth while your own load balancer keeps answering. External uptime monitoring is what closes that gap, because it sees exactly what a visitor sees.

The second reason is evidence. When your host tells you the outage lasted four minutes and your customers tell you it lasted an hour, an independent record of every check, from every location, with timestamps, settles the argument. That record is also what a monthly uptime report and a public status page are built from.

1. Step 1CheckA checkpoint runs your check at the interval you set, as often as once a minute, from the locations you picked.
2. Step 2ConfirmA failure is rechecked from other checkpoints before anything is declared Down, so one bad route is not an outage.
3. Step 3AlertThe contacts subscribed to that monitor are notified on the channels they chose, and again when it recovers.
4. Step 4RecordEvery result is kept with its location and timing, feeding uptime figures, incident history and reports.

The server stops answering. The obvious failure, and still the most common one: the site times out, or returns an error page that nobody sees until a customer calls. Uptime monitoring runs an HTTP or HTTPS request against your address as often as once a minute from 300+ checkpoints, confirms the failure from other locations before it calls anything Down, and alerts the people subscribed to that monitor.

The certificate expires. A certificate that lapses at 2am breaks every browser on earth while the server itself keeps answering perfectly, so nothing in your own logs looks wrong. SSL certificate monitoring tracks the expiry date, the chain of trust and the hostname on the certificate, and warns you weeks ahead instead of at the moment it stops working.

The domain lapses. The renewal notice went to an address nobody reads any more, or a name-server record was changed by someone who no longer works here. Domain expiration monitoring watches the registration date and the DNS answers behind it, so an expiring domain is something you are told about rather than something you discover.

The domain gets blacklisted. A shared hosting IP, a compromised account or a misconfigured mail server is enough, and the first symptom is usually silence - your email simply stops arriving. Blacklist monitoring checks your domain and your IP address against dozens of blacklists on a schedule and tells you the day a listing appears.

The site gets flagged as malware. A compromised plugin starts serving something Google does not like, and browsers put a red interstitial in front of your homepage while the site itself is up. Malware monitoring checks your URLs against Google's Web Risk database around the clock, so you hear about the flag from us and not from your traffic graph.

All five run from the same monitor list, on the same contacts and the same bill - which is the point. They are the failures that share one symptom, "the site is fine on my machine", and they are cheapest to watch together.

Availability is the floor, not the ceiling. A site can answer every request with a perfectly healthy 200 while its login form is broken, its search returns nothing, or its API has started sending an empty array where it used to send your product catalogue. These three checks - uptime, synthetic transaction monitoring and API monitoring - cover the whole ladder: the server responds, the journey through it completes, and the machine-readable answers behind it are still correct. Hosts that have no website at all - routers, mail servers, devices - get ping monitoring on the same schedule, from the same checkpoints.

Slow is the outage nobody declares. Pages that take eight seconds do not trigger a downtime alert, they just quietly lose the visitors who were not going to wait, and they do it for weeks before anyone notices. These checks watch the three layers where that usually starts: the page as a real browser loads it, the machine serving it (server monitoring software that needs no agent), and the database it is waiting on.

This group exists because of a specific kind of failure: nothing broke, but the internet stopped trusting you. An expired certificate, a domain nobody renewed, a malware flag from a compromised plugin, or a mail server that landed on a blacklist will each take a perfectly healthy site off the air, and none of them will show up in an availability check that only reads status codes. The same goes for a release that adds a noindex tag or points a canonical at staging: the site stays up while its pages leave search.

Any script can email you the first time a request times out. The hard part of running a monitoring service is not noticing failures, it is being right about them, because a service that pages you at 3am for a routing hiccup gets muted within a month, and a muted monitor protects nothing.

So a failed check is never an alert on its own. HostTracker rechecks the site from other checkpoints first. If one location cannot reach your server while the rest can, that is a network problem between that checkpoint and you, and it is recorded as such instead of escalated. You decide how many confirmations a monitor needs before it flips to Down, and you can raise that number for a site behind a flaky network or lower it for one where every second counts.

Planned work gets the same treatment from the other direction: schedule a maintenance window and the monitor keeps checking and keeps recording, but nobody is woken up for a deployment they already knew about. And because every result carries the location it came from, the alert itself is diagnostic. Down from every checkpoint is a server problem. Down from one country is a routing or CDN problem. Slow from three of the twelve you picked is a capacity problem that has not become an outage yet.

Detection is only half of a monitoring service; the other half is reaching the right person on a channel they will actually answer. HostTracker sends downtime alerts by email, SMS, voice call, Telegram, Slack, Microsoft Teams, PagerDuty, Viber, Discord, Pushover, Pushbullet, Mattermost, web push and webhook, and you can use as many of them at once as you like.

Contacts subscribe per monitor rather than per account, so the developer who owns the checkout flow is not paged about a marketing landing page, and the person who renews domains does not get every HTTP timeout. Channels can be staged as an alert escalation: a Telegram message immediately, then a phone call if the site is still down a few minutes later, then an escalation to a second person. Recovery alerts are sent on the same channels, so an incident always closes explicitly instead of trailing off.

Webhooks are there for the cases none of the above cover. They post the incident to whatever you already run, whether that is PagerDuty, an internal chat bot, a ticket queue, or a script that restarts a service and posts back what it did.

Every check result is kept, which turns a stream of alerts into something you can actually reason about. The dashboard shows the current state of every monitor plus its uptime over any date range you choose; the incident log lists each outage with its start, its duration and the locations that saw it; and scheduled uptime and SLA reports can land in an inbox weekly or monthly without anyone logging in, which is usually what an SLA conversation or a client retainer actually needs.

When your users need the same information, publishing it beats answering it forty times. Build a free public status page from the monitors you already run: live uptime percentages, an incident timeline you can annotate as work progresses, and email or RSS updates for anyone who subscribes. It is the same data your dashboard shows, filtered to what you are willing to make public.

If you already debug with an AI assistant open, the monitoring network can answer it directly. HostTracker's MCP server for AI assistants exposes instant checks over the Model Context Protocol, so Claude, Cursor and other MCP clients can run an HTTP check from Europe and Asia, resolve DNS, look for blacklist listings or trace a route, and read the results back in the same conversation where you are working out what broke.

It uses your own HostTracker API token and the same 300+ checkpoints as everything else on this page. There is no separate dashboard to learn, and nothing to keep in sync, because it is the same service answering.

The same token drives the REST API v2, the official SDKs for TypeScript, Python, Go and .NET and the ht-cli command line client, so monitoring can live in your code, your pipelines and your assistant at once.

Every check type on this page is available on every plan. What the plan decides is scale: how many monitors you run and how often they are allowed to check. That is deliberate, because the difference between a personal blog and an online shop is not which features they need, it is how quickly they need to hear about a problem.

The free plan is permanent and monitors two sites every 30 minutes, which is enough to catch an expired certificate or a site that went down overnight. Paid plans start with Solo at $9 a month, then Webmaster at $14 and Business at $29, with an Enterprise tier for larger fleets. New accounts get a 30-day trial with 100 monitors and one-minute checks, with no credit card required, so you can measure a real month of your own uptime before committing to anything.

The honest way to choose is to work backwards from your check interval. If a five-minute outage costs you nothing, monitor every five minutes and pay less. If it costs you orders, monitor every minute and the plan pays for itself the first time it saves you fifty minutes of unnoticed downtime. Compare all monitoring plans and prices.