---
title: "What does 99.9% uptime mean? 43 minutes a month · Fettle"
description: "99.9% uptime allows 43m 12s of downtime in a 30-day month. Budgets for every common target, and why your check interval limits what you can measure."
url: "https://fettle.sh/guides/what-does-99-9-uptime-mean"
---

/ guides / what-does-99-9-uptime-mean

# What 99.9% uptime actually allows

99.9% uptime allows 43m 12s of downtime in a 30-day month. Budgets for every common target, and why your check interval limits what you can measure.

Updated 2026-10-31

[Start free](https://fettle.sh/register)

Free plan: 20 monitors every 3 minutes from 1 region. No card.

99.9% uptime means a service may be down for 0.1% of the time: 43 minutes 12 seconds in a 30-day month, 8 hours 45 minutes 36 seconds in a 365-day year, or about a minute and a half a day. Fettle is uptime monitoring for developers: it checks your sites, APIs and servers on a schedule and reports uptime as one minus the confirmed downtime over the time it was watching. That makes the number you read a measurement of what happened, not a promise about what will. You can run any target through the [uptime calculator](https://fettle.sh/tools/uptime-calculator) for the figures; the rest of this guide covers the full table, the limits of measuring it, and how the figure differs from an SLA.

## How much downtime does each uptime target allow?

Each extra nine cuts the allowed downtime by a factor of ten. 99% allows over seven hours a month, 99.9% about three quarters of an hour, 99.99% just over four minutes. The table below uses a 30-day month and a 365-day year, the convention Fettle's calculator uses; calculators that use an average month show slightly more.

| Target | Per day  | Per week   | Per 30-day month | Per 365-day year |
| ------ | -------- | ---------- | ---------------- | ---------------- |
| 99%    | 14m 24s  | 1h 40m 48s | 7h 12m           | 3d 15h 36m       |
| 99.5%  | 7m 12s   | 50m 24s    | 3h 36m           | 1d 19h 48m       |
| 99.9%  | 1m 26.4s | 10m 4.8s   | 43m 12s          | 8h 45m 36s       |
| 99.95% | 43.2s    | 5m 2.4s    | 21m 36s          | 4h 22m 48s       |
| 99.99% | 8.64s    | 1m 0.48s   | 4m 19.2s         | 52m 33.6s        |

The arithmetic is one multiplication: the period's length times `(100 − target) / 100`. A 30-day month is 2,592,000 seconds, so 99.9% leaves 0.1% of it, 2,592 seconds, which is 43 minutes 12 seconds. A 31-day month allows a little more than the table shows and February a little less; check which period your own contract measures. The [uptime calculator](https://fettle.sh/tools/uptime-calculator) prints the same ladder for any target you type, shortened to its two largest units, and works backwards from a downtime figure to the target it matches.

Two things the table makes obvious. First, the period matters as much as the target. A single two-hour outage blows a 99.9% month but fits comfortably inside a 99.9% year, so a monthly target is far stricter in practice than a yearly one with the same number. Second, the budget at four nines is small enough that one slow deploy rollback or one DNS change can spend it. Picking 99.99% is a decision about how you deploy, not only about how you host.

## What can a check interval actually measure?

A monitor sees a service only at the moments it checks it. An outage shorter than the check interval can start and end between two checks and leave no mark, and every outage it does catch is timed only to within one interval. The interval sets a floor on the uptime figures a monitor can tell apart.

Take a monitor that checks every 5 minutes. A 99.99% month allows 4 minutes 19.2 seconds of downtime, which is less than one interval. Any outage that short may fall entirely between two checks, so that monitor cannot distinguish a 99.99% month from a 100% one. It is a perfectly good monitor for a 99.5% target, whose 3 hours 36 minutes a month is dozens of intervals long, and the wrong instrument for four nines.

Shorter intervals help, but nothing makes the blind spot disappear. Fettle's shortest interval is 30 seconds, and a 10-second blip can still land between two checks at that cadence. The shortest interval each plan allows is every 3 minutes on Free, every minute on Plus and Pro and every 30 seconds on Max for up to 50 monitors (every minute for the rest); the details are on the [pricing page](https://fettle.sh/pricing).

Confirmation widens the gap on purpose. To keep one dropped packet from paging you, Fettle opens an incident only after a failure is confirmed across a set number of consecutive check rounds, a setting from 1 to 10 per monitor. With a threshold of 2 and a 5-minute interval, an outage has to outlast at least two checks before it counts as downtime at all. That trades sensitivity for fewer false alarms, and it is the right trade for most teams, but it is one more reason a monitor at a slow cadence cannot vouch for a very strict target.

A practical rule: to report against a target, the check interval should be a small fraction of that target's monthly budget. For 99.9%, a one-minute interval leaves the budget more than 40 intervals long. For 99.99%, even 30 seconds leaves fewer than nine.

## How does Fettle calculate uptime?

Fettle computes uptime from incidents, not from the share of passing checks. Uptime over a window is one minus confirmed downtime divided by observed time. Downtime runs from the first failing check of a confirmed outage to the first check that sees the service answer again. Observed time is the time the monitor was actually being checked.

Each part of that definition has a consequence you can see in the numbers:

- **Only confirmed outages count.** A single failed check, or a failure seen from some regions but not all of them, never becomes downtime. Fettle's regional consensus opens an incident only when every region that recently reported sees the service down; how that works is in the [multi-region monitoring guide](https://fettle.sh/guides/multi-region-monitoring).
- **Partial is not down.** A failure seen in only part of the world, a lossy ping or a certificate close to expiry shows as degraded, which Fettle records separately and never subtracts from uptime. A slow answer is not degraded: it is up until it runs past the monitor's timeout, and then it fails as a timeout.
- **Paused time is not observed time.** A monitor that is paused, or that did not exist yet, does not drag the figure down or up for that stretch. The window starts when the monitor was created.
- **Maintenance counts as up.** Inside a [maintenance window](https://fettle.sh/guides/maintenance-windows) checks keep running, but no incident opens and any downtime period in progress ends when the window starts.
- **The figure is floored, not rounded.** Fettle shows uptime to two decimals and rounds down, so any downtime at all keeps a monitor below 100%, and a month with one minute of downtime reads 99.99%, never 100%.

The dashboard and the API report uptime over rolling 24-hour, 7-day and 30-day windows and as a day-by-day series, each with the downtime and observed seconds behind the percentage. The same figure drives [status pages](https://fettle.sh/status-page) and [uptime badges](https://fettle.sh/docs/badges), so the number on your public page is the one your team sees.

## Is an uptime percentage the same as an SLA?

No. An uptime percentage is a measurement of what happened over a window. An SLA is a contract: it defines what counts as downtime, the period it is measured over, what is excluded, and what the provider owes when the target is missed. The same 99.9% means very different things under two different contracts.

The differences are usually in the definitions:

- **What counts as down.** One contract counts any failed request; another counts only an outage that lasts five minutes or affects every region. Short blips that a monitor records may not count against the provider at all.
- **What is excluded.** Announced maintenance, outages the customer caused, and incidents in third-party dependencies are common exclusions. A month that looks like 99.8% on your monitor can be 100% under the contract.
- **The measurement period.** A monthly clause is broken by one bad afternoon; a quarterly or yearly one absorbs it.
- **The remedy.** Most SLAs pay out service credits, a share of that month's bill, not the cost of your outage. The target tells you how often to expect a breach, not what a breach costs you.

Fettle measures uptime; it does not sell an SLA and does not attach one to any plan. Use it to know what your own services delivered, and to check a provider's numbers against the definitions in their contract.

## What should you set as your target?

Pick the target from what an outage costs you and how you ship, then check that your monitoring can see it. A side project or an internal tool is well served by 99% to 99.5%. A product people pay for usually aims at 99.9%. Four nines needs redundancy, careful deploys and a check interval measured in seconds, not minutes.

Then work backwards. Turn the target into a monthly budget with the [calculator](https://fettle.sh/tools/uptime-calculator), choose a check interval that is a small fraction of it, and check from more than one place so a regional network fault does not spend the budget for you. The [uptime monitoring guide](https://fettle.sh/uptime-monitoring) covers the rest of the setup, from check types to alert routing, and the other [guides](https://fettle.sh/guides) go deeper on each part.

## Questions

- How much downtime does 99.9% uptime allow?

  1 minute 26.4 seconds a day, 10 minutes 4.8 seconds a week, 43 minutes 12 seconds in a 30-day month and 8 hours 45 minutes 36 seconds in a 365-day year.

- Is 99.9% uptime the same as a 99.9% SLA?

  No. The percentage is a measurement. An SLA is a contract that defines what counts as downtime, over which period it is measured, what is excluded and what the provider owes when it misses. Two services at 99.9% can sit under very different contracts.

- Can a monitor that checks every 5 minutes prove 99.99% uptime?

  No. A 99.99% month allows 4 minutes 19.2 seconds of downtime, less than one 5-minute interval. Outages that short can fall entirely between two checks, so the monitor cannot tell a 99.99% month from a perfect one.

## Try it by hand first

- [Uptime / SLA calculator Convert an availability target into the downtime it allows per day, week, month and year, or work back from downtime. 99.9% is 43 minutes a month.](https://fettle.sh/tools/uptime-calculator)

## Related guides

- [What is uptime monitoring? A developer's guide Uptime monitoring checks your sites, APIs and jobs from outside on a schedule and alerts you when they stop answering. How checks, regions and alerts work.](https://fettle.sh/uptime-monitoring)
- [Set up uptime monitoring from Claude Code or Codex Connect Claude Code or Codex to Fettle over MCP, then let the agent create monitors and heartbeats, silence a deploy and triage an outage in the terminal.](https://fettle.sh/guides/uptime-monitoring-with-ai-agents)
- [Multi-region uptime checks: how regional consensus stops false alerts How multi-region uptime monitoring decides a site is down: why Fettle needs every fresh region to agree, what a partial failure shows, and the trade-off.](https://fettle.sh/guides/multi-region-monitoring)
- [API health check monitoring: design a /health endpoint worth watching How to design an API health check endpoint worth monitoring, from shallow vs deep checks to status codes, then watch it with status and keyword checks.](https://fettle.sh/guides/api-health-check-monitoring)
- [Uptime alerts in Slack, Discord or a webhook Send downtime alerts to Slack, Discord, Telegram or your own signed webhook: what triggers an alert, what stays quiet, and how repeats and recovery work.](https://fettle.sh/guides/uptime-alerts-slack-discord-webhook)
- [Maintenance windows: silence alerts, keep checking How maintenance windows stop deploy alerts while checks keep running: one-off or recurring, timezones, uptime, and opening one from CI or an agent.](https://fettle.sh/guides/maintenance-windows)
- [TCP port and DNS monitoring: checks below HTTP Watch databases, mail servers and SSH with TCP port checks, catch a database port left open to the internet, and alert when a DNS record changes.](https://fettle.sh/guides/tcp-port-and-dns-monitoring)
- [How to monitor an MCP server Check a remote MCP server with an HTTP POST that sends a real JSON-RPC request, and a local stdio server with a heartbeat behind a scheduled smoke test.](https://fettle.sh/guides/monitor-mcp-server)

## Use cases

- [How to monitor a cron job with a heartbeat A cron job that stops running fails no request and throws no error. Here is how a heartbeat monitor catches the silence and alerts you before users notice.](https://fettle.sh/use-cases/cron-job-monitoring)
- [How to catch SSL certificate expiry before it hurts Renewal is automated and mostly works, which is exactly why nobody notices when it quietly stops. Here is what to monitor and how to get warned early.](https://fettle.sh/use-cases/ssl-expiry-monitoring)

## Start monitoring in a minute

The free plan checks up to 20 monitors as often as every 3 minutes from 1 region, and emails you when one breaks. See [pricing](https://fettle.sh/pricing) for the paid intervals, or follow the [quickstart](https://fettle.sh/docs/quickstart) to do it from the API.

[Start free](https://fettle.sh/register)