Uptime Calculator

Allowed Downtime Budget

for {{ periodLabelReadable }} · {{ selectedTierLabel }}

{{ effectiveDowntimeReadable }} used {{ budgetStatusBadgeText }} {{ errorBudgetBurnPercent.toFixed(2) }}% budget used {{ burnPaceBadgeText }} {{ achievedAvailabilityPercent.toFixed(3) }}% achieved

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

Availability percentages look generous until they are translated into time. A 99.9% target over 30 days allows 43 minutes and 12 seconds of unavailability. Moving to 99.99% over the same window leaves 4 minutes and 19 seconds, so one short incident can consume an entire month of room.

The useful question is not only how long a service was down. Uptime reviews also need to know the reporting window, the target being tested, whether scheduled maintenance is charged, and how much of the window has already elapsed. A service can look healthy on a yearly chart while already missing a weekly or monthly commitment, and a maintenance window can be harmless or budget-breaking depending on the policy language attached to it.

Common availability terms used in uptime reviews
Term	Plain meaning	Why it changes the calculation
SLI	The service level indicator, such as time available or successful request share.	The measured signal decides whether the review is time-based or request-based.
SLO	The service level objective, or the internal target for the measured signal.	The target sets the unavailable fraction that becomes the downtime budget.
SLA	The service level agreement, often a customer-facing promise with credit rules.	Contract wording may define exclusions, measurement windows, and remedies differently from engineering reports.
Error budget	The allowed failure or unavailable time before a target is missed.	Burning the budget early leaves less room for incidents later in the period.

Thirty day downtime budgets shrink as availability targets move from two nines to five nines

Time-based availability and request-based availability are related, but they answer different questions. A clock-based budget treats unavailable minutes as the unit of failure. A request-yield budget treats failed operations as the unit of failure, which can be more accurate for distributed services that degrade in one region, fail only for some users, or carry uneven traffic during the day.

Burn pace adds timing to the same budget. Ten minutes of charged downtime early in a window is more urgent than ten minutes near the end because the remaining period still has time to accumulate incidents. Pace does not predict future failures; it shows whether the current rate of budget use would finish inside or outside the selected target if it continued.

Availability math is a planning aid, not a substitute for monitoring data or contract review. The result is most useful when incident records, maintenance rules, and reporting windows are already agreed, and least useful when those definitions are still disputed.

How to Use This Tool:

Use the calculator to match a target, a reporting window, and the downtime that should count against that window.

Set SLA target, or choose a Preset such as 99.9%, 99.99%, or 99.999%. Editing the target after choosing a preset switches the target back to custom.
Set Reporting period in hours, days, weeks, or years. The summary should show an Allowed Downtime Budget once the period is greater than zero.
Enter Downtime logged for unplanned incident time, using seconds, minutes, or hours. This time is always charged to Policy effective downtime.
Open Advanced when scheduled 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. If elapsed time is 0%, those pace results intentionally report that more elapsed period is needed.
Add Incident count only when MTTR and mean time between incidents help explain whether downtime came from one long incident or several smaller interruptions.
Review Run-Rate Guidance first for the plain-language status, then use Budget Metrics, Downtime Lookup, Budget Mix Chart, Target Ladder Chart, or JSON when you need a table, chart, or exportable record.

If the result looks missing or implausible, check that the period is positive, units match the incident record, and downtime or maintenance values have not been entered in hours when the source record was in minutes.

Interpreting Results:

The main decision is whether Policy effective downtime is less than or equal to Allowed downtime. A positive Remaining budget means the selected target still passes for the entered values. A positive Over budget means the target is already missed for that reporting period and maintenance policy.

Burn pace compares budget consumed with period elapsed. A pace near 1.00x means budget use is roughly matching time progress, a value above 1.00x is spending the budget faster than the window is passing, and a value above 1.20x is treated as a danger signal. A warning can also appear when less than 10% of the allowed downtime remains.

Uptime output fields and interpretation cues
Output	Meaning	Verification cue
`Allowed downtime`	The full downtime budget for the selected target and period.	Confirm the reporting window matches the SLA or SLO review window.
`Policy effective downtime`	Unplanned downtime plus the counted share of planned maintenance.	Check the maintenance rule before treating this as a contractual result.
`Observed availability (raw)`	Availability after unplanned downtime plus all planned maintenance.	Compare it with policy availability when customers experienced the maintenance window.
`Projected period-end availability`	A straight-line projection from current downtime and elapsed period.	Use it as a pace check, not as a forecast of future incidents.
`Best common tier met`	The highest common 99.x target currently satisfied by policy availability.	Do not replace the selected target with this label if the commitment names a different target.

A passing policy result can still hide a customer-visible interruption when planned maintenance is exempt. When the review concerns user impact, compare Achieved availability (policy), Observed availability (raw), and the incident timeline before concluding that the period was healthy.

Technical Details:

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

Maintenance policy changes the numerator, not the target. Raw interruption includes unplanned downtime and all planned maintenance. Policy effective downtime includes unplanned downtime plus only the maintenance share selected by the policy. That distinction lets a review show both what users experienced and what the selected rule counts against the budget.

Formula Core:

The arithmetic is seconds-based. Durations are converted to seconds, the allowance is calculated from the target, and derived percentages are displayed from those totals.

\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 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%; pace is unavailable when this is 0%.

For a 99.9% target over 30 days, the period is 2,592,000 seconds and the unavailable fraction is 0.001. The 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%, effective downtime is 24 minutes, so budget used is 55.56%.

Status Rules:

Uptime budget status rules
Status	Boundary	Meaning
Within budget	`Effective downtime <= Allowed downtime`	The selected target still passes.
Over budget	`Effective downtime > Allowed downtime`	The target is missed for the current inputs.
Low remaining budget	`Remaining budget <= 10%` of allowed downtime.	The target passes, but little room remains.
Warning pace	`Burn pace > 0.9` and `<= 1.2`.	The current downtime rate is close to or above 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 same target against fixed comparison periods of 1 hour, 1 day, 1 week, 30 days, 90 days, and 1 year. Target comparisons use common 99.x commitments plus the selected target. Durations are rounded to whole seconds for readable output, percentages show policy availability to three decimals, and budget burn shows two decimals.

Limitations and Privacy Notes:

The calculator uses the numbers entered in the browser and does not connect to monitoring systems, billing records, status pages, or contract repositories. It is a time-based uptime calculator, so it cannot decide every reliability question by itself.

Calendar nuance is simplified: a year is 365 days, a week is 7 days, and fixed 30 day or 90 day lookup rows are not named calendar months.
Request-weighted availability, partial regional outages, degraded performance, retries, and customer-specific exclusions need separate analysis.
SLA credit disputes depend on contract wording, evidence, notice periods, and exclusions, not only on downtime arithmetic.
Input values are calculated locally in the page; no live service account 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. Enter 18 minutes of Downtime logged, 12 minutes of Planned maintenance, Maintenance counted at 50%, Period elapsed at 60%, and 3 incidents. Policy effective downtime is 24 m, Remaining budget is 19 m 12 s, budget burn is 55.56%, and burn pace is 0.93x. MTTR is 6 m, and mean time between incidents 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 pushes the window roughly 5 m over budget, with budget burn near 595.24%. The outage is short in human 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 only 5 m and 16 m 36 s remains. Observed availability (raw) is lower because users still experienced the full 35 minutes of interruption.

Elapsed period set to zero

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

FAQ:

Does planned maintenance always count as downtime?

No. The calculation separates raw interruption from policy effective downtime. Use Maintenance counted at 0% when scheduled 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 from the scored result.

Does incident count change whether the target passes?

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

Is five nines always the better target?

Not always. A higher target leaves less downtime budget and often requires more redundancy, monitoring, recovery work, and operational cost. The useful target is the one that matches user need, business risk, and the system's realistic design.

Can the result settle an SLA credit claim?

No. The calculator shows uptime arithmetic for the values entered. 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, 2017.
Availability Table, Google SRE Book, 2017.
A Collection of Best Practices for Production Services, Google SRE Book, 2017.
Availability, AWS Well-Architected Reliability Pillar.
Availability, NIST CSRC Glossary.