Uptime Calculator

SLA target:

Enter 90-100%; common targets are 99.9, 99.99, and 99.999.

Reporting period:

Use hours, days, weeks, or years; a year is treated as 365 days.

Downtime logged:

Enter charged incident time from records; select seconds, minutes, or hours.

Preset:

Choose Custom for manual target, or a 99.x tier for quick budget lookup.

Planned maintenance:

Enter scheduled downtime duration; use 0 when no planned maintenance applies.

Maintenance counted: {{ maintenanceImpactPercentValue.toFixed(0) }}%

0% exempts maintenance; 100% charges all planned downtime.

Period elapsed: {{ elapsedPercentValue.toFixed(0) }}%

Set 0-100%; use 100% for a completed reporting window.

Incident count:

Enter distinct unplanned incidents, or 0 to skip incident metrics.

Metric	Value	Copy
{{ row.label }}	{{ row.value }}
No budget metrics available.

Signal	Value	Interpretation
Period elapsed	{{ elapsedPercentValue.toFixed(0) }}% · {{ elapsedPeriodReadable }}	{{ burnPaceNarrative }}
Budget consumed	{{ errorBudgetBurnPercent.toFixed(2) }}% · {{ effectiveDowntimeReadable }}	Current burn pace determines whether the selected availability target is still recoverable.
Projected availability	{{ projectedAvailabilityReadable }}	{{ projectionBalanceText }}
Budget exhaustion	{{ budgetExhaustionReadable }}	Best common tier met: {{ bestCommonTargetLabel }}; maintenance policy: {{ maintenancePolicyText }}.
{{ row.label }}	{{ row.value }}	{{ row.note }}

Period	Allowed downtime	Current burn	Status	Copy
{{ row.label }}	{{ row.readable }}	{{ row.burnText }}	{{ row.statusText }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

A high availability percentage only becomes useful when it is translated into time. Over a 30 day window, 99.9% availability allows 43 minutes and 12 seconds of downtime. In the same window, 99.99% allows 4 minutes and 19 seconds. The difference between three nines and four nines can be one short incident.

Uptime reviews depend on the measurement window as much as the target. A service may look healthy against a yearly goal while failing a weekly target, and a maintenance window may be excluded from one agreement but counted in another. The arithmetic is simple only after the organization has agreed what counts as downtime.

Availability planning terms for uptime budget reviews
Term	Plain meaning	Why it matters
SLI	Service level indicator, the signal being measured.	Time-based uptime and request success rate can tell different stories.
SLO	Service level objective, the internal reliability target.	The target creates an error budget for the period.
SLA	Service level agreement, often a customer-facing promise.	Contracts may define exclusions, credits, notice rules, and measurement sources.
Error budget	The amount of downtime or failure that can be spent before a target is missed.	Burning it early leaves little room for the rest of the period.

Availability is often described with the number of nines because the extra digits are easier to say than long percentages. That shorthand can hide how steep the tradeoff is. Each additional nine removes most of the downtime room and usually requires better redundancy, monitoring, incident response, maintenance planning, and dependency design.

Burn pace adds timing to the budget. Ten minutes of charged downtime in the first half of a reporting period is more urgent than ten minutes near the end because there is still more time left for incidents. Pace does not predict future outages; it shows whether the current rate would finish inside or outside the selected target if it continued.

Availability math is strongest when incident records, maintenance policy, and the reporting period are already agreed. It is weakest when a team is still debating whether a degraded service counted as down, whether customers were affected, or whether an exclusion applies.

How to Use This Tool:

Enter the target and period first, then decide which downtime should count against that period.

Set SLA target, or choose a Preset such as 99.9%, 99.99%, or 99.999%. Editing the target after a preset returns the target to custom.
Set Reporting period in hours, days, weeks, or years. A year is treated as 365 days, and the summary should show Allowed downtime once the period is positive.
Enter Downtime logged for unplanned incident time. Choose seconds, minutes, or hours to match the incident record before comparing the result.
Open Advanced when planned maintenance needs separate treatment. Enter Planned maintenance, then set Maintenance counted from 0% for exempt maintenance to 100% for fully charged maintenance.
Set Period elapsed before using Burn pace, Projected period-end availability, or Budget exhaustion. Pace results intentionally stay unavailable when elapsed time is 0%.
Add Incident count only when MTTR and mean time between incidents help explain whether downtime came from one long event or several smaller interruptions.
Use Run-Rate Guidance for the plain-language status, then switch to Budget Metrics, Downtime Lookup, Budget Mix Chart, Target Ladder Chart, or JSON when you need details or exports.

Interpreting Results:

The pass/fail check compares Policy effective downtime with Allowed downtime. Remaining budget means the selected target still passes for the current inputs. Over budget means the target is already missed for that window and maintenance policy.

Burn pace compares budget consumed with period elapsed. A pace near 1.00x means downtime is being spent at about the same rate as the period is passing. A pace above 1.00x is using the budget faster than the sustainable line, and a value above 1.20x is treated as a danger signal. A warning can also appear when 10% or less of the allowed downtime remains.

Uptime calculator output fields and interpretation cues
Output	Meaning	Check before relying on it
`Allowed downtime`	The full downtime budget implied by the selected target and period.	Confirm the reporting window matches the commitment being reviewed.
`Policy effective downtime`	Unplanned downtime plus the counted share of planned maintenance.	Verify the maintenance rule before treating the value as contractual.
`Observed availability (raw)`	Availability after unplanned downtime plus all planned maintenance.	Compare it with policy availability when user impact matters.
`Projected period-end availability`	A straight-line projection from current charged downtime and elapsed period.	Use it as a pace check, not as an outage forecast.
`Best common tier met`	The highest common 99.x target currently satisfied by policy availability.	Do not replace a named SLA or SLO target with this comparison label.

A passing policy result can still hide a customer-visible interruption when maintenance is exempt. For user-impact reviews, compare Achieved availability (policy), Observed availability (raw), and the incident timeline rather than reading only the status badge.

Technical Details:

Time-based availability uses the reporting period as the denominator and charged unavailable time as the numerator. The unavailable fraction is the complement of the availability target. A 99.9% target leaves 0.1% of the period for downtime, while 99.99% leaves 0.01%.

Maintenance policy changes the numerator. Raw interruption includes unplanned downtime plus all planned maintenance. Policy effective downtime includes unplanned downtime plus only the maintenance share counted by the selected policy. That split lets a review separate what users experienced from what the agreement charges to the budget.

Formula Core:

Durations are converted to seconds, budget values are calculated from the target, and readable durations are rounded to whole seconds for display.

\begin{array}{lcl} D_{allowed} & = & T_{period} \times (1 - \frac{A}{100}) \\ D_{effective} & = & D_{unplanned} + D_{maintenance} \times \frac{M}{100} \\ A_{policy} & = & \frac{T_{period} - D_{effective}}{T_{period}} \times 100 \\ B_{used} & = & \frac{D_{effective}}{D_{allowed}} \times 100 \\ P_{burn} & = & \frac{D_{effective} / D_{allowed}}{E / 100} \end{array}

Uptime formula symbols and units
Symbol	Meaning	Unit or boundary
`A`	Selected availability target.	Percent, clamped to the 0% to 100% calculation range.
`T_period`	Reporting period after unit conversion.	Seconds; 1 day is 86,400 seconds and 1 year is 365 days.
`M`	Share of planned maintenance charged to the budget.	0% to 100%.
`E`	Elapsed share of the reporting period.	0% to 100%; burn pace is unavailable at 0%.

For a 99.9% target over 30 days, the period is 2,592,000 seconds and the unavailable fraction is 0.001. Allowed downtime is 2,592 seconds, or 43 minutes and 12 seconds. With 18 minutes of unplanned downtime and 12 minutes of maintenance counted at 50%, policy effective downtime is 24 minutes and budget used is 55.56%.

Status Rules:

Uptime budget status and pace rules
Status	Boundary	Meaning
Within budget	`Effective downtime <= Allowed downtime`	The selected target still passes.
Over budget	`Effective downtime > Allowed downtime`	The selected target is missed for the current inputs.
Low remaining budget	`Remaining budget <= 10%` of allowed downtime.	The target passes, but little downtime room remains.
Warning pace	`Burn pace > 0.9` and `<= 1.2`.	Budget use is close to the sustainable line.
Danger pace	`Burn pace > 1.2`, or the window is already over budget.	The current rate would miss the target unless downtime slows.

Lookup rows reuse the selected target for fixed periods of 1 hour, 1 day, 1 week, 30 days, 90 days, and 1 year. Target ladder rows compare common 99.x targets plus the selected target, while MTTR uses unplanned downtime divided by incident count and MTBI uses the reporting period divided by incident count.

Limitations and Privacy Notes:

The calculator uses the values entered in the browser and does not connect to monitoring systems, billing records, status pages, or contract repositories. It is a time-based availability calculator, so it cannot settle every reliability or customer-impact question.

Calendar handling is fixed: a year is 365 days, a week is 7 days, and fixed 30 day or 90 day lookup rows are not calendar months or quarters.
Request-weighted availability, partial regional outages, degraded performance, retries, dependency failures, and customer-specific exclusions need separate analysis.
SLA credit decisions depend on contract wording, evidence, notice periods, exclusions, and measurement sources, not only on downtime arithmetic.
Entered values are calculated locally in the page; no live service account, status page, or incident feed is queried.

Worked Examples:

Three nines with partly counted maintenance

At 99.9% over 30 days, allowed downtime is 43 m 12 s. With 18 minutes of unplanned downtime, 12 minutes of planned maintenance counted at 50%, 60% of the period elapsed, and 3 incidents, policy effective downtime is 24 m. Remaining budget is 19 m 12 s, budget burn is 55.56%, burn pace is 0.93x, MTTR is 6 m, and MTBI is 10 d.

Four nines over one week

At 99.99% over 1 week, the downtime allowance is about 1 m. A 6 minute unplanned outage puts the window roughly 5 m over budget, with budget burn near 595.24%. The incident is short in ordinary terms, but it misses a four-nines weekly target.

Maintenance exempt from the scored result

At 99.95% over 30 days, allowed downtime is 21 m 36 s. With 5 minutes of unplanned downtime, 30 minutes of planned maintenance, and maintenance counted at 0%, policy effective downtime is 5 m and 16 m 36 s remains. Raw availability is lower because users still experienced the full 35 minutes of interruption.

Elapsed period set to zero

With Period elapsed at 0%, current budget status still calculates, but burn pace, straight-line projection, and budget exhaustion need elapsed time. Move the elapsed value above 0% when run-rate guidance matters.

FAQ:

Does planned maintenance always count as downtime?

No. Raw interruption includes all planned maintenance, but policy effective downtime counts only the selected share. Use 0% when maintenance is exempt, 100% when it is fully charged, or an intermediate value when policy splits the difference.

Why can policy availability be higher than raw availability?

Policy availability uses only the counted share of planned maintenance. Raw availability includes all planned maintenance plus unplanned downtime, so it can be lower when maintenance is partly or fully exempt.

Does incident count change whether the target passes?

No. Incident count only calculates MTTR and MTBI. Budget status comes from the target, reporting period, unplanned downtime, and counted maintenance.

Is five nines always the better target?

No. A higher target leaves less downtime budget and usually costs more to meet. The useful target is the one that matches user need, business risk, operational maturity, and system design.

Can this settle an SLA credit claim?

No. The result shows uptime arithmetic for the entered values. SLA credits depend on contract definitions, notice rules, exclusions, measurement sources, and customer impact evidence.

Glossary:

Availability target: The percentage of a reporting period expected to remain available, such as 99.9% or 99.99%.
Downtime budget: The allowed unavailable time implied by an availability target and reporting period.
Error budget: The reliability room that can be spent on failures or downtime before a target is missed.
Policy effective downtime: Unplanned downtime plus the counted share of planned maintenance.
Raw interruption: Unplanned downtime plus all planned maintenance, regardless of whether policy exempts it.
Burn pace: Budget consumption compared with the elapsed share of the reporting period.
MTTR: Mean time to repair, calculated here as unplanned downtime divided by incident count.
MTBI: Mean time between incidents, calculated here as the reporting period divided by incident count.

References:

Service Level Objectives, Google SRE Book.
Table for Service Availability, Google SRE Book.
Availability, AWS Well-Architected Reliability Pillar.
Availability, NIST CSRC Glossary.