Uptime Calculator

Introduction

Availability targets sound close together until you convert them into actual downtime. Over 30 days, 99.9% leaves 43 minutes and 12 seconds of tolerance. Over the same span, 99.99% leaves only about 4 minutes and 19 seconds. That is why reliability reviews work better with a downtime budget than with a bare percentage.

This calculator turns a selected uptime target and reporting period into an allowed downtime budget, then compares that budget with the unplanned downtime and planned maintenance you enter. The headline summary shows how much budget was available, how much charged downtime has been used, how much remains or has been exceeded, and what availability the current window has achieved.

The advanced controls make the result more useful than a simple percentage conversion. You can load common 99.x presets, decide how much planned maintenance should count against the budget, set how much of the reporting window has already elapsed so the page can judge burn pace, and add incident count to derive mean time to repair and mean time between incidents.

Use it for monthly service reviews, pre-maintenance checks, post-incident summaries, or side-by-side target comparisons. Treat it as an engineering aid rather than a provider-specific contract ruling. Real service agreements can define downtime, retries, exclusions, and measurement windows in ways that this calculator does not model. The calculation, charts, copying, and file exports all stay in the browser session.

Technical Details

The main input is labeled SLA target, but the arithmetic is the same whether you are checking an internal service-level objective, a customer-facing uptime promise, or a draft maintenance policy. The page converts the selected period into seconds, computes the allowed downtime from the target, and then compares that allowance with the downtime that your policy says should count.

period_seconds = selected period converted to seconds
allowed_downtime = period_seconds × (1 - target / 100)
weighted_maintenance = planned_maintenance × (maintenance_counted / 100)
effective_downtime = unplanned_downtime + weighted_maintenance
policy_availability = ((period_seconds - effective_downtime) / period_seconds) × 100
raw_availability = ((period_seconds - raw_interruption) / period_seconds) × 100
burn_pace = (effective_downtime / allowed_downtime) ÷ elapsed_share

Two availability values matter because the page keeps raw interruption separate from charged downtime. Observed availability (raw) uses unplanned downtime plus the full maintenance duration. Achieved availability (policy) uses unplanned downtime plus only the maintenance share that you choose to count. When maintenance is fully exempt, those two values can diverge sharply.

The page exposes that model through several views. Budget Metrics lists the detailed ledger, including remaining budget, over-budget amount, policy and raw availability, projected period-end balance, best common tier met, and incident-derived metrics. Run-Rate Guidance turns the same numbers into a pace summary. Downtime Lookup recalculates the allowed downtime for fixed windows of 1 hour, 1 day, 1 week, 30 days, 90 days, and 1 year. Target Charts draws a Budget Mix donut and a Target Ladder comparison chart.

Time handling is intentionally simple and fixed. Hours, days, weeks, and years are converted with constant second values, so a year is treated as 365 days and a week as 7 days. The calculator does not model leap years, provider-specific billing months, rolling-window data aging, retry clauses, or narrow legal definitions of downtime.

Export behavior is equally direct. The metrics table and lookup table can be copied or downloaded as CSV and exported as DOCX. Both charts can be saved as PNG, WebP, JPEG, or CSV. The JSON pane includes the current inputs, raw totals in seconds, readable summaries, guidance rows, lookup rows, and target-comparison rows, all generated locally from the current state.

Everyday Use & Decision Guide

Start with the reporting window you actually use. If your team reviews availability every 30 days, enter 30 days. If the commitment is weekly, enter 1 week instead. The same outage can look minor under a 99.0% weekly target and fatal under a 99.99% weekly target, so the window and the target have to match the decision you are making.

Enter unplanned downtime first because that is the part most teams always charge. Add planned maintenance only when you need to see how policy changes the reading. Set Maintenance counted to 0% when maintenance is exempt, 100% when it is fully charged, or any middle value when your review process counts only part of it. Then compare policy availability with raw availability before you explain the result to someone else.

Set Period elapsed before you rely on pace or projection. If half the period has elapsed and half the budget is gone, the current pace is roughly sustainable. If only 20% of the period has elapsed but 70% of the budget is gone, the run-rate guidance is telling you the target is already in danger. If elapsed time is left at 0%, the pace and projection outputs are intentionally unavailable because the page has no basis for extrapolation.

• Use Budget Metrics when you need the full ledger, per-row copy controls, or CSV and DOCX exports.
• Use Run-Rate Guidance when you need the quickest read on burn pace, projected period-end balance, maintenance policy, and incident cadence.
• Use Target Charts when you need a visual explanation of burned versus remaining budget or when you want to compare the selected target with common 99.x tiers.
• Use Downtime Lookup when you need to translate one target into standard windows without changing the current target.
• Use JSON when you need one portable export of the current inputs, totals, summaries, and comparison rows.

Incident count should be treated as structure, not severity. It helps answer whether the same downtime came from one long outage or many short ones, but it never changes the budget arithmetic itself. That makes the incident metrics useful for post-incident commentary and less useful for deciding whether the target was formally met.

Step-by-Step Guide

1. Choose the uptime target directly or load a preset such as 99.0%, 99.5%, 99.9%, 99.95%, 99.99%, or 99.999%.
2. Set the reporting period in hours, days, weeks, or years so the time window matches the commitment you are reviewing.
3. Enter the current unplanned downtime in seconds, minutes, or hours.
4. Open the advanced panel if needed, then add planned maintenance, decide how much of it should count, set how much of the period has elapsed, and add incident count if you want MTTR and incident-spacing metrics.
5. Read the summary banner first, then confirm the detailed rows in Budget Metrics and the pace wording in Run-Rate Guidance.
6. Use Downtime Lookup, Target Charts, JSON, and the CSV, DOCX, or image exports only after the current run looks correct.

Interpreting Results

The fastest reading is still the simplest one. If the banner says there is budget left, the current window is still inside the selected target. If it says the run is over budget, the target has already been missed for the inputs you entered. The achieved percentage can still be useful, but the pass or fail boundary is the remaining-budget line, not whether the displayed percentage looks close.

Burn percentage and burn pace answer two different questions. Budget burn shows how much of the allowance is already gone. Burn pace compares that consumption with the share of the period already elapsed. In this calculator, a pace above 1 means the current rate would exhaust the budget before the end of the period if nothing changes. The guidance badge becomes more severe once the pace climbs above about 1.2x, and it moves into warning territory once it rises above about 0.9x.

The lookup table is useful when someone asks a translation question instead of a compliance question. It answers, for example, how much downtime 99.95% allows over 1 hour, 1 week, or 90 days. The target ladder answers a different question again: given the charged downtime already logged, which common targets are still feasible for the current period.

Read the raw and policy views together when maintenance is part of the story. A result can still pass under the selected policy while the raw interruption figure looks much worse, and that difference is often exactly what stakeholders need explained in a review note.

Worked Examples

FAQ:

Glossary:

Availability target

The percentage goal the selected reporting period is measured against.

Error budget

The share of the reporting period that may be unavailable before the target is missed.

Policy effective downtime

Unplanned downtime plus only the maintenance share that the current policy counts toward burn.

Raw interruption

Unplanned downtime plus the full maintenance duration, regardless of whether maintenance is charged.

Burn pace

The rate at which the error budget is being consumed compared with the share of the period already elapsed.

MTTR

Mean time to repair, derived here by dividing unplanned downtime by incident count.

Mean time between incidents

The reporting-period length divided by incident count for the current window.

References:

• Concepts in service monitoring, Google Cloud Observability documentation.
• Alerting on your burn rate, Google Cloud Observability documentation.
• How to read a service-level agreement (SLA), Microsoft Learn.
• Architecture strategies for defining reliability targets, Microsoft Azure Well-Architected Framework.
• What is mean time to repair (MTTR)?, IBM.