| Metric | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} |
| Period | Allowed downtime |
|---|---|
| {{ p.label }} | {{ p.readable }} |
Service availability is the share of time a service stays reachable within a chosen window. Many people call it uptime, and they translate a target such as 99.9 percent into how much outage can occur before expectations are missed. This page centers on that translation so teams can weigh budgets and tradeoffs, an uptime to downtime calculator that helps across typical reporting periods.
You enter a target availability and a period length, then optionally describe interruptions and planned work, and the calculator returns allowed downtime, budget used, and budget left with a simple burn share. It also shows ready lookup values for common windows so you can benchmark your target quickly and explain the implications to stakeholders in clear terms.
For example, imagine a month where you aim for 99.9 percent and expect about fifteen minutes of incidents plus ten minutes of maintenance. The summary shows more than half of the budget spent with a modest cushion remaining. Short windows can swing sharply, so do not read brief streaks as a trend without context.
Choose the same period your reports use to make comparisons fair. Count planned work only if your policy includes it and record it separately either way. Track burn as the window progresses to catch drift early, and use the lookup values to set expectations before a maintenance window.
Service Level Agreement (SLA) availability states the proportion of time a service meets its objective within a fixed window. This calculator models a time‑based service level indicator (SLI) and converts a target percentage into the maximum downtime permitted in the same window. It also aggregates reported outages and maintenance to compute use of the error budget.
Inputs are a target percentage, a period length, and optional downtime components labeled unplanned and planned. Planned time remains part of the budget in this model; the label is for tracking. The reactive engine applies proportional arithmetic and presents allowed downtime, remaining budget, and a burn percentage for quick interpretation.
Interpret outputs as planning guards rather than guarantees. Allowed downtime is the outage limit before the target fails for that window. Remaining budget turns negative once usage exceeds the allowance, while the burn percentage hits or passes 100 percent at that point. Treat planned work consistently with your policy to avoid confusion.
| Symbol | Meaning | Unit/Datatype | Source |
|---|---|---|---|
| Target availability | percent | Input | |
| Period length | seconds | Input | |
| Unplanned downtime | seconds | Input | |
| Planned maintenance | seconds | Input | |
| Effective downtime | seconds | Derived | |
| Allowed downtime | seconds | Derived | |
| Error‑budget remaining | seconds | Derived | |
| Error‑budget burn | percent | Derived |
| Field | Type | Min | Max | Step/Pattern | Error Text |
|---|---|---|---|---|---|
| SLA target | number | 90 | 100 | 0.001 | — |
| Period length | number + unit | 1 | — | unit: seconds, minutes, hours, days, weeks, years | — |
| Downtime experienced | number + unit | 0 | — | unit: seconds, minutes, hours | — |
| Planned maintenance | number + unit | 0 | — | unit: seconds, minutes, hours | — |
| Input | Accepted Families | Output | Encoding/Precision | Rounding |
|---|---|---|---|---|
| Targets, durations, period | Numbers with unit selectors | Readable durations, percentages, lookup table | Text with units; structured JSON export | Nearest second; fixed decimals for percents |
| Metrics table | — | Copyable snapshots | Comma‑separated values | As displayed |
Worked example: Target 99.9% for a 30‑day window; unplanned 15 minutes; planned 10 minutes.
Readable results: allowed 43 m 12 s, effective 25 m, remaining 18 m 12 s, burn 57.87%.
Service level management practice defines availability as an uptime ratio across a window, while site reliability engineering popularizes the error‑budget framing. Both support proportional conversion from a target to allowed downtime.
Processing is client‑only; no data is transmitted or stored on servers. Outputs are informational and do not constitute contractual terms or service guarantees.
Convert a target availability into allowed downtime and read budget health.
Example: Target 99.95% for 90 days with 25 minutes of incidents and 15 minutes of maintenance gives a small cushion; a second long incident may exhaust the budget.
No. Calculations run locally and nothing is saved to servers or local storage.
Keep copies externally if you need an audit trail.Totals use proportional arithmetic. Durations round to the nearest second and then split into whole units, which may hide very small fractions at high targets.
Near boundaries, verify with context.Periods support seconds, minutes, hours, days, weeks, and years. Downtime entries support seconds, minutes, and hours.
Year equals 365 days by design.Not in this model. Planned work is counted toward the budget; the separate entry helps track it distinctly for reports.
Apply your own policy consistently.Yes after the page loads. All computations happen locally.
Charts render without a data connection once assets are cached.Service Level Agreement. It states the expected availability or performance over a defined window.
SLO is the objective; SLI is the indicator.Select a month‑length window, set 99.9%, and read the allowed downtime line. For 30 days this is 43 minutes 12 seconds.
Interpret as guidance, not a guarantee.The calculator runs locally without using paid APIs. Check your organization’s policy before relying on any tool for contractual decisions.
Always consult formal agreements for binding terms.