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.

PeriodDowntime allowed
Day7m 12s
Week50m 24s
Month3h 39m 9s
Quarter10h 57m 27s
Year1d 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
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

FeatureLogdashuptime.is
Downtime per day, week, month, quarter, yearYes, average month of 730.5 hoursYes, same periods
SLA measured only in business hoursNo, 24/7 onlyYes, hours per weekday
Measures the uptime you actually deliverHTTP checks every 5 minutes free, 15 seconds on ProCalculator 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.

Point it at your own URL and watch it for real.