---
title: "99.5 uptime calculator: downtime per month | Logdash"
description: "99.5% uptime is 7m 12s of downtime a day, 3h 39m 9s a month and 43h 49m 48s a year. The exact numbers per period, the formula, and how to measure it."
url: https://logdash.io/tools/99-5-uptime
---

# 99.5 uptime calculator

99.5% uptime allows 7m 12s of downtime per day, 50m 24s per week, 3h 39m 9s per month, 10h 57m 27s per quarter and 1d 19h 49m 48s per year, and the calculator on this page does the same sum for any percentage you type.

**99.5%** uptime allows **1d 19h 49m 48s** of downtime a year.

| Period  | Downtime allowed |
| ------- | ---------------- |
| Day     | 7m 12s           |
| Week    | 50m 24s          |
| Month   | 3h 39m 9s        |
| Quarter | 10h 57m 27s      |
| Year    | 1d 19h 49m 48s   |

99.5% sounds close to 100\. It is 0.5% of the clock, and 0.5% of a year is almost two full days. That is the budget: every failed deploy, every reboot for a kernel patch and every hour your host spends on someone else's incident comes out of the same 43h 49m 48s.

## 99.5 uptime per day, week, month, quarter and year

- Per day: 7m 12s of downtime, out of 1,440 minutes.
- Per week: 50m 24s.
- Per month: 3h 39m 9s, using the average month of 30.44 days.
- Per quarter: 10h 57m 27s.
- Per year: 1d 19h 49m 48s, which is 43h 49m 48s.

The year is 365.25 days so leap years average out, and a month is a twelfth of that, 730.5 hours. Contracts often measure the calendar month instead, and then the number moves: 3h 21m 36s in a 28-day February, 3h 36m in a 30-day month, 3h 43m 12s in a 31-day one. Check which one your SLA uses before you argue about a credit.

## The formula the calculator runs

Allowed downtime is the length of the period times the share of it you may be down: `period x (1 - 99.5 / 100)`. Paste this into Node or a browser console and change the percentage on the last line.

 downtime.js 

```javascript
const YEAR = 365.25 * 24 * 3600; // seconds in an average year
const PERIODS = {
  day: 86400,
  week: 7 * 86400,
  month: YEAR / 12,
  quarter: YEAR / 4,
  year: YEAR,
};

const fmt = (seconds) => {
  const s = Math.round(seconds);
  return `${Math.floor(s / 3600)}h ${Math.floor((s % 3600) / 60)}m ${s % 60}s`;
};

function allowedDowntime(percent) {
  const down = (100 - percent) / 100;
  return Object.fromEntries(
    Object.entries(PERIODS).map(([name, seconds]) => [
      name,
      fmt(seconds * down),
    ]),
  );
}

console.log(allowedDowntime(99.5));
// {
//   day: '0h 7m 12s',
//   week: '0h 50m 24s',
//   month: '3h 39m 9s',
//   quarter: '10h 57m 27s',
//   year: '43h 49m 48s'
// }
```

## 99.5 uptime per month, counted in checks

A monitor turns the percentage into a count you can watch. At one check every 5 minutes a month holds 8,766 checks, and 99.5% lets 43 of them fail. At one check a minute it is 43,830 checks and 219 failures. At every 15 seconds, 175,320 checks and 876 failures.

The interval also decides how much budget you burn before anyone knows. A full outage that starts just after a 5-minute check runs up to 5 minutes unseen, which is 69% of the 7m 12s daily allowance. At 15 seconds the blind spot is about 3.5% of it.

## 99.5 availability next to the other tiers

- 99%: 7h 18m 18s per month. A bad Saturday.
- 99.5%: 3h 39m 9s per month. One slow migration and a host incident.
- 99.9%: 43m 49.8s per month. One rollback, if you notice fast.
- 99.95%: 21m 54.9s per month. Needs automatic failover or a lot of luck.

99.5 is an honest target for a side project or an early SaaS on one VPS with no failover. It is too loose for anything taking payments, where a 3-hour hole in a single month reads as broken to the customer it hits. The Logdash classic uptime badge agrees: anything from 99% to just under 99.9% renders amber, not green.

### Logdash vs uptime.is

| Feature                                      | Logdash                                             | uptime.is              |
| -------------------------------------------- | --------------------------------------------------- | ---------------------- |
| Downtime per day, week, month, quarter, year | Yes, average month of 730.5 hours                   | Yes, same periods      |
| SLA measured only in business hours          | No, 24/7 only                                       | Yes, hours per weekday |
| Measures the uptime you actually deliver     | HTTP checks every 5 minutes free, 15 seconds on Pro | Calculator only        |

### When uptime.is is the better pick

- Your SLA only counts office hours, say 9 to 5 on weekdays. uptime.is lets you set the hours per weekday and Logdash does not.
- You want to work backwards from minutes of downtime to a percentage. uptime.is has a reverse mode built for exactly that.

## Measure the 99.5 you actually get

1. **Add the URL** Create a service in Logdash and give its monitor your health endpoint. Every check stores the status code and response time, and uptime is the share of checks that came back 200-399.
2. **Pick the interval** Every 5 minutes free, every minute on Builder, every 15 seconds on Pro. For a 7m 12s daily budget, a minute is the slowest interval that still leaves room to react.
3. **Break it once** Return a 503 from the endpoint. The next check flips the monitor to down and a Telegram alert lands with the status code, then a second one when it recovers.

### How much downtime is 99.5 uptime? 

7m 12s per day, 50m 24s per week, 3h 39m 9s per month, 10h 57m 27s per quarter and 1d 19h 49m 48s per year, with a 365.25-day year and a month of a twelfth of it.

### What is 99.5 uptime per month? 

3h 39m 9s in an average month of 730.5 hours. In a calendar month it is 3h 21m 36s for February, 3h 36m for a 30-day month and 3h 43m 12s for a 31-day month.

### Is 99.5 availability good enough? 

For a side project or an internal tool, yes. For a product people pay for, 3 hours in one month is long enough that they notice and ask. Most paid SaaS aims for 99.9%, which is 43m 49.8s a month.

### How do I measure 99.5 uptime? 

Point an HTTP monitor at a health endpoint and divide successful checks by total checks. Use an interval of a minute or shorter, because a 5-minute gap can hide most of a day's 7m 12s budget before the first failed check.

## Keep reading

[All free tools](https://logdash.io/tools): One page per tool, each with the tool itself, the command or formula behind it and a monitor that keeps checking after you leave.

[SLA calculator](https://logdash.io/tools/sla-calculator): The SLA calculator turns an SLA percentage into the downtime it allows per day, week, month, quarter and year, and multiplies the SLAs of every service in your request path into the composite SLA you can actually promise.

[Downtime cost calculator](https://logdash.io/tools/downtime-cost-calculator): The downtime cost calculator multiplies the length of the outage by your revenue per hour and by what the people fixing it cost per hour, and the formula below adds the customers who leave and any SLA credits, so you get one number for one outage.

[Incident postmortem template](https://logdash.io/tools/incident-postmortem-template): Copy the blameless template below into a markdown file within 48 hours of the incident, fill the timeline from your alert timestamps in UTC, and end it with at most three action items that each have an owner and a date.

[Uptime monitoring](https://logdash.io/features/monitoring): HTTP checks as often as every 15 seconds. When one fails, Telegram tells you before your users do.