---
title: "What Is Uptime Monitoring? The Complete Guide | FourSight"
description: "How uptime monitoring works — check types, multi-region consensus, alerting, and status pages — plus an honest look at when a free monitor is all you need."
lang: en
json-ld: |
  [
    {
      "@context": "https://schema.org",
      "@type": "Article",
      "headline": "What Is Uptime Monitoring? The Complete Guide",
      "description": "How uptime monitoring works — check types, multi-region consensus, alerting, and status pages — plus an honest look at when a free monitor is all you need.",
      "author": {
        "@type": "Organization",
        "name": "FourSight"
      },
      "publisher": {
        "@type": "Organization",
        "name": "FourSight"
      },
      "url": "https://foursight.cloud/guides/what-is-uptime-monitoring",
      "mainEntityOfPage": "https://foursight.cloud/guides/what-is-uptime-monitoring",
      "datePublished": "2026-07-14",
      "dateModified": "2026-07-14",
      "wordCount": 2400
    },
    {
      "@context": "https://schema.org",
      "@type": "BreadcrumbList",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Home",
          "item": "https://foursight.cloud"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "Guides",
          "item": "https://foursight.cloud/guides"
        },
        {
          "@type": "ListItem",
          "position": 3,
          "name": "What Is Uptime Monitoring? The Complete Guide",
          "item": "https://foursight.cloud/guides/what-is-uptime-monitoring"
        }
      ]
    },
    {
      "@context": "https://schema.org",
      "@type": "FAQPage",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "What is uptime monitoring in simple terms?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "It's an external service that repeatedly checks whether your website or API is up — typically every 30 seconds to 5 minutes, from multiple locations — and alerts you the moment it isn't. Because the checks come from outside your infrastructure, they catch failures your own servers can't report, like DNS problems, expired SSL certificates, and total outages."
          }
        },
        {
          "@type": "Question",
          "name": "What's the difference between uptime and availability?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "In practice they're used interchangeably: the percentage of time a service is operational. Strictly, availability is the measured percentage (uptime divided by total time), while 'uptime' often refers to the raw duration. A related but distinct concept is reliability — whether the service responds correctly and quickly, not just at all."
          }
        },
        {
          "@type": "Question",
          "name": "How much does uptime monitoring cost?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Anywhere from $0 to hundreds per month. Self-hosted Uptime Kuma is free plus server costs. Hosted free tiers (including FourSight's, which allows commercial use on $0) cover small setups. Paid plans across the industry generally run $10-100/month depending on monitor count, check frequency, and alerting depth — FourSight's paid tiers are $16, $40, $80, and $160 flat."
          }
        },
        {
          "@type": "Question",
          "name": "What check interval do I actually need?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Match it to the cost of undetected downtime. Personal projects: 5 minutes is fine. Commercial sites: 1 minute. Revenue-critical endpoints and anything backing an SLA: 30 seconds or faster, because your measurement resolution needs to be finer than the uptime number you're claiming."
          }
        },
        {
          "@type": "Question",
          "name": "Do I really need checks from multiple regions?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "If alerts wake a human, yes. A single vantage point can't distinguish your site being down from the monitor's own network having a blip, and that ambiguity is where most false alarms come from. Quorum-based multi-region checks eliminate the false-alarm class structurally — several regions must independently agree before anyone gets paged."
          }
        },
        {
          "@type": "Question",
          "name": "Can uptime monitoring detect problems before users notice?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Often, yes — that's the point of the countdown-style checks. SSL expiry alerts fire 30 days before browsers start blocking. Domain expiry alerts fire before registration lapses. Heartbeat monitors flag a dead backup job the morning after it first fails, not during the disaster recovery you needed it for."
          }
        }
      ]
    }
  ]
---

[FourSight ](/)

[Features](/#features)[Pricing](/pricing)[Guides](/guides)[Glossary](/glossary)[FAQ](/faq)

[Login](/auth)[Start free](/auth?signup=true)

[Start free](/auth?signup=true)

[All Guides](/guides)

Reliability & Infrastructure

# What Is Uptime Monitoring? The Complete Guide

How uptime monitoring works — check types, multi-region consensus, alerting, and status pages — plus an honest look at when a free monitor is all you need.

12 min read Guide Published Jul 14, 2026 

## 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](/glossary/dns "Glossary: 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](/glossary/ssl-tls "Glossary: 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.

**💡** The most underrated entries on this list are the ones that don't check a URL at all. SSL expiry, domain expiry, and dead cron jobs cause some of the most damaging outages precisely because a plain HTTP check stays green right up until the moment everything fails at once.

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

Related Reading

-   [→ Feature: SSL certificate monitoring](/features/ssl-monitoring)
-   [→ Heartbeat monitoring for cron jobs & scheduled tasks](/guides/heartbeat-monitoring-cron-jobs)

## 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](/glossary/sla "Glossary: SLA") needs a check resolution finer than the SLA it's supposed to prove.

Related Reading

-   [→ Uptime SLA reporting for SaaS companies](/guides/uptime-sla-reporting-for-saas)

## 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](/glossary/probe "Glossary: 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](/glossary/multi-region-monitoring "Glossary: 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](/glossary/cdn "Glossary: 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

-   [→ Multi-region monitoring explained](/guides/multi-region-monitoring-explained)

### Monitoring a Commercial SaaS?

FourSight's free plan includes 10 commercial-safe monitors with multi-region validation — free forever, no card.

[Start Monitoring Free](/auth?signup=true)

## Alerting 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

-   [→ Alerting without alert fatigue](/guides/alerting-without-alert-fatigue)
-   [→ Glossary: escalation policy](/glossary/escalation-policy)

## 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

-   [→ Status page best practices for SaaS](/guides/status-page-best-practices)
-   [→ Feature: status pages](/features/status-pages)

## 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.6s
```

## When 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.

Related Reading

-   [→ Best uptime monitoring tools in 2026 — honest roundup](/guides/best-uptime-monitoring-tools)
-   [→ Can you use UptimeRobot for commercial SaaS?](/guides/uptimerobot-commercial-use)

## 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.

[See plans and pricing →](/pricing)

## Frequently Asked Questions

### What is uptime monitoring in simple terms?

### What's the difference between uptime and availability?

### How much does uptime monitoring cost?

### What check interval do I actually need?

### Do I really need checks from multiple regions?

### Can uptime monitoring detect problems before users notice?

#### Related Guides

[Multi-Region Monitoring Explained 8 min ](/guides/multi-region-monitoring-explained)[SSL Certificate Expiry Monitoring 10 min ](/guides/ssl-certificate-expiry-monitoring)[How SSL Certificates Expire Silently: The Failure Modes 8 min ](/guides/how-ssl-certificates-expire-silently)[Let's Encrypt Auto-Renewal Failures: ACME Failure Modes Explained 9 min ](/guides/lets-encrypt-renewal-failures)

#### Compare FourSight

[vs UptimeRobot →](/compare/uptimerobot-alternative)[vs StatusCake →](/compare/statuscake-alternative)[vs Pingdom →](/compare/pingdom-alternative)

10 free commercial-safe monitors

[View Pricing](/pricing)

## Protect Your SaaS Revenue

Start monitoring in under 60 seconds.

[Start Monitoring Free](/auth?signup=true)[View Pricing](/pricing)

FourSight 

© 2026 [TetraCore](https://tetracorehq.com/). All rights reserved.

FourSight is a TetraCore product — Bowling Green, Ohio.

Product

[Pricing](/pricing)[Guides](/guides)[Glossary](/glossary)[FAQ](/faq)[About](/about)[For Agencies](/solutions/agencies)[For Startups](/solutions/startups)[Privacy](/privacy)[Terms](/terms)

Features

[Cron Job & Heartbeat Monitoring](/features/cron-job-monitoring)[SSL Certificate Monitoring](/features/ssl-monitoring)[Status Pages](/features/status-pages)[Domain Expiry Monitoring](/features/domain-expiry-monitoring)[DNS Monitoring](/features/dns-monitoring)[Port Monitoring](/features/port-monitoring)

Compare

[All comparisons](/compare)[vs UptimeRobot](/compare/uptimerobot-alternative)[vs StatusCake](/compare/statuscake-alternative)[vs Freshping](/compare/freshping-alternative)[vs Pingdom](/compare/pingdom-alternative)[vs Pulsetic](/compare/pulsetic-alternative)[vs Better Stack](/compare/better-stack-alternative)[vs Uptime Kuma](/compare/uptime-kuma-alternative)[vs Cronitor](/compare/cronitor-alternative)[vs Healthchecks.io](/compare/healthchecks-alternative)[vs Hyperping](/compare/hyperping-alternative)

Pricing Guides

[UptimeRobot Pricing](/compare/uptimerobot-pricing)[StatusCake Pricing](/compare/statuscake-pricing)[Pingdom Pricing](/compare/pingdom-pricing)[Better Stack Pricing](/compare/better-stack-pricing)[Uptime Kuma Pricing](/compare/uptime-kuma-pricing)[Cronitor Pricing](/compare/cronitor-pricing)[Healthchecks.io Pricing](/compare/healthchecks-pricing)[Hyperping Pricing](/compare/hyperping-pricing)[Pulsetic Pricing](/compare/pulsetic-pricing)