What Is Uptime Monitoring?
Uptime monitoring is the practice of continuously checking a website, API, or service from outside your own infrastructure to verify it is reachable and responding correctly, and alerting a human the moment it isn't. A monitoring service sends requests to your endpoints on a fixed interval — typically every 30 seconds to 5 minutes — from servers in one or more geographic regions. Each check records whether the endpoint answered, how long it took, and whether the response looked healthy. When checks fail, the monitor opens an incident and notifies you by email, Slack, webhook, SMS, or an escalating combination of them. That's the whole idea: an independent observer that notices your service is down before your customers tell you.
Why You Can't Rely on Self-Reporting
The fundamental problem with monitoring your own service from inside your own infrastructure is that whatever kills your service tends to kill the monitor with it. A crashed server can't email you to say it crashed. A saturated database takes down both your app and the health dashboard that reads from it. A DNS misconfiguration makes your service unreachable to the world while every internal check — which never leaves your network — stays green. External uptime monitoring works precisely because it shares no fate with what it watches: the checks originate from someone else's servers, traverse the public internet, resolve your DNS the way a real user's browser would, complete a real TLS handshake, and see exactly what your users see. If a layer between the internet and your application breaks, an outside-in check catches it; an inside-out check often can't.
The Check Types That Matter
The word 'uptime' hides a lot of different failure modes. A mature monitoring setup uses several check types, each aimed at a distinct way services break. FourSight ships eight; most serious monitors offer some variation of this list.
| Check type | What it verifies | What it catches |
|---|---|---|
| HTTP(S) | Endpoint returns an expected status code | Crashes, 5xx errors, timeouts, bad deploys |
| Keyword | Response body contains (or lacks) specific text | 200-with-error-page failures, stale content, hijacked pages |
| Ping (ICMP) | Host is reachable at the network layer | Server down, network partition, routing failure |
| Port | A specific TCP port accepts connections | Database, SMTP, or custom service listener down |
| SSL certificate | Certificate validity, chain, and days to expiry | Silent renewal failures before browsers hard-fail |
| DNS | Records resolve to the expected values | Propagation problems, hijacking, misconfiguration |
| Domain expiry | Days until domain registration lapses | The outage that takes weeks to recover from |
| Heartbeat (cron) | Your job actively pings the monitor on schedule | Cron jobs, workers, and pipelines that silently stop |
Check Intervals: How Often Is Often Enough?
Check frequency determines how long an outage can run before anyone knows about it, and it puts a hard ceiling on how precisely you can measure uptime. A 5-minute interval samples your service 288 times a day — fine for a personal site, but it means an outage can burn through 4 minutes and 59 seconds before the first failed check, and your measured uptime can't meaningfully distinguish 99.9% from 99.5%. A 30-second interval samples 2,880 times a day and typically detects an outage within a minute. The right answer depends on what a minute of downtime costs you: hobby projects are fine at 5 minutes, revenue-critical endpoints deserve 30 or 60 seconds, and anything backing a contractual SLA needs a check resolution finer than the SLA it's supposed to prove.
Related Reading
Regions and Consensus: Where False Positives Come From
A single monitoring server cannot tell the difference between 'your site is down' and 'the path between me and your site hiccuped.' Packet loss at the probe's data center, an upstream ISP issue, a DNS resolver blip — all of these look identical to a real outage from one vantage point, and they are the source of most false 3 AM pages. Multi-region monitoring fixes this structurally rather than statistically: checks run from several geographic regions in parallel, and an incident opens only when a quorum of regions independently agrees the endpoint is failing.
How Quorum Consensus Works
FourSight checks every monitor from four regions. When one region reports a failure, that result is held as suspicion, not fact — the system weighs it against what the other regions saw in the same window. Only when a majority of regions concur does an incident open and alerting begin. A transient network problem near one probe never reaches your phone, because the other three regions keep reporting success. The trade-off is a few extra seconds of confirmation time in exchange for eliminating an entire class of false alarms — a trade almost every on-call engineer takes gladly.
What a Single-Region Failure Actually Means
When one region persistently fails while three pass, that's information, not noise: users in that geography may be experiencing a CDN edge problem, a regional DNS issue, or a routing fault that a full-outage alert would mislabel. Good monitoring surfaces this as a regional degradation distinct from a global outage, so you can respond proportionately — check your CDN provider's status for that region rather than rolling back your last deploy in a panic.
Related Reading
Monitoring a Commercial SaaS?
FourSight's free plan includes 10 commercial-safe monitors with multi-region validation — free forever, no card.
Start Monitoring FreeAlerting and Escalation: The Half That Actually Matters
Detection without a reliable path to a human is just logging. The alerting half of uptime monitoring decides who hears about a failure, through which channel, and what happens if they don't respond. The baseline is channel routing: email for low-urgency notices, Slack or a webhook for team visibility, SMS or a phone call for revenue-critical failures. On top of that sit escalation policies — if the primary on-call doesn't acknowledge within, say, 10 minutes, the alert moves to the secondary, then to a lead. The failure mode to design against is alert fatigue: a monitor that cries wolf trains its humans to ignore it, which is strictly worse than no monitor at all. Quorum consensus, confirmation thresholds, and maintenance windows exist to keep the signal-to-noise ratio high enough that every page demands action.
Related Reading
Status Pages: Monitoring's Public Face
A status page turns your private monitoring data into a public trust asset. It answers the question every customer asks during an incident — 'is it them or is it me?' — before they open a support ticket, and it gives prospects evaluating your service verifiable evidence that you measure what you ship. The strongest setups drive the status page directly from monitor state: when a quorum of regions confirms an outage, the affected component flips automatically and subscribers get notified, with no human in the loop who has to remember to update a page mid-crisis. If you operate anything commercial, a status page is the cheapest credibility you will ever buy.
Related Reading
The Uptime Math: What 99.9% Actually Allows
Uptime percentages compress a lot of reality into one number, and the difference between two decimal places is bigger than it looks. Each additional nine cuts the allowable downtime by a factor of ten. Knowing the budget behind each tier keeps both your promises and your monitoring honest — there is no point committing to 99.95% on a 5-minute check interval that can't even see a 4-minute outage.
Tier Yearly downtime Monthly downtime Daily downtime
99.0% 3d 15h 36m 7h 18m 14m 24s
99.5% 1d 19h 48m 3h 39m 7m 12s
99.9% 8h 45m 36s 43m 49s 1m 26s
99.95% 4h 22m 48s 21m 54s 43s
99.99% 52m 33s 4m 22s 8.6sWhen You Don't Need a Paid Monitor
Honesty from a company that sells monitoring: plenty of situations genuinely don't need a paid uptime monitor, and pretending otherwise would insult your intelligence. If you're monitoring a homelab, a personal blog, or a side project with no revenue and no users depending on it, a self-hosted Uptime Kuma instance on a spare VPS is excellent software at a price of $0 — its single-vantage-point limitation matters far less when nobody is paying you for uptime. If your only problem is knowing whether cron jobs ran, Healthchecks.io's free tier is famously generous. Free tiers of hosted monitors also work for personal projects — just read the terms first, since some (notably UptimeRobot's, per its announced 2025 policy) restrict free plans to non-commercial use. The line where paid monitoring earns its keep is predictable: money changes hands, clients depend on you, an SLA exists, or an alert needs to reliably wake a specific human. At that point false-positive resistance, escalation, and status pages stop being luxuries.
How FourSight Approaches Uptime Monitoring
Since we've walked you through the concepts, here's where we sit in the landscape, stated factually. FourSight runs every check from four regions and opens incidents only on quorum consensus — false-positive resistance is the core design decision. It covers all eight check types described above, from HTTP through heartbeat. Pricing is flat and public: the Free plan is $0 forever with 10 monitors, 4-region validation, email alerts, and a status page, and it explicitly permits commercial use — client sites and revenue-generating apps included. Paid plans are Starter at $16/mo (50 monitors, 1-minute checks), Growth at $40/mo (100 monitors, all 8 check types, 30-second checks, escalation policies), Pro at $80/mo (250 monitors, SMS alerts), and Scale at $160/mo (500+ monitors, white-label status pages). If the concepts in this guide describe problems you have, that's the shape of our answer to them.