Website availability monitoring from 300+ locations worldwide

The six cards above are where most accounts start. The full catalogue is fourteen monitor types, all sharing this location fleet, this confirmation protocol and this alert routing - you do not run one tool for uptime and a second for certificates.

The network checks run from the public 300+ location fleet. The infrastructure checks - database query, performance counter and SNMP - run through dedicated agents instead, because what they need is credentials and reach into your network rather than geography.

That matters because the commonest reasons a check "fails" have nothing to do with your server:

• The path broke, not the site. A transit provider reroutes badly for ninety seconds while every other network still reaches you.
• The site broke, but only for some people. A CDN edge serves stale errors in one region, or a firewall rule blocks a country - and a vantage point in the wrong place calls that "all good".
• The probe broke. Without a second opinion, a bad node and a bad site look identical.

Distributed monitoring answers all three the same way: ask several unrelated places, then compare. For that comparison once, right now, use the website down checker.

1. The monitor comes due. Intervals run from one minute to 24 hours, defaulting to three, and due work is claimed continuously rather than in batch windows.
2. A location is picked from the groups you chose. You select groups, not machines, so a check rotates across the group instead of pinning to one box.
3. The check runs. The location performs the real request - HTTP fetch, ICMP ping, TCP handshake, browser page load - and returns the outcome, the timing breakdown and, where it applies, the response body.
4. A state change starts a confirmation, not an alert. Only a confirmed change opens or closes a downtime episode.

The groups a monitor can be pointed at are named and selectable in the interface and in the API:

A new monitor starts on Western Europe, Eastern Europe and North America. Groups combine and they subtract: allworld with -russia means "everywhere except Russia", which is how you keep one country's national routing out of your alerting.

A single failing check never sends an alert. When a result disagrees with the monitor's current state, HostTracker opens a confirmation session and holds the alert until other locations answer:

1. Wait ten seconds. A target that just flipped is the last thing that needs a burst of extra traffic, and many blips are over before second ten.
2. Fan the re-check out. Up to seven locations are drawn from a shuffled pool and launched two seconds apart, so the re-checks are spread in time as well as geography. If too few trusted locations are free, the quorum is topped up to a minimum of three.
3. Sort the answers before counting them. A location that could not run the check does not count and is not penalised. One that returns junk does not count either, is marked, and a replacement is dispatched.
4. Apply the agreement rule. By default the majority decides. Per monitor you can require at least a set number of locations to report down, require full agreement in both directions, or require full agreement for a down while recoveries confirm on a majority.
5. Score the locations against the verdict. A location that keeps disagreeing picks up a distrust strike with a countdown, is skipped while it runs, and earns its way back as the countdown decays. That is how a flapping node retires itself.
6. If nothing countable came back, nobody is woken. The session ends with no verdict and the base check is retried later.

It also has an off switch: a check whose result is definitive on its own - a database query either returned the row or it did not - skips confirmation entirely.

The strongest argument for multi-location monitoring is not the outage everyone notices, but the one only some people notice. Up in Europe, gone in North America looks like this:

Illustrative, but the shape a real per-location result carries. The default majority rule does not call that a global outage, because it is not one. What it does is record which locations failed, at what second, with which error - timestamped evidence gathered from outside your provider's network, which is what makes it usable in a support ticket.

To be paged for a regional failure rather than only have it logged: set the confirmation rule to "at least this many locations report down", or run a second monitor pinned to that region, where the failure is the majority. Troubleshooting a host right now instead? A global ping test shows this picture in one click.

Alerting is driven by each contact's own delay, not one global rule. Every contact picks when it wants to hear about an outage: immediately, or after 3, 5, 15, 30 or 60 minutes of continuous failure, or after 3, 6, 12 or 24 hours. That ladder turns a contact list into an escalation policy without a separate on-call product - minute 0 to the team channel, minute 5 to the on-call engineer's phone, minute 30 to the engineering lead, hour 3 to the account owner.

Channels for any rung: email, SMS, voice call, browser push, Slack, Telegram, Discord, Viber and signed webhooks - the webhook being how alerts reach an incident manager, a ticketing system or any internal tool with an inbound URL.

Monitoring that only alerts is half a product. The other half is the record it leaves - what you use in a hosting dispute, an SLA credit claim or a post-incident review.

• Per-location check results with status, response time and error text, kept as history rather than only as a current state.
• Downtime episodes with a confirmed start, a confirmed end and the confirmation trail behind both.
• Scheduled uptime reports emailed on the cadence you set.
• An SLA export and an uptime badge published straight from a status page.
• Maintenance windows, so planned work does not contaminate the availability figure you later have to defend.

External evidence carries weight precisely because it is external: a provider can dismiss your own server logs, but a timestamped record of failures seen from several independent networks, none of them yours, is harder to argue with.

The fastest way to cut support volume during an incident is to stop making people ask. A status page turns monitors you already run into public components, updates them from the same confirmed results that drive your alerts, and is hosted for you at its own address - no extra hosting, no DNS work. Incidents and maintenance windows post to it, and visitors can subscribe.

Status pages are included on every plan, the free one included; publishing under your own domain is an Enterprise option. HostTracker runs its own on the same machinery - status.host-tracker.com is a live example - and the status pages overview covers the rest.

Every claim on this page is testable without an account, because the free instant tools run on the same fleet as the paid monitors. Point one at a site you know is healthy, then at one you know is not, and read the per-location results yourself.

• Free HTTP check from multiple locations - status code, response time and headers per location.
• Run a global ping test - reachability, latency and packet loss at the network layer, where routing problems show up first.
• Website down checker - the "is it just me" question answered from many places at once.

There are eleven of these free tools, each the manual version of a monitor type you can later put on a schedule.

Locations are a first-class parameter, not a setting buried in a form. Running a check from named regions over REST:

curl -X POST https://api2.host-tracker.com/check \
  -H "Authorization: Bearer $HT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com", "type": "http", "pools": ["westeurope", "asia"]}'

The identifiers from the region table go in pools, and the same values work when you create a scheduled monitor. Around that REST surface sit official libraries for TypeScript, Python, Go and .NET, the ht command-line client, a GitHub Action, and an MCP server so an AI assistant can create monitors and read results directly - all generated from one OpenAPI document. See the monitoring API overview, the command-line client or the MCP server.

Three ways to run the network, and the fleet is the same in all of them - the free plan is not checked from fewer places than the paid ones.

The trial is the honest way to evaluate this: 30 days, a hundred monitors, no card - enough to run HostTracker beside whatever you use today and compare the alerts the two actually sent. Full limits per tier: HostTracker website monitoring plans.

Only columns that can be checked against a published page. Drawn from each vendor's own pricing and documentation, August 2026 - verify anything a decision depends on.

Where we are not ahead the table says so: UptimeRobot's free plan carries more monitors than ours, and their hosted MCP server shipped with OAuth before ours did. The reasons to pick this network are the first three rows. Fuller breakdown: how HostTracker compares to UptimeRobot.

Network, protocol and plan details on this page last reviewed 30 August 2026. HostTracker has operated this distributed monitoring network since 2004.