Uptime Calculator

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

Period	Allowed downtime
{{ p.label }}	{{ p.readable }}

Service availability is the share of time a system can serve requests within a chosen window, and it guides how much interruption you can tolerate before missing your target. Many teams plan with an uptime error budget calculator so they can translate a percentage goal into minutes and seconds they may spend on incidents or maintenance.

Set an availability target, choose the evaluation period, then account for outages and planned work. The result shows allowed downtime, how much you have used, and the burn percent that signals whether you are on track or at risk.

For example, a target of 99.9 for 30 days allows 43 minutes and 12 seconds. If you have 20 minutes of unplanned downtime and 10 minutes of maintenance, you have 13 minutes and 12 seconds remaining, so the budget is about two thirds consumed.

Short windows can be noisy and policies differ on what counts as exempt maintenance, so compare like with like and keep unit choices consistent for fair trends over time.

Technical Details:

The calculation observes availability over a fixed period. Inputs are a target availability percentage, a period length with units, and two time quantities measured in seconds, minutes, or hours for outages and planned maintenance. In reliability language these reflect a Service Level Indicator (SLI) over a window and a Service Level Agreement (SLA) target.

The core idea is to convert the target into an error budget, which is the total allowed downtime during the period. Effective downtime is the sum of unplanned incidents and planned work. Comparing effective downtime to the budget yields remaining seconds and a burn percent that rises from zero toward one hundred as the budget is consumed.

When the burn percent reaches or exceeds one hundred, the budget is exhausted and further interruptions will breach the target. Values very near the boundary are sensitive to rounding, so interpret them with a small margin in mind.

Comparability assumes consistent definitions for downtime and maintenance across periods. Results are descriptive for the selected window and do not generalize to different windows without recalculation.

\begin{array}{lll} Allowed & = & Period \times (100 - Target) / 100 \\ Effective & = & Downtime + Maintenance \\ Remaining & = & \max (Allowed - Effective, 0) \\ Burn % & = & \frac{Effective}{Allowed} \times 100 (Allowed > 0, else 0) \end{array}

Symbols and units
Symbol	Meaning	Unit/Datatype	Source
A	Availability target	percent	Input
T	Period duration	seconds	Derived from value and unit
$D_{o}$	Unplanned downtime	seconds	Input
$D_{m}$	Planned maintenance	seconds	Input
E	Effective downtime	seconds	Derived
$B_{rem}$	Error budget remaining	seconds	Derived
$P_{burn}$	Burn percent	percent	Derived

Worked example.

\begin{array}{l} T & = & 30 \times 86400 = 2, 592, 000 s \\ Allowed & = & 2, 592, 000 \times (100 - 99.9) / 100 = 2, 592 s \\ E & = & 20 min + 10 min = 1, 800 s \\ B_{rem} & = & 2, 592 - 1, 800 = 792 s (13 min 12 s) \\ P_{burn} & = & \frac{1}{800} / \frac{1}{2} \approx 69.44 % \end{array}

Interpretation: budget remaining is positive, so the target is still achievable for this window.

Units, precision & rounding:

Durations convert by 1 min = 60 s, 1 h = 3600 s, 1 day = 86400 s, 1 week = 604800 s, 1 year = 31536000 s.
Human‑readable durations round to the nearest second; minutes and hours display leftover parts when non‑zero.
Percentages show with two decimals; the SLA target displays with three decimals in the metrics table.
Decimals use a period as the separator.

Validation & bounds (from inputs):

Input validation
Field	Type	Min	Max	Step/Pattern	Units / Options
SLA target	number	90	100	0.001	percent
Period length	number	1	—	integer	seconds, minutes, hours, days, weeks, years
Downtime experienced	number	0	—	integer	seconds, minutes, hours
Planned maintenance	number	0	—	integer	seconds, minutes, hours

I/O formats & encoding:

Inputs and outputs
Input	Accepted Families	Output	Encoding/Precision	Rounding
Availability target	Numeric percent	Percentages	Two decimals	Fixed at 2 decimals
Period, downtime, maintenance	Numeric duration with unit	Human‑readable durations	Seconds, minutes, hours, days	Nearest second
Aggregates	Computed values	Tables, chart, CSV, JSON	As displayed	As above

Networking & storage behavior:

Processing is browser‑based; calculations happen locally.
Copy operations use the system clipboard when permitted by the browser.
Downloads are generated as local files from in‑memory data.

Performance & complexity:

All computations are constant‑time with negligible memory.
Input changes are debounced by about 40 ms for responsive updates.
Chart rendering is lightweight for two slices representing used and remaining budget.

Diagnostics & determinism:

Identical inputs produce identical results.
Percent and duration formatting follow fixed rules for repeatable displays.
If allowed downtime is zero, burn percent is defined as zero.

Assumptions & limitations:

Heads‑up One year is treated as 365 days; leap days are not considered.
Weeks are seven days exactly.
Planned maintenance is counted toward effective downtime.
Only one period window is evaluated at a time.
Availability target must be between 90 and 100 inclusive.
Negative durations are not accepted.
Minute and hour inputs assume uniform seconds per unit.
Sub‑second events are not represented.
Exemptions or partial credit policies are not modeled.
Time zone and business hours are not considered.
No distinction between partial and total service degradation.
Rounding may mask very small residuals in displays.

Edge cases & error sources:

SLA at 100 % yields zero allowed downtime; any non‑zero downtime implies a breach, but burn percent displays as zero.
Very small budgets amplify small timing errors.
Mistaken units, such as hours for minutes, inflate results.
Clock skew across systems can misstate incident lengths.
Rounding to seconds may hide brief flaps.
Copying results without units can mislead downstream readers.
Chart legend order may be misread if values are small.
Clipboard permissions can block copy actions silently.
Browser locale settings do not affect decimal parsing; use a period.
Zero‑length periods are invalid and produce no metrics.
Large periods with tiny budgets may show percentages as 0.00 % until consumed.
Maintenance classified incorrectly as downtime will skew comparisons.
Input debounce can delay rapid successive edits briefly.
Manual CSV edits can drop non‑breaking spaces from duration text.

Scientific & standards backing:

Concepts align with common reliability practice for availability, error budgets, and service level targets in operations engineering. Availability is a quality attribute recognized in software quality models.

Privacy & compliance:

No data is transmitted or stored server‑side; copies and downloads are initiated by the user within the browser session.

Step‑by‑Step Guide:

Availability budgeting, from inputs to a clear result.

Enter the availability target as a percentage.
Set the period value and pick its unit.
Add downtime for unplanned incidents.
Add planned maintenance if you track it against the budget.
Review allowed downtime, remaining budget, and burn percent.
Watch for zero allowed time at a 100 % target.

Example: Target 99.9, period 30 days, outages 20 minutes, maintenance 10 minutes → burn about 69.44 % with 13 min 12 s remaining.

Presets provide allowed downtime for common windows like 1 hour, 1 day, and 30 days.

Use the burn percent to decide whether to defer maintenance or tighten incident response.

FAQ:

Is my data stored?

No. All calculations run locally and outputs are generated within your browser session.

How accurate is the estimate?

It converts your inputs exactly, then rounds displayed durations to the nearest second and percentages to two decimals.

What units can I enter?

Durations accept seconds, minutes, or hours. The period accepts seconds, minutes, hours, days, weeks, or years.

Does maintenance consume the budget?

Yes. Effective downtime is outages plus maintenance. Adjust your policy if you treat some work as exempt.

Can I use it without connectivity?

Yes. Once loaded, calculations and result generation do not require network access.

Is there a cost or license?

The calculator’s terms follow the hosting site. There are no usage‑based meters in the computation itself.

How do I compute 99.99 for a quarter?

Set the target to 99.99, choose 90 days as the period, and read the allowed downtime and burn percent from the results.

What does a “borderline” result mean?

When remaining time is close to zero, small timing changes or rounding can flip the outcome. Treat it as at risk.

Troubleshooting:

Inputs set to different units than intended.
Target at 100 % shows no allowed time.
Copy to clipboard fails due to browser permissions.
CSV or JSON not opening with your default app.
Chart not visible until the tab is opened.
Very long periods produce large numbers that are hard to scan.

If no values appear, ensure the period is at least 1 in any supported unit and the target is between 90 and 100.

Advanced Tips:

Tip Track a rolling 30‑day window for steadier comparisons.
Tip Split maintenance into exempt and counted buckets for policy clarity.
Tip Pair burn percent with incident count to reflect impact and frequency.
Tip Normalize to seconds internally, then format for display only.
Tip Use presets to benchmark targets across common periods.
Tip Treat partial degradations consistently so comparisons stay fair.

Glossary:

Availability: Fraction of time service can meet requests in a window.
SLA: Service Level Agreement, the contractual target.
SLI: Service Level Indicator, the measured metric.
Error budget: Allowed downtime implied by the target.
Burn percent: Share of the error budget consumed.
Downtime: Unplanned service unavailability.
Maintenance: Planned work that reduces availability.
Window: The evaluation period for the calculation.