← Blog

What is uptime monitoring? A guide for 2026

Last updated 23 June 2026

What uptime monitoring checks, how HTTP, keyword, heartbeat and TCP checks differ, and how to stop one-off failures from paging people.

Uptime monitoring means checking a service on a schedule and alerting someone when it stops responding correctly. The aim is to hear about real problems before customers do, without so many false alarms that people stop reacting.

Types of check

  • HTTP: request a URL and check the status code and response time. Used for most websites and APIs.
  • Keyword: an HTTP check that also looks for a word (or its absence) in the body, so a 200 response showing an error page still fails.
  • Heartbeat: your cron job or worker requests the monitor's URL on each run. If no request arrives in the expected window, the job is marked down. Used for anything without a public URL.
  • TCP: open a connection to a host and port. Used for databases, mail servers and other services that don't speak HTTP.

Check interval

Most monitors check every one or two minutes. A single failed check rarely means an outage: networks drop packets, servers pause, deploys restart processes. Alerting on every single failure is how a pager ends up ignored.

Confirmation thresholds

Require several failures in a row before opening an incident, and several successes in a row before resolving it. Short glitches are absorbed and sustained failures are still caught within a few minutes. A brief recovery in the middle of an outage shouldn't split it into two incidents. A confirmed recovery followed by a new failure should start a new one.

Checking from more than one region

Every check runs from somewhere, and a network fault between that location and your server looks the same as your server being down. Thresholds handle short faults, but a longer one on a single route can still look like an outage. Checking from several regions handles that. In Sentivel, a monitor with two or more regions is checked from each one, and an incident opens only when a majority of regions see the failure. Combined with the thresholds above, an outage has to last and be seen from more than one place before anyone is paged.

Connecting monitors to your status page

When a monitor's confirmed state drives a component on your status page, customers see the real status without anyone updating it by hand. A new monitor should show as warming up until it has a few successful checks.

Uptime monitoring that waits for a confirmed failure before paging anyone.

Start free

Frequently asked questions

What is uptime monitoring?
Checking a service on a schedule, by HTTP request, keyword match, heartbeat or TCP connection, and alerting when it fails, so you hear about problems before customers do.
What is the difference between HTTP and heartbeat monitoring?
An HTTP monitor requests a URL and checks the response. A heartbeat monitor waits for your job to request its URL on each run and alerts when a request doesn't arrive. Heartbeats suit cron jobs and workers without a public URL.
How do I avoid false-positive alerts?
Require several failed checks in a row before opening an incident and several successes before resolving it. Check from more than one region and alert only when a majority agree.
How often should checks run?
Every one to two minutes is typical. Shorter intervals find problems sooner and cost more. Use confirmation thresholds so more checks don't mean more noise.

Keep reading