Uptime monitoring for
websites, APIs and servers
Probe any endpoint every minute from 9 regions across 6 continents. Cover HTTP, TCP, UDP, SSL and DNS from one dashboard, with alerts on the channels your team already uses.
What is uptime monitoring?
Uptime monitoring is the practice of probing a service from outside its own infrastructure on a fixed interval and recording whether it responds correctly. A monitor sends a request — an HTTP GET, a TCP handshake, a DNS query, a TLS connection — from one or more remote regions, then compares the response to a set of expectations: status code, latency budget, response body, certificate validity, record value.
When the response fails to match, the monitor opens an incident and alerts the on-call team through their preferred channel. Over time, the same probes feed an uptime percentage, per-region latency history and the data you need to defend an SLA. Done well, it is the single shortest path from "something just broke" to "the right person knows about it."
Status Harbor runs that probe loop for you, every minute, from 9 regions, across 5 protocols.
Protocols we monitor
One dashboard for the five protocols that cover almost everything a developer ships.
| Protocol | Typical use | What we check |
|---|---|---|
| HTTP / HTTPS | Websites, REST APIs, GraphQL endpoints, health-check URLs | Status code, response time, response body match, headers |
| TCP | Databases, message brokers, raw socket services, custom protocols | Connect success, handshake latency |
| UDP | Game servers, VoIP, DNS resolvers, custom UDP services | Packet send / response, round-trip time |
| SSL | TLS certificate health on any HTTPS endpoint | Days to expiry, chain validity, hostname mismatch |
| DNS | A, AAAA, CNAME, MX, TXT records on your authoritative or any resolver | Record value match, propagation, resolver latency |
9 regions across 6 continents
Run checks from one region, a handful or all of them. Multi-region coverage rules out single-network blips before an alert ever fires.
- United States — us-east
- Germany — eu-west
- Sweden — eu-north
- Singapore — ap-southeast
- Japan — as-east
- UAE — me-west
- South Africa — af-south
- Brazil — sa-east
- Australia — oc-southeast
Alerts where your team already lives — in two clicks
Most monitoring tools ask you to copy a webhook URL, paste a bot token or register an OAuth app before the first alert can land. Status Harbor does not.
Slack
- Click Add to Slack in Status Harbor.
- Pick the channel that should receive alerts.
- That is it. The bot is in the channel and the next failed check will post there.
Telegram
- Tap the Telegram bot link from Status Harbor.
- Press /start in the chat.
- Connected. Personal alerts arrive in DMs; group alerts work the same way after adding the bot to a group.
Email, WhatsApp and webhook integrations work the same way — pick the channel, confirm, done. Each monitor can route to a different channel, so production noise stays out of staging.
Set up a monitor in under five minutes
From sign-up to first alert, no installation required.
- 1
Create a monitor
Pick the protocol — HTTP, TCP, UDP, SSL or DNS — and paste in the endpoint, hostname or record you want to watch.
- 2
Choose your regions
Run from one region, several or all 9. Multi-region coverage rules out single-network blips before an alert ever fires.
- 3
Connect an alert channel
Slack, Telegram, email, WhatsApp or your own webhook. Route production and staging to different channels per monitor.
- 4
Sleep better
Status Harbor probes every minute and only pings you when something is actually wrong.
Common questions
How does uptime monitoring work?
A monitoring service sends a request from a remote region to your endpoint on a fixed interval. The request is the same one a real client would make: an HTTP GET, a TCP connect, a DNS query, a TLS handshake. The response is then compared against a set of rules — status code, latency, response body, certificate validity. When the response fails the rules from at least one region, the service opens an incident and alerts the team. When checks recover, the incident closes automatically.
What is the difference between HTTP and TCP monitoring?
HTTP monitoring speaks the application protocol: it issues a real request, waits for a response and inspects status code, headers and body. It catches everything from network outages to a misconfigured 500 from a single bad deploy. TCP monitoring stops one layer lower — it confirms the port is open and the handshake completes, without sending any application traffic. Use HTTP for anything that serves HTTP. Use TCP for databases, message queues, SSH or any service where a successful connection is enough proof of life.
What is a good check interval?
For production user-facing services, one minute is the practical floor for most teams. It bounds maximum detection time at 60 seconds and gives multi-region confirmation before an alert fires, which keeps false-positive rates low. Five-minute intervals are fine for non-critical internal services or staging, where alert noise costs more than detection lag. Status Harbor supports 1-minute checks on every paid plan; lower intervals are available for higher-tier plans.
How fast should uptime alerts arrive?
The honest answer is "slower than you think." Detection time equals one full check interval, plus the time it takes to confirm the failure from a second region to suppress single-network blips, plus delivery latency on the alert channel. With 1-minute checks and two-region confirmation, expect end-to-end alert latency in the 60-90 second range on Slack and Telegram and a few seconds longer on email. Faster than that usually means trading off false-positive rate.
Why monitor from multiple regions?
Single-region monitoring tells you "the service is unreachable from this one network path." That conflates real outages with transit issues, BGP route flaps and regional CDN problems that your users in other regions never see. Multi-region monitoring lets you separate "the service is down" from "the service is down for some users" — and lets you alert differently on each. A real outage trips every region; a regional path issue trips one.
Start monitoring in minutes
No card required. Set up your first monitor and a public status page in under five minutes.
Start monitoring free