What Is Uptime Monitoring? A Complete Explainer

Uptime monitoring is automated, external checking of whether a service is reachable and working correctly. A monitoring system runs a check against your target on a schedule, records the result, and alerts you when the target fails. The output is two things: fast notification of outages and a historical availability percentage, usually called uptime.

It is sometimes called availability monitoring, website monitoring or black-box monitoring, because it observes your service from the outside, the same way a user or client would, without needing access to your code or servers.

How uptime monitoring works

Every uptime check follows the same loop, regardless of tool:

1. Request. A probe (a server run by the monitoring service) sends a request to your target: an HTTP request to a URL, a TCP connection to a port, a DNS query, or an ICMP ping.
2. Evaluate. The response is compared with expectations: status code in the 2xx range, a keyword present in the page, a response within the timeout, a valid TLS certificate, a DNS record with the right value.
3. Confirm. A single failure is usually re-checked before anything is declared down, because networks occasionally drop a packet or a request times out once.
4. Alert. When the failure is confirmed, an incident opens and notifications go to the channels you configured.
5. Recover. When checks succeed again, the incident closes, a recovery notification goes out, and the downtime is recorded in the availability history.

Scheduled jobs are monitored the other way around. Instead of the monitor calling your service, your job calls the monitor after each successful run. If the expected call does not arrive in time, the monitor alerts. This is called heartbeat or dead man's switch monitoring.

Common check types

Check intervals and detection time

The check interval sets how quickly you can learn about an outage. With a 5-minute interval, an outage that starts right after a successful check is not seen until the next one, and then needs confirmation. With a 30-second or 1-minute interval, detection happens within a minute or two.

A rough rule: worst-case detection time is about one interval plus the time needed to confirm the failure. Shorter intervals cost the provider more, which is why free plans typically check every 5 minutes and paid plans every 30 to 60 seconds.

• 5 minutes is adequate for personal sites, blogs and internal tools.
• 1 minute suits most business websites and APIs.
• 30 seconds or less is for revenue-critical paths such as checkout or login.

In Uptime Tracker, intervals range from 15 seconds to 1 hour, with the fastest allowed interval set by plan: 5 minutes on Free, 60 seconds on Starter and 30 seconds on Team.

Why confirmation matters

Confirmation is the step that separates a real outage from a network blip. Without it, a single dropped packet between the probe and your server would page someone at 3 a.m. Good monitoring tools re-check a failure before declaring the target down, and require more than one success before declaring it recovered, so a flapping service does not generate a storm of alerts.

Uptime Tracker requires two consecutive failed checks before a monitor is marked down and two consecutive successes before it is marked up again. Errors on the monitoring side are not counted as your downtime; uncertain results are shown as "unknown" rather than guessed. Today checks run from one probe location; additional probe regions are planned and will add cross-region confirmation.

What to monitor

Start with what your users and revenue depend on, then add the infrastructure underneath. A practical first set:

• Your homepage, with a keyword check for text that only appears on a healthy page.
• Login, signup and checkout pages or their API endpoints.
• A dedicated /health endpoint for each backend service.
• Public APIs that customers or mobile apps call.
• DNS records for your main domain and mail (MX).
• TLS certificates and domain registration expiry.
• Scheduled jobs: backups, billing runs, data syncs, via heartbeats.

The step-by-step version is in how to monitor website uptime.

Alerts and incident workflow

An alert is only useful if it reaches someone who can act. Most teams use two tiers: chat channels (Slack, Microsoft Teams, Discord) for awareness and a paging channel (SMS, PagerDuty, push notifications) for urgent issues outside working hours. As a team grows, routing rules, on-call rotations and escalation policies decide who is notified and when. See alerts and incident management for how Uptime Tracker handles this.

Uptime percentage and reporting

Uptime is expressed as the percentage of time a service was available in a period. 99.9% over a 30-day month allows 43 minutes and 12 seconds of downtime. The full table of "nines" is in uptime percentages explained, and you can compute any target with the uptime calculator. Many teams publish this data on a status page.

Free vs paid uptime monitoring

Free plans cover the basics; paid plans buy speed, channels and history. The main differences between tiers across the market are:

As a concrete example, Uptime Tracker's Free plan includes 2 monitors at 5-minute intervals, 5 heartbeat monitors, one status page, and alerts by email, Slack, Discord, Telegram and webhooks, with commercial use allowed, which is enough to watch your most important site. Starter ($9/month) raises that to 10 monitors with 60-second checks and adds SMS and more channels; Team ($49/month) offers 50 monitors, 30-second checks, PagerDuty, on-call rotations and escalation. Current details are on the pricing page.

Uptime monitoring vs other kinds of monitoring

Uptime monitoring answers "is it up and responding correctly from the outside?" It complements, rather than replaces, application performance monitoring (traces and code-level timings), log management, infrastructure metrics (CPU, memory, disk) and real-user monitoring. Small teams often start with uptime monitoring because it requires no code changes and catches the outages users notice first.