What Is Uptime Monitoring? How It Works and What to Monitor

In March 2024, Facebook, Instagram and other Meta services suffered a widespread outage lasting roughly two hours. Wedbush Securities analyst Dan Ives estimated that the disruption may have cost Meta approximately $100 million in revenue.

Whether your business operates at Meta’s scale or serves a smaller audience, the underlying lesson is the same: you need to know when customers cannot reach your services.

That is where uptime monitoring comes in.

Uptime monitoring is the automated process of checking whether a website, API, server or other online service is available and responding correctly.

A monitoring service performs checks at regular intervals from outside your infrastructure. If a check fails, times out or returns an unexpected result, it can retry the request, confirm the problem and alert you before customers report it.

Modern uptime monitoring should verify more than whether a server returns a response. A website can return 200 OK while displaying an error page, an empty screen or a maintenance message. Status-code and keyword monitoring can work together to detect these less obvious failures.

In this guide, we’ll explain how uptime monitoring works, the different checks you can use, which metrics matter and how to build a monitoring setup that detects real problems without generating constant false alerts.

What Does “Uptime” Mean?

Uptime represents the percentage of time that a service was available during a particular measurement period.

The basic calculation is:

Uptime percentage = Available time ÷ Total measured time × 100

For example, if a website was unavailable for 43 minutes during a 30-day month, its uptime would be approximately 99.9%.

Small differences in availability percentages can represent significant amounts of downtime:

Our guide to comparing availability “nines” examines these percentages in more detail.

Uptime percentage is useful, but it should not be your only measure of reliability. A website can technically be online while responding so slowly—or returning such an incomplete response—that customers cannot use it effectively.

How Does Uptime Monitoring Work?

An uptime monitor behaves like a lightweight external visitor.

At a configured interval, it connects to your website or service and checks whether the result meets the conditions you defined.

A typical monitoring cycle works like this:

1. Send a check: The monitoring system requests a URL, resolves a DNS record, connects to a port or sends a ping.
2. Validate the result: It checks the status code, expected keyword, DNS value, connection result or certificate.
3. Measure response time: It records how long the service took to respond.
4. Retry a failure: The request may be repeated to rule out a temporary network interruption.
5. Confirm the incident: The system determines whether the failure meets the conditions required to declare the service down.
6. Send an alert: The monitoring service notifies the appropriate people through their chosen channels.
7. Detect recovery: Checks continue during the incident so the service can notify you when the endpoint works again.

This process runs continuously, including overnight, on weekends and whenever nobody is actively watching your infrastructure.

External Monitoring vs Internal Server Monitoring

External uptime monitoring and internal server monitoring answer different questions.

Internal monitoring collects data such as:

• CPU utilization
• Available memory
• Disk space
• Application logs
• Database activity
• Queue length
• Container health

This information helps engineers understand what is happening inside their infrastructure.

External uptime monitoring asks a more direct question:

Can someone outside your network reach and use the service right now?

A server dashboard may show healthy CPU and memory while customers receive a DNS error, an expired certificate or a response blocked by a firewall. Conversely, a server may have high CPU usage while the application continues serving customers normally.

For effective coverage, use both:

• Internal monitoring to understand infrastructure health and diagnose failures
• External monitoring to verify availability from the customer’s perspective

Types of Uptime Monitoring

Different failures require different types of checks. Monitoring only your homepage will not tell you whether your DNS records, API, background jobs and other critical services are working.

HTTP and HTTPS Monitoring

HTTP monitoring requests a website, web application or API endpoint and verifies that it returns an acceptable response.

An HTTP monitor can check:

• Whether a connection can be established
• Whether the request completes before the timeout
• Whether the endpoint returns the expected HTTP status code
• How long the response takes
• Whether HTTPS negotiation succeeds
• Whether the TLS certificate is valid

HTTP monitoring is usually the best starting point for websites, SaaS applications, online stores and REST APIs.

Do not limit monitoring to your homepage. Check the endpoints that represent important customer actions, such as:

• Login
• Checkout
• Account dashboard
• API health endpoint
• Payment callback
• Webhook receiver

A working homepage does not prove that the rest of an application works.

Keyword Monitoring

Status-code monitoring tells you whether a server responded correctly at the HTTP level. Keyword monitoring helps verify that the response contains the content you expected.

This addresses an important blind spot: a broken application can return 200 OK.

For example, a website might respond successfully while displaying:

• A generic error page
• An empty template
• A database connection message
• A maintenance page
• A partially rendered page
• Incorrect content from a cache or deployment

A status-code-only monitor may treat that response as healthy because the server returned 200 OK. A keyword monitor can instead look for text that should appear when the page is functioning normally.

Examples include:

• Monitoring a store homepage for “Shop now”
• Checking a login page for “Sign in”
• Verifying that a customer portal contains “My account”
• Checking an API response for "status":"healthy"
• Confirming that a documentation page contains the current product name

Choose a keyword that is stable and specific to the successful response. Avoid generic words such as “website,” “home” or “page,” because they may also appear on error pages.

Keyword monitoring is especially valuable when you cannot rely on the HTTP status code alone. Used together, status-code and keyword checks answer two separate questions:

1. Did the server respond?
2. Did it return the content we expected?

Ping Monitoring

Ping monitoring uses ICMP echo requests to determine whether a host is reachable over the network.

It is useful for servers, routers, gateways and other infrastructure that may not expose a website. Ping can also help distinguish a host-level connectivity problem from an application-level HTTP failure.

However, a successful ping does not prove that a website or API is working. A server may answer ICMP requests while its web server, database or application has failed.

Use ping monitoring as a complementary infrastructure check, not as the only monitor for a web application.

Port Monitoring

Port monitoring attempts to connect to a particular TCP or UDP port.

This can verify that services such as HTTPS, SSH, SMTP or a custom network application are accepting connections.

Common examples include:

• Port 80 for HTTP
• Port 443 for HTTPS
• Port 22 for SSH
• Port 25 or 587 for email delivery
• A custom port used by an application

An open port does not necessarily mean the application behind it is functioning correctly. Whenever possible, combine port monitoring with a protocol-specific check.

DNS Monitoring

DNS monitoring verifies that a domain resolves correctly and that its records match their expected values.

DNS problems can make a healthy application completely unreachable. Common causes include:

• Accidental record changes
• Incorrect nameservers
• Failed DNS migrations
• Missing IPv4 or IPv6 records
• Unauthorized modifications
• Regional resolution failures

DNS monitoring is particularly important when several people or service providers can change your domain configuration.

TLS Certificate Monitoring

TLS certificate monitoring—still commonly called SSL certificate monitoring—checks the certificate presented by an HTTPS service.

A certificate check can detect:

• An expired certificate
• An approaching expiration date
• A hostname mismatch
• An invalid certificate chain
• A certificate that is not yet valid
• A failure to complete the TLS handshake

Automated renewal reduces certificate risk, but it does not eliminate it. A renewal job might succeed without deploying the new certificate to every server or load balancer.

Our guide explains how to monitor SSL certificate expiration and why independent verification remains necessary.

Domain Expiration Monitoring

Domain monitoring tracks when a registered domain is due to expire.

Domain expiration can take an entire business offline at once, affecting its website, API and email. Because domains may be managed across different registrars or employee accounts, relying on a single renewal email is risky.

Use independent expiration alerts and keep registrar ownership, billing details and recovery access documented.

Heartbeat Monitoring

Heartbeat monitoring is designed for scheduled jobs that cannot be checked using a normal external request.

Instead of the monitoring service contacting your system, your job sends a signal to a unique monitoring URL when it completes. If the signal does not arrive within the expected period, the monitor raises an alert.

Heartbeat checks are useful for:

• Cron jobs
• Database backups
• Data imports
• Report generation
• Queue workers
• Scheduled maintenance scripts
• Nightly synchronization tasks

A server can be online while a critical backup has silently stopped running. Heartbeat monitoring closes that gap.

Which Uptime Metrics Matter?

Availability Percentage

Availability shows how consistently a service remained reachable during the measurement period.

When comparing results, understand how the monitoring tool treats retries, excluded incidents and regional failures. Two providers can calculate availability differently.

Response Time

Response time measures how long a monitored request takes to complete.

Track the trend rather than relying on one universal threshold. A gradual increase can reveal database, network or application problems before the service becomes completely unavailable.

Incident Frequency

Incident frequency shows how often failures occur.

One 30-minute outage and thirty one-minute outages produce similar total downtime, but customers may experience them very differently. Repeated short incidents can indicate instability, overloaded dependencies or an overly sensitive monitor.

Time to Detect

Time to detect measures how long your monitoring system takes to notice a failure.

Check frequency has a direct effect. With 30-second checks, a failure will normally be discovered sooner than with five-minute checks, although timeouts and retries also affect detection time.

Time to Acknowledge

Detection alone does not resolve an incident. Time to acknowledge measures how long it takes someone to see the alert and begin responding.

An alert sent to an unattended inbox may be technically successful but operationally useless.

Time to Recover

Time to recover measures how long the service remains unavailable after detection.

Tracking recovery time helps you evaluate whether your alerting, escalation and troubleshooting processes are improving.

How Often Should You Check Uptime?

The right interval depends on how critical the service is and how quickly your team can respond.

As a practical starting point:

A five-minute interval does not mean an outage will always be detected after five minutes. If a failure begins midway between checks, the initial detection will take about two and a half minutes on average—before accounting for the timeout and retries.

Faster checks reduce detection time, but they should be paired with sensible retry rules to prevent temporary network errors from generating unnecessary alerts.

How to Avoid False Downtime Alerts

A useful monitor must detect real failures without waking your team for every brief interruption.

Use Retries Carefully

One or two quick retries can distinguish a temporary connection problem from a sustained outage. Too many retries, however, delay legitimate alerts.

Use faster escalation for revenue-critical endpoints and more conservative confirmation rules for lower-priority services.

Monitor From Multiple Locations

A check can fail because the monitoring location itself has a routing or connectivity problem.

Multi-location monitoring helps determine whether an outage is global or limited to a particular region. It can also uncover genuine regional failures that a single-location monitor would miss.

Read more about why geographic distribution matters in uptime monitoring.

Choose Realistic Timeouts

An aggressive timeout may mark a slow but functioning endpoint as down. An excessively long timeout delays detection.

Set the timeout using the endpoint’s normal response history and the response time you consider unacceptable for customers.

Select Reliable Keywords

For keyword monitoring, choose text that appears only when the page or response is healthy.

The keyword should be:

• Present on every successful response
• Unlikely to appear on an error page
• Stable across normal content updates
• Specific enough to prove the correct content loaded

If you monitor a frequently edited headline or product description, a routine content change could create an unnecessary alert.

Account for Firewalls and Rate Limits

Web application firewalls, bot protection and rate limiting may block monitoring requests even though regular visitors can access the site.

Allow the monitoring provider’s documented IP addresses or user agent where appropriate. Check for 403 Forbidden and 429 Too Many Requests responses when investigating false alerts.

Monitor the Right Endpoint

Choose a stable endpoint that represents the service you care about.

For APIs, a lightweight health endpoint can be useful, but it should check enough dependencies to be meaningful. A health endpoint that always returns 200 OK, even when the database is unavailable, provides false reassurance.

What Should You Monitor First?

Start with the services whose failure would immediately affect customers, revenue or essential business operations.

For a typical SaaS product, that might include:

1. The main website
2. The application login page
3. A stable keyword on each critical page
4. The primary API health endpoint
5. DNS records for the production domain
6. The HTTPS certificate
7. Payment or webhook endpoints
8. Background jobs and backups
9. The public status page

For an online store, add the product catalogue, cart and checkout. For an agency, monitor each client’s public website, DNS and certificate expiration. For a content site, prioritize the homepage, publishing system and domain.

Avoid creating dozens of monitors without an alerting plan. Every monitor should have an owner, a reason for existing and a clear response when it fails.

How Uptime Monitoring Supports Incident Response

Monitoring should connect directly to your incident process.

When an outage is confirmed, the monitoring system should alert the right people through channels they actually watch. Depending on the severity, that might include email, SMS, Slack, Discord, Telegram, PagerDuty or a webhook connected to another system.

A public status page can then keep customers informed while your team investigates. Clear communication reduces duplicate support requests and reassures customers that the problem has been acknowledged.

Prepare this workflow before an outage occurs. Our incident communication plan and templates provide a practical starting point.

After recovery, review what happened:

• Which monitor detected the failure?
• Was the alert fast and actionable?
• Did it reach the right person?
• Did status-code and keyword monitoring detect the correct condition?
• Were customers updated promptly?
• Was another monitor needed?
• What could prevent the incident from recurring?

This turns monitoring history into reliability improvements instead of treating every outage as an isolated event.

How to Choose an Uptime Monitoring Tool

Look beyond the number of monitors included in a plan. Consider whether the tool supports the services and response process you need.

Important capabilities include:

• HTTP and HTTPS monitoring
• Expected status-code validation
• Keyword monitoring
• DNS, port and ping checks
• TLS certificate and domain-expiration monitoring
• Heartbeat monitoring
• Flexible check intervals and timeouts
• Configurable retries
• Multiple monitoring locations
• Response-time history
• Several independent alert channels
• Integrations and webhooks
• Public status pages
• Incident history
• Clear firewall and allowlist documentation

Ease of use matters as well. A sophisticated monitoring system provides little protection if it is too difficult to configure or if nobody trusts its alerts.

Getting Started With Uptime Monitoring

You can build a useful first monitoring setup in a few minutes:

1. Create an HTTP monitor for your most important public endpoint.
2. Configure the expected HTTP status code.
3. Add a stable keyword that confirms the correct content loaded.
4. Select an interval appropriate to the endpoint’s business importance.
5. Configure a realistic timeout and retry policy.
6. Add another monitoring location if available.
7. Connect at least two alert channels for critical services.
8. Add DNS and TLS certificate monitoring.
9. Add heartbeat monitoring for essential scheduled jobs.
10. Test your alert workflow intentionally.

UptimeObserver can monitor websites, APIs, keywords, DNS records, ports, host connectivity, TLS certificates, domain expiration and scheduled jobs from external locations.

You can start monitoring your most important endpoint and expand your coverage as you identify where the real risks are.

The objective is not to produce a dashboard full of green checks. It is to find out quickly when customers cannot use your service—and give your team enough information to respond.