Multi-Location Website Availability Monitoring
HostTracker's multi-location website availability monitoring is a comprehensive service that checks your website around the clock from 300+ locations around the globe at specific intervals.
Key takeaways
- HostTracker checks a website or server from more than 300 monitoring locations worldwide, on an interval you set - as often as once a minute on the higher plans.
- A failed check is repeated from other locations before anything is sent, and a quorum of those rechecks (a majority by default) decides whether the monitor is really down.
- Alerts go out by email, SMS, voice call, Slack, Microsoft Teams, PagerDuty, Telegram, Discord, Viber, browser push and signed webhooks, with a per-contact delay chosen from 0, 3, 5, 15, 30 and 60 minutes, or 3, 6, 12 and 24 hours.
- Fourteen monitor types share the same alerting, reporting, status pages and REST API, so a website check and a database check raise alerts the same way.
- Paid plans start at $14 per month for Webmaster (10 monitors at a 5-minute interval). The 30-day trial covers 100 monitors and needs no credit card, and a free plan afterwards keeps 2 monitors at a 30-minute interval.
One dashboard, every check type, 300+ locations
Every check runs from HostTracker's global network and is re-verified from several independent locations before an alert is sent - so you catch real outages, not one server's network blip.
HTTPS Check
HostTracker's HTTPS Check is a robust tool designed for 24x7 monitoring of website accessibility. It simulates real customer interactions and performs checks from various global locations. This ensures that your website is always accessible to your users, providing a seamless online experience.
Ping
The Ping check sends ICMP echo requests to your host from HostTracker's 300+ locations and records reachability, round-trip latency and packet loss at each one. Because it works at the network layer, it shows that a machine is unreachable or dropping packets - often before an HTTP check fails. Comparing the locations separates a host that is genuinely offline from a routing problem in a single region.
SMTP
The SMTP check connects to your mail server on port 25, 465 or 587, waits for the greeting banner and completes the handshake, so you know that mail can still be delivered. A website that answers 200 OK says nothing about the mail service behind it, and mail outages usually surface only when customers report missing messages. Running the check from several locations also shows when your mail server is reachable from some networks but not others.
Content Monitoring
Content Monitoring fetches the page and verifies that the text or markup you expect is present - or that a phrase you never want to see is absent. A server can return 200 OK while serving a broken deployment, a defaced page or an injected script, and an availability check alone would count that as a success. Inspecting the response body catches those silent failures and reports them as downtime.
TCP Port
The TCP Port check opens a connection to any port on any host - a database, game server, VPN endpoint, SSH daemon or internal API - and reports whether the port accepts connections and how long the handshake takes. It covers the services behind your website that a browser-level check never touches. Run from several locations, it also reveals when a firewall or routing rule blocks the port for some networks only.
Uptime reports & alerts
Get periodic uptime reports and instant alerts across SMS, email, voice call, Telegram, Slack and more - with escalation rules so the right person is notified when your site goes down.
All 14 check types, run from the same network
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.
| Check type | What a passing check proves |
|---|---|
| HTTP(S) | A real visitor request returns the status, headers and timing you expect |
| API | An endpoint answers with the right status, content type and values inside the payload |
| Ping | The host answers ICMP, with its latency and packet loss recorded per location |
| Port (TCP) | A specific port on a specific host accepts a connection and completes the handshake |
| Transaction | A multi-step journey - log in, search, check out - still completes in a real browser |
| Page speed | The full page loads within your budget, broken down resource by resource |
| Content | The text or markup you require is present, and the phrase you never want to see is absent |
| Database query | A query against your database returns, in time, and returns what it should |
| Performance counter | CPU, RAM, disk or a custom counter stays under the threshold you set |
| SNMP | A network device reports an OID value inside the range you accept |
| Domain expiry | The registration still has runway, read live over RDAP rather than from a cache |
| SSL/TLS expiry | The certificate is valid and not about to lapse over a weekend |
| Blacklist (DNSBL) | Your IP or domain is absent from the blocklists that decide whether your mail arrives |
| Web Risk | Your site is not flagged by Google's Web Risk database as malware or phishing |
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.
What global uptime monitoring is - and why one location lies
Global uptime monitoring means testing a site's availability from many independent vantage points at once, and treating the agreement between them - not any single result - as the verdict. A single vantage point reports one machine's view of one network path.
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.
Multi-location checking answers all three the same way: ask several unrelated places, then compare. For that comparison once, right now, use the website down checker.
How HostTracker checks your site from 300+ locations
- 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.
- 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.
- 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.
- 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:
| Location group | Identifier | Location group | Identifier |
|---|---|---|---|
| Western Europe | westeurope | Africa | africa |
| Eastern Europe | easteurope | Ukraine | ukraine |
| North America | northamerica | Russia | russia |
| South America | southamerica | Iran | iran |
| Asia | asia | Everywhere | allworld |
| Australia | australia |
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.
How we kill false alarms: the re-verification protocol
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:
- 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.
- 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.
- 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.
- 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.
- 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.
- If nothing countable came back, nobody is woken. The session ends with no verdict and the base check is retried later.
What this is worth, in numbers. The figure that matters is the share of single-location failures a second independent location never reproduces - the alerts this protocol removes before they reach a human. We publish it with its measurement window and sample size rather than as a slogan.
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.
Regional and ISP-level outages you only see from multiple locations
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:
| Location | First failure | What it saw | Verdict |
|---|---|---|---|
| London, UK | - | 200 OK, 11 ms | Up |
| Frankfurt, DE | - | 200 OK, 9 ms | Up |
| New York, US | 14:02:11 | Connection timed out | Down |
| Toronto, CA | 14:02:19 | Connection timed out | Down |
| Singapore, SG | - | 200 OK, 14 ms | Up |
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.
Alerts, escalation and who gets woken up
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.
Recovery notices follow the same ladder. A contact whose delay never came due during a short outage was deliberately never told about the down, so it is not told about the recovery either. Nobody gets a 3 a.m. "resolved" message about an incident they slept through.
Uptime reports, SLA evidence and dispute-ready logs
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.
Public status pages your users can watch
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.
Try it before you sign up: free instant checks
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.
API, CLI and AI-agent access
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.
Plans, limits and what the free plan covers
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.
| Free plan | 30-day trial | Paid plans | |
|---|---|---|---|
| Cost | Free, permanently | Free, no credit card | From $14 per month |
| Monitors | A starter allowance | Up to 100 | Scales with the plan |
| Locations | The full 300+ fleet | The full 300+ fleet | The full 300+ fleet |
| Status pages | Included | Included | Included, custom domain on Enterprise |
| REST API, SDKs, CLI, MCP | No | Yes | Yes, Business and above |
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.
How HostTracker compares on locations and check types
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.
| HostTracker | UptimeRobot | StatusCake | Site24x7 | |
|---|---|---|---|---|
| Published locations | 300+ | 4 broad regions | 43 across 30 countries | 32 on the entry uptime plan |
| Monitor types | 14 | 6 | Uptime, page speed, domain, SSL, blacklist | Broad, split across add-on SKUs |
| Documented multi-location confirmation | Yes, configurable per monitor | Not published | Not published | Not published |
| Free plan | Yes, small allowance | Yes, more generous on monitor count | Yes | Yes, limited resources |
| Status pages | Included on every plan | Included | A separately priced product | Included |
| Official SDKs, CLI, MCP | All three | CLI and hosted MCP, no official SDKs | Go SDK official, others alpha | MCP via the Zoho platform |
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.
Frequently Asked Questions
Multi-location website availability monitoring checks whether your site is reachable and responding correctly by testing it from many independent geographic locations around the world, rather than from a single vantage point. HostTracker's availability monitoring runs these checks continuously, around the clock, from its distributed network of monitoring locations, so it can distinguish a real, global outage from a problem that only affects visitors in a specific region or on a specific network. This distinction matters because a single-location check has no way to tell the difference: if it fails, you don't know whether your entire site is down or whether the problem is local to that one testing point. Checking from many locations at once gives a far more accurate picture of what your actual visitors, spread across different countries and networks, are experiencing right now.
A check run from a single location can only tell you about conditions at that one point on the internet - it can't distinguish between your website being genuinely down everywhere and a localized problem like a regional network outage, a routing issue, or a block affecting only that one testing location. Running the same check from many independent locations around the globe solves this by giving you many simultaneous data points instead of one: if every location fails, the outage is real and global; if only a handful fail while the rest succeed, the problem is local to those specific regions or networks rather than your site being fully offline. This distinction directly affects how urgently you need to respond, which is why distributed, multi-location checking is significantly more reliable than testing from a single server or your own browser.
Yes, this happens more often than most site owners expect. Regional network issues, ISP-level routing problems, a block on a specific IP range, or a CDN edge node having trouble in one area can all make a website unreachable from a particular country or network while it continues to load normally everywhere else. From the perspective of a single-location monitoring tool or a website owner testing from their own connection, this kind of partial, regional failure is invisible unless it happens to affect their specific location. Distributed monitoring checks from many locations simultaneously, so a regional problem shows up clearly as a subset of locations failing while the rest succeed, letting you identify a geographically limited issue instead of either missing it entirely or mistakenly treating it as a full outage.
HostTracker's distributed availability monitoring covers multiple check types run from its global network of locations, including HTTP/S checks that simulate real visitor requests to your website, TCP port checks for verifying that specific network services are reachable, and content checks that confirm a page returns the expected data rather than just any response. Running these checks from many locations at once, rather than from a single server, ensures that the availability picture reflects what real users in different regions actually experience, not just conditions local to one testing point. Combined with automatic alerts and periodic uptime reports, this gives a fuller view of availability than a single-location check could provide on its own, covering both whether your infrastructure responds and whether it responds correctly to visitors around the world.
A check run from just one location can be tripped up by a problem that has nothing to do with your website - a momentary network blip near the testing server, a temporary routing issue, or a block specific to that one location - and mistakenly report your entire site as down. Multi-location monitoring reduces this risk by re-testing from several independent locations before treating a failure as confirmed: if only one or two locations report a problem while the rest succeed, it's treated as a local anomaly rather than a real outage, and no unnecessary alert is sent. Only when a meaningful number of independent locations agree that your site is unreachable does the system treat it as a genuine outage worth notifying you about, so the alerts you do receive are far more likely to reflect an actual problem.
HostTracker checks websites from a network of 300+ monitoring locations spread around the world, which is what makes it possible to distinguish a genuine global outage from a problem limited to a specific region or network. This scale matters for accuracy: the more independent locations a check runs from, the more confidently you can tell whether a failure is truly widespread or confined to one area, and the less likely a single location's local network issue is to trigger a false alarm. HostTracker has operated this distributed monitoring network since 2004 and currently monitors 500,000+ websites, giving it a long operational track record for reliably detecting both full outages and the more subtle, regional availability problems that single-location tools are structurally unable to see.
A failing check pauses ten seconds, then re-runs across up to seven independent locations launched two seconds apart, so a confirmed verdict typically lands within roughly half a minute of the first failure. Contacts then alert on their own chosen delay - immediately, or after 3, 5, 15, 30 or 60 minutes of continuous failure, or after 3, 6, 12 or 24 hours.
Yes. Monitors are pointed at named location groups - Western Europe, Eastern Europe, North America, South America, Asia, Australia, Africa, plus country-scoped groups - and a new monitor starts on Western Europe, Eastern Europe and North America. Groups also subtract, so you can run everywhere except one country whose national routing you do not want deciding your alerts.
Monitor your website from 300+ locations
Start a free trial and get instant alerts when your site goes down - verified from multiple locations before you're notified.
Part of HostTracker's website monitoring service.