What Is Uptime Monitoring? A Complete Guide

Uptime monitoring is the practice of checking, automatically and at a fixed interval, that a website, API, server or scheduled job is available and responding the way it should. A monitoring service sends a request from outside your network, compares the answer with what it expects, and alerts you when the answer is wrong or does not arrive. When the service recovers, it tells you that too.

Available means more than "the server answered". A page can return a response and still be broken: an error message served with a 200 status, a blank page after a failed deployment, a login form that no longer loads, or a certificate that browsers refuse to trust. Good uptime monitoring checks the things that tell you a service works for the people who use it, not only that a machine somewhere is switched on.

What uptime percentages really mean

Uptime is usually quoted as a percentage over a month or a year. The figures sound close together, but the downtime they allow is very different:

Uptime	Downtime allowed per 30-day month	Downtime allowed per year
99%	7 hours 12 minutes	3 days 15 hours 36 minutes
99.5%	3 hours 36 minutes	1 day 19 hours 48 minutes
99.9%	43 minutes 12 seconds	8 hours 45 minutes 36 seconds
99.95%	21 minutes 36 seconds	4 hours 22 minutes 48 seconds
99.99%	4 minutes 19 seconds	52 minutes 34 seconds
99.999%	26 seconds	5 minutes 15 seconds

The free uptime calculator converts any target into the downtime it allows per day, month and year. In PulseStack™, a monitor's uptime percentage is the share of its checks over the last 30 days that succeeded.

Uptime monitoring and observability

Uptime monitoring tells you that something is wrong, from the outside, the way a customer experiences it. Observability tools such as logs, metrics and traces help you work out why, from the inside. They complement each other: external checks catch problems that internal tools cannot see, such as a DNS failure, an expired certificate or a network route that fails for some visitors. The guide to observability versus monitoring goes into the difference.

Without monitoring, outages are found by the people they affect: a customer emails, a sales figure dips, or someone happens to load the site. By then the problem may have been running for hours. Monitoring reverses that order, so you hear first.

Lost orders and enquiries

For a business that sells online, downtime costs money in a straight line. If a shop takes £2,400 a day fairly evenly, every hour offline costs about £100 in orders, before counting the customers who do not come back. Outages also tend to arrive when traffic is highest, during a launch, a sale or a campaign, because that is when systems are under most strain. The cost of downtime guide shows how to work out the figure for your own business.

Search visibility

Search engines crawl on their own schedule. Google's documentation says its crawlers slow down when a site returns server errors (5xx) or 429 responses, and that pages which keep returning errors are eventually dropped from its index. A short outage rarely does lasting harm, but repeated or long ones can, and the effect often appears days later, when the cause is hard to trace without monitoring history.

Trust and service agreements

If you promise customers a level of availability, you need an independent record of what actually happened. Monitoring history gives you that record, and a public status page lets customers see the current state for themselves instead of opening support tickets.

Faster fixes

A vague report that "the site seems slow" sends someone searching. An alert that names the monitor, the error and the locations that failed tells the person on call where to start.

Every uptime monitor follows the same cycle:

1. Schedule. Each monitor has a target (a URL, host, port or heartbeat), a type and an interval, such as every 60 seconds.
2. Request. At each interval a probe server outside your network sends the request.
3. Evaluate. The response is compared with what the monitor expects.
4. Record. The result, status code and response time are stored, building the history behind uptime percentages and charts.
5. Alert. When the result changes from passing to failing, or back again, the right people are told.

What a check looks at

• Status code. HTTP checks read the status code of the final response. PulseStack™ follows redirects and by default expects 200 on the page you land on. You can set a different expected code per monitor, for example 401 for an endpoint that should refuse anonymous requests. The guide to HTTP status codes explains what each code means for monitoring.
• Response time. Every check records how long the response took, and PulseStack™ charts it per location. It does not send alerts for slow responses, so the charts are where you spot a slowdown building.
• Content. A keyword monitor confirms that a word or phrase is in the page HTML, or that an error message is not, which catches pages that return 200 but are broken.
• Certificate. An SSL certificate monitor opens a TLS connection and reads the certificate's expiry date and whether browsers would trust it.

Confirming a failure before anyone is alerted

A single failed request does not prove a site is down. A dropped packet, a brief routing fault or a hiccup at the monitoring end can each fail one check. Reliable monitoring confirms a failure before it alerts.

In PulseStack™, website, keyword, API, ping and port monitors are checked from three locations, London, New York and Sydney, and a monitor is only marked down when at least two of them fail. SSL certificate, DNS record, domain expiry and heartbeat monitors run from our main server and are re-tested three seconds after a failure before the result counts.

One alert when it breaks, one when it recovers

Alerts fire on a change of state. When a monitor goes down you get one alert, and when it comes back you get a recovery alert that says how long it was down. You are not sent a fresh alert for every failed check in between.

Different parts of a service fail in different ways, so most setups combine several monitor types. These are the nine PulseStack™ offers and what each one is for. The Free plan includes HTTP(S) monitors, and paid plans include every type.

HTTP(S) monitoring

Requests a URL and checks the status code and response time. It is the first monitor to set up for any website or web application. See website monitoring.

Keyword monitoring

Fetches a page and checks that a word or phrase is present, or that it is absent. The match is case-sensitive and runs against the raw HTML before any JavaScript runs, so choose text that appears in the page source. Use it to catch error pages served with a 200 status, empty pages after a failed build, or a maintenance message left switched on. See keyword monitoring.

Ping monitoring

Classic ping uses ICMP. PulseStack™ ping monitors open a TCP connection to the host instead (port 80 unless you choose another) and record the connection time, which works even where ICMP is blocked. A host can answer while the application on it has crashed, so use ping alongside HTTP checks, not instead of them. See ping monitoring.

Port monitoring

Checks that a TCP port accepts connections: a database on 5432 or 3306, a mail server on 25 or 993, or a custom service. It confirms that something is listening, not that the service behind the port is working correctly. See port monitoring.

API monitoring

Sends a request to an API endpoint with your choice of method (GET, POST, PUT, PATCH or HEAD), headers and body, and checks for the status code you expect. Custom headers let you monitor endpoints that need an API key or a bearer token. See API monitoring and the developer's guide to API monitoring.

Heartbeat (cron job) monitoring

Turns monitoring around: your job sends a request to a unique PulseStack™ URL each time it runs, and you are alerted when no signal arrives within the grace period you set. The grace period runs from 1 to 60 minutes (five by default), so heartbeats suit jobs that run at least once an hour, such as queue workers, imports and frequent syncs that can fail without anyone noticing. See cron job monitoring.

SSL certificate monitoring

Reads the certificate presented on port 443 and alerts when it is within a set number of days of expiry (seven by default, adjustable per monitor), or as soon as browsers would refuse it: expired, self-signed, issued for a different name or missing part of its chain. Certificate lifetimes are getting shorter, as the SSL certificate expiry changes explain, so this matters more each year. See SSL certificate monitoring.

DNS record monitoring

Watches one record for a hostname, such as an A or MX record, and alerts when no record holds the value you expect, or when the record disappears. A DNS mistake takes every service on a domain offline at once, so watch the records that matter. See DNS monitoring.

Domain expiry monitoring

Looks up a domain's registration expiry date and warns you a set number of days before it lapses. A forgotten renewal, or an expired card on the registrar account, can take a whole business offline. See domain expiry monitoring.

What uptime monitoring does not cover

Some tools also run scripted browser journeys, such as logging in and completing a checkout, and real user monitoring, which measures what visitors' own browsers experience. PulseStack™ does neither. Its checks are single requests, which makes them fast and dependable, but a journey that fails at step three needs a different kind of tool. The guide to synthetic versus real user monitoring explains the difference.

The interval decides how quickly you hear about a problem. Shorter intervals detect outages sooner but send more requests to your server. Longer ones are fine for things that change slowly.

What you are monitoring	Suggested interval	Why
Checkout, login or main API	30 to 60 seconds	Every minute offline has a cost
Main website pages	60 seconds	Fast detection without much load
Marketing pages, documentation, staging	5 minutes	Lower impact if they fail
SSL certificates	Hourly or slower	Expiry is a date, not a moment-to-moment state
DNS records	5 to 15 minutes	Records change rarely
Domain registrations	Every 12 to 24 hours	The expiry date changes once a year
Cron jobs (heartbeats)	A grace period a little longer than the gap between runs	You want to know when a run is missed

In PulseStack™, the fastest interval depends on the plan: every 5 minutes on Free, every 60 seconds on Starter, and every 30 seconds on Pro, Team and Enterprise. Some monitor types have their own minimum: SSL certificate monitors run at most hourly, DNS record monitors every 5 minutes, and domain expiry monitors every 12 hours.

Because a failure is confirmed before it alerts, expect to hear about an outage within one to two intervals rather than one. A sensible start is 60 seconds for anything customer-facing and 5 minutes for the rest, adjusted once you have a few weeks of history.

A check from one place tests one network path. If that path breaks, a single-location monitor reports an outage your customers never saw. If a different path breaks, one your customers use, it may report nothing at all.

Checking from several locations deals with both. A failure that only one location sees is usually a fault on that route rather than an outage. A failure that two or more locations agree on is real.

PulseStack™ runs website, keyword, API, ping and port monitors from London, New York and Sydney, and marks a monitor down when at least two locations fail. The locations and the two-location rule are the same for every monitor, which keeps alerts consistent. Response times are charted for each location, so a slowdown that affects one region shows as a gap between the lines. See multi-location monitoring.

Three locations cannot see every network. A problem limited to one country, one internet provider or one CDN edge can be real for the people affected while all three probes succeed. If customers in one region report trouble your checks do not show, ask someone there to test, and check your CDN or hosting provider's status for that region.

Monitoring only helps if the alert reaches someone who can act on it. Three decisions matter: where alerts go, who gets which, and how to keep the noise down.

Choose channels by urgency

PulseStack™ has eight native alert channels: email, SMS, Slack, Microsoft Teams, Discord, PagerDuty, Telegram and webhooks. Zapier and Google Chat connect through the webhook channel.

• Email suits awareness and anything that can wait a few minutes.
• Slack, Microsoft Teams, Discord or Telegram put alerts where the team already talks, so everyone sees them and nobody investigates twice.
• SMS cuts through for production outages. It is included on Team and Enterprise, or available as an add-on.
• PagerDuty handles on-call rotas and escalation. PulseStack™ triggers an incident when a monitor goes down and resolves the same incident when it recovers.
• Webhooks send a JSON payload to your own systems, for example to open a ticket automatically.

Route each monitor to the right people

Each monitor has its own list of alert contacts, so production checks can reach the on-call engineer while staging checks go to a quieter channel. A monitor with no contacts selected alerts every contact on the account.

Keep the noise down

Alert fatigue sets in when people receive alerts they cannot act on, and it is the main reason monitoring ends up ignored. Two-location confirmation removes most false alarms. Recovery alerts close the loop, so nobody keeps investigating a problem that has already cleared. Sending each monitor only to the people who own it does the rest. The guide to alert fatigue covers this in more depth.

Monitoring tells your team what is happening; a status page tells your customers. During an outage, silence does more damage than the fault itself: people refresh, wonder whether the problem is theirs, and open support tickets. A status page gives them one place to look.

Every PulseStack™ plan includes public status pages that show your monitors' live status and daily history for the last 30 days, and the Free plan includes one. Name components the way customers think of them, such as "Website", "API" or "Checkout", rather than by internal server names.

When something goes wrong, acknowledge it quickly, update regularly even when there is nothing new, be specific about what is affected, and confirm clearly when it is resolved. The guides to creating a status page and to incident management go further.

A site that takes eight seconds to respond is up by any technical measure and down by any practical one. Response times often climb before an outage, as a database runs short of connections or a server runs short of memory, so a rising trend is an early warning.

PulseStack™ records the response time of every check and charts it for each location. It does not alert on slow responses, so the charts are where you look. To read them well:

1. Collect two weeks of data to see what normal looks like at different times of day.
2. Compare typical values with the slowest ones: the median shows the usual experience, the 90th or 99th percentile shows the bad moments.
3. Compare locations. Distance adds time, so some difference is normal, but a sudden gap in one region points to a routing or CDN problem.
4. Look again after each release, because performance regressions often arrive with deployments.

The guide to response time thresholds covers how to set targets, and response time monitoring shows what PulseStack™ records.

Setting up takes a few minutes and needs no code, server access or DNS changes. You need the URLs you want to watch and an email address for alerts.

1. Create an account

Register with your email address and a password. The Free plan includes 5 HTTP(S) monitors with checks every 5 minutes and one public status page, with no card needed. Paid plans start with a 14-day trial, also with no card. The pricing page compares the plans.

2. Add your first monitor

From the dashboard, choose "Add monitor" and fill in the form:

• Type. HTTP(S) for a website. Paid plans add keyword, TCP ping, port, API, heartbeat, SSL certificate, DNS record and domain expiry monitors.
• URL and name. Enter the full URL, including https://, and use the final address visitors land on: if example.co.uk redirects to www.example.co.uk, monitor the www address. Give the monitor a name you will recognise in an alert, such as "Checkout".
• Interval. As fast as your plan allows for important pages, slower for the rest.
• Advanced settings. Change the expected status code (200 by default), the HTTP method or the timeout (30 seconds by default), and on paid plans add custom request headers.
• Tags. Optional labels, such as production or a client's name, keep a long list tidy.

Start with five to ten monitors on the pages and endpoints that matter most: the homepage, the main product or service pages, login, checkout and any API health endpoint.

3. Set up alert contacts

Open Alert contacts, choose "Add contact" and pick a channel. For Slack, create an incoming webhook for the channel you want alerts in, copy the URL Slack gives you (it starts https://hooks.slack.com) and paste it in. Then open each monitor and tick the contacts that should hear about it under "Notify on failure".

4. Test the whole chain

Every contact has a "Send test" button. Use it for each one and check the message arrives where you expect. If you have a staging site, make a test URL return a 503 for a few minutes and watch the whole sequence: the failed check, the confirmation, the alert and the recovery.

5. Publish a status page and review weekly

If your customers would benefit, open Status pages and choose "Create Status Page". Then look at the dashboard once a week. Are response times creeping up? Is one monitor failing more often than the others? Does the list still match what you run?

Monitoring only the homepage

A homepage is often served from a cache that stays up when the application behind it has failed. Monitor the pages and endpoints that do real work: login, search, checkout and the API.

Monitoring a URL that redirects

When the monitored URL redirects, every check follows the redirect chain, which adds to the response time and hides which hop is slow. Monitor the final address, and add a separate check if the redirect itself matters.

Forgetting certificates and domains

An expired certificate or a lapsed domain causes about as complete an outage as there is, and both are preventable. Add an SSL certificate monitor and a domain expiry monitor for every domain you rely on, including ones used only for email or redirects. If a certificate has already lapsed, the guide to an expired SSL certificate walks through the fix.

Sending every alert to everyone

When everyone gets everything, nobody owns anything. Route each monitor to the people who can fix it.

Ignoring third-party services

Your checkout depends on your payment provider, and your login may depend on an identity service. Monitor the external endpoints you rely on so you know when a problem is upstream. The guide to third-party dependency monitoring explains how.

Setting it up once and never looking again

Services change. Review your monitors every few months: add checks for new features, remove ones for retired endpoints, and make sure alerts still reach the right people.

Relying on one system to watch itself

If your monitoring runs on the same infrastructure as your site, one failure can take out both, and you hear nothing. Keep monitoring independent of what it watches.

If your site is down right now, start with why is my website down?. If you are choosing a tool, the comparison of the best free uptime monitoring tools sets out each free plan. For server uptime commands rather than website monitoring, see how to check uptime on Windows, Mac and Linux.

What is the difference between uptime and availability?

Uptime is the time a system is running and reachable. Availability is the share of a period in which it was usable, and it is the figure most service agreements use. External uptime monitoring measures availability the way customers experience it: from outside your network.

How often should uptime be checked?

Every 60 seconds suits most customer-facing services, and every 5 minutes is fine for lower-impact pages. Checkout, login and core APIs justify 30-second checks. Certificates, DNS records and domain registrations change slowly, so hourly or daily checks are enough.

What is a good uptime percentage?

Many businesses aim for 99.9%, which allows about 43 minutes of downtime in a 30-day month. Each extra nine cuts the allowance by ten: 99.99% allows about 4 minutes a month and usually needs redundant infrastructure to reach.

Is uptime monitoring free?

Many tools have a free plan. The PulseStack™ Free plan covers 5 HTTP(S) monitors with checks every 5 minutes, email alerts and one public status page, with no card needed. Paid plans add faster checks and every monitor type.

Can uptime monitoring check pages behind a login?

It can check endpoints that accept a token or key in a request header: on paid plans PulseStack™ sends custom headers such as an Authorization header. It cannot fill in a login form and click through a journey, which needs a scripted browser check.

Is uptime monitoring the same as the uptime command on a server?

No. The uptime command reports how long a machine has been running since it last restarted. Uptime monitoring checks from outside whether a service is reachable and responding correctly. A server can have weeks of uptime while its website is down.