Uptime calculator · SLA arithmetic

What your nines actually allow.

Everyone agrees to 99.9% before anyone works out what it permits: 43 minutes a month. Pick a target below and read the budget — then watch what your check interval takes out of it before a human has even been told.

Downtime budget
per day
per week
per 30-day month
per quarter
per year
The part nobody prices in

Detection spends the budget too.

An outage is not over when you fix it. It starts when the service breaks — including the part where nobody knows yet.

The worst case is simple: the service fails just after a check succeeds, so you wait a full interval before the next one looks. Our confirmation adds a couple of seconds on top — the first failure dispatches two immediate parallel re-checks rather than waiting for the next scheduled one.

That number is dead time you cannot spend on the fix. At a five-minute interval it is five minutes of a 43-minute monthly budget before anyone reaches for a laptop — and against a 99.99% target, one undetected outage is the whole month.

This is the honest argument for a short interval, and it is also why we price intervals instead of gating them: 10 seconds is available on every plan, and the meter tells you what it costs before you save.

The reference

Every common target, worked out.

Calendar convention: a month is 30 days, a year is 365. Percentages are of wall-clock time, which is how an SLA counts unless it says otherwise.

TargetPer dayPer weekPer monthPer year

Generated from the same arithmetic as the calculator above, so the two cannot drift.

FAQ

SLA questions, answered plainly

Which target should I promise?
Promise the one you can survive breaking. 99.9% is the honest default for a small team: 43 minutes a month absorbs a bad deploy and a reboot. 99.99% is 4 minutes 19 seconds a month — that is not a monitoring target, it is an architecture commitment, and it needs redundancy you can fail over to without a human. Promising a nine you cannot hold costs more than the nine was worth.
Does planned maintenance count?
Only if your SLA says it does — and most say it does not, provided you announce a window in advance. That is a real reason to run a status page with scheduled maintenance: an announced window is excluded, an unannounced one is downtime. What we measure is what actually happened; which minutes you exclude is your contract’s business.
Is up4 measuring the same thing my SLA means?
Close, and worth checking. We record whether your endpoint answered correctly from our probes, confirmed by three consistent observations before we call it down. An SLA usually means “the service was usable”, which can differ — a page that returns 200 while checkout is broken is up by our measure and down by your customers’. Keyword checks close most of that gap.
What about slow instead of down?
We separate them. A response that arrives late is degraded, not down: it is recorded and visible, but nobody is paged for a sluggish server. Whether degraded time counts against your budget is your policy, and the reporting can mask it either way.
Can up4 report against a target automatically?
Yes. SLA policies let you set the target and the business hours it applies to, and the monthly report shows the achieved percentage, the error budget consumed and every incident that spent it — as a PDF you can hand over without editing.
Why is a 30-day month the convention here?
Because the alternative is arguing about February. Thirty days is what the pricing meter uses too, so the availability figure and the cost figure are computed over the same period. Real reports are run over real calendar ranges.

Know the number before you promise it.

€3 credit · no card · 10-second checks on every plan