---
title: How uptime is calculated, and why one failed check doesn't count
description: Uptime that drops for every failed check measures your monitor, not your site. WatchFor counts only confirmed incidents, and keeps that history forever.
canonical: https://watchfor.io/blog/how-uptime-is-calculated
---

# How uptime is calculated, and why one failed check doesn't count

2026-10-20 · WatchFor Team · Monitoring · monitoring, uptime, reliability, incidents

Uptime that drops for every failed check measures your monitor, not your site. WatchFor counts only confirmed incidents, and keeps that history forever.

It's the end of the quarter and a customer asks for your uptime. Two tools
answer. One says 99.95%. The other says 99.81%. Nobody on the team remembers
an outage, the status page was green all quarter, and now you have to explain
which number is true.

Both tools watched the same site. They didn't disagree about the site. They
disagreed about what "uptime" means.

## The number most tools give you

The common way to calculate uptime is a ratio of checks:

```
uptime = successful checks / all checks
```

It's easy to compute and easy to explain. It also has three problems that
show up the moment you rely on it.

**One bad network path becomes downtime.** A check is one request from one
place. If the route between that location and your server drops packets for
thirty seconds, the check fails, and the ratio counts it as your site being
down. Your visitors, on other networks, saw nothing.

**The same outage gives different numbers.** Take a real three-minute outage
and two monitors on the same site:

| Check interval | Checks in a day | Failed checks | Uptime by check ratio |
| --- | --- | --- | --- |
| Every minute | 1,440 | 3 | 99.79% |
| Every 5 minutes | 288 | 0 or 1, depending on timing | 100% or 99.65% |

![Timeline of one three-minute outage: a one-minute monitor records three failed checks, a five-minute monitor records none or one, while an incident-based figure records the same three minutes for both](/blog/how-uptime-is-calculated-ratio.webp)

The outage didn't change. The sampling did. A five-minute monitor can miss a
short outage completely, or turn it into five minutes of "downtime" because
one sample happened to land inside it.

**A blip you can't explain still costs you.** The ratio has no idea whether a
failed check was a real outage or a timeout on our side of the internet. It
just subtracts it. You end up arguing with your own monitoring tool.

## What WatchFor counts instead

WatchFor calculates uptime from **confirmed incidents**, not from individual
checks. One formula is used everywhere a percentage appears: the monitor
cards, the Uptime card on the monitor page, the Uptime SLA tab, reports, the
status page bars and the API.

```
uptime = (observed time − time in critical incidents − scheduled maintenance) / observed time
```

A single failed check is not an incident. When a check fails, WatchFor checks
again, faster, and from other locations, and only opens an incident once the
failure is confirmed. We wrote up exactly how that works in
[How we confirm an outage before paging anyone](/blog/confirm-outage-before-paging);
the short version is that a failure has to be real from more than one angle
before it becomes downtime. A failed check that never turns into an incident
does not lower your uptime anywhere in the product.

Three details matter:

- **Only critical incidents count.** A warning incident marks the monitor as
  Degraded, which is worth knowing, but it doesn't reduce uptime. Slow is not
  down.
- **Downtime is measured in time, not in checks.** Once a failure is
  confirmed, the incident is dated back to the first failed check of that run
  and ends when the site recovered. A one-minute monitor and a five-minute
  monitor report the same outage as roughly the same number of minutes; the
  difference is only how quickly each one noticed.
- **New monitors are judged on their own life.** A monitor created ten
  minutes ago is measured over those ten minutes, not over a day it didn't
  exist for. The card says *since created* until it has a full day of
  history.

![A monitor page with the Uptime card (100.00%, up for 5 days) and the Incidents card side by side, and the probe success figure in the card next to them](/blog/how-uptime-is-calculated-cards.webp)

## The check ratio still exists, under its own name

Throwing away the per-check view would hide something useful, so we kept it
and gave it an honest name: **check success**. It's the share of checks where
the probe reached your server and got an answer, shown next to uptime in
reports and on the API.

Check success is the number to read for flakiness: timeouts, refused
connections, DNS that sometimes doesn't resolve. It can even sit at 100%
while the monitor is down, because a server that answers *500* on every
request was reached every time. The two numbers answer different questions,
so they never share a label.

## Planned work and false alarms

Two kinds of time shouldn't count against you, and both are handled without
deleting anything.

**Scheduled maintenance is neutral.** Time inside a
[maintenance window](/docs/monitors/maintenance) counts as neither up nor
down. The checks keep running, so you still see what happened, and uptime
figures say so out loud, for example *excludes 2h of scheduled maintenance*.
If something real breaks during the window and is still broken when it ends,
you get paged within about a minute of the window closing.

**A confirmed incident can still be wrong.** Confirmation makes false alarms
rare, not impossible: a firewall rule that briefly blocked the probes, a
threshold set too tight. Owners and admins can mark a resolved incident as a
[false positive](/docs/alerting/resolving#false-positives). It stays on
record with its timeline, notes and post-mortem, but it stops counting as
downtime in uptime, the SLA tab, reports and the status page. If you change
your mind, *Count as downtime again* puts it back.

![A resolved critical incident with the False positive badge and the reason: a rate limit from the API being polled too often, not an outage. Count as downtime again undoes it](/blog/how-uptime-is-calculated-false-positive.webp)

Both actions are recorded in the
[activity log](/docs/organization/activity-log), so a number that changed
always has a name and a reason next to it.

## History that doesn't expire

Uptime figures are only useful if you can go back to them. A customer asking
about last year's SLA doesn't care which plan you were on.

WatchFor keeps **uptime, SLA and incident history forever, on every plan,
including Free**. What varies by plan is how long we keep every individual
check result: 30 days on Free and Starter, 90 days on Pro and 180 days on
Business. Charts further back are drawn from hourly summaries. When raw
checks age out, the incidents, their timelines and the uptime they produced
stay exactly as they were. The full table is in
[Data retention](/docs/organization/data-retention).

![The Uptime SLA tab of a monitor with 17 days of history: 99.90% for the last 7 days, 85.81% for the last 30 days after a long outage, each with a note that only 17 days of history exist so far](/blog/how-uptime-is-calculated-sla.webp)

## The trade-offs

No way of counting is free, and this one has costs worth stating plainly.

- **Confirmation takes a little time.** The alert reaches you after the
  failure is confirmed, not at the first failed check. The downtime itself is
  dated back to that first check, so the number is right; it's the page that
  arrives a minute later. We think an alert you can trust is worth that.
- **Very short blips can go uncounted.** If something fails for twenty
  seconds and recovers before confirmation finishes, uptime stays at 100%.
  Check success will still show the failed checks, and that is the place to
  look for intermittent trouble.
- **You have to trust the incident list.** Because uptime follows incidents,
  a wrong incident means a wrong number until someone marks it. That's why
  false positives are one click and fully visible, not something support has
  to do for you.

If you're choosing a target, [What is 99.9% uptime?](/blog/what-is-99-9-percent-uptime)
turns the nines into minutes. If you're measuring one, measure outages your
users could have felt. A failed check is a rumour. An incident is the thing
you'll be asked about.

Read the formula and every rule behind it in
[How uptime is calculated](/docs/monitors#how-uptime-is-calculated).

---

Canonical page: https://watchfor.io/blog/how-uptime-is-calculated · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt