SLA Availability Calculator

SLA target:

Enter the committed availability percentage.

Reporting window:

Set the full period that the downtime budget applies to.

Unplanned downtime:

Enter outage time from incident records or monitoring data.

Planned maintenance:

Use 0 when planned maintenance is not part of this calculation.

Maintenance counted: {{ formatPercent(maintenance_counted_percent, 0) }}

Choose how much scheduled downtime burns the availability budget.

Check SLA inputs

{{ error }}

Service or SLA name:

Name the service, customer contract, or SLO slice being reviewed.

SLA preset:

Use common two-nines through five-nines tiers as a quick starting point.

Window elapsed: {{ formatPercent(elapsed_percent, 0) }}

Set less than 100% when reviewing an in-progress period.

Incident count:

Enter distinct incidents, or 0 to skip average outage metrics.

Budget watch gate: {{ formatPercent(policy_watch_percent, 0) }}

Used for guidance rows and the chart watch line.

Metric	Value	Reliability note	Copy
{{ row.metric }}	{{ row.value }}	{{ row.note }}

Signal	Current	Action	Copy
{{ row.signal }}	{{ row.current }}	{{ row.action }}

Enter a valid reporting window and SLA target to draw the downtime budget curve.

Period	Allowed downtime	Current share	Status	Copy
{{ row.period }}	{{ row.allowed }}	{{ row.share }}	{{ row.status }}

Checkpoint	Allowed downtime	Projected counted downtime	Projected remaining	Copy
{{ row.checkpoint }}	{{ row.allowed }}	{{ row.projected }}	{{ row.remaining }}

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

SLA availability is the share of a reporting window when a service is available under the rules of a service-level agreement. A 99.9% monthly target leaves only 0.1% of that month for counted downtime, which is 43.2 minutes in a 30-day window. That small allowance is why a few incident minutes can matter more than the percentage label suggests.

Availability is narrower than reliability. Availability asks whether the service was usable when required. Reliability also includes whether the service behaves correctly, recovers predictably, avoids repeated incidents, and continues to meet user expectations over time. A service can remain above its availability target while still causing concern if incidents cluster, burn the allowance early, or affect a critical customer path.

SLA availability budget diagram with reporting window, allowed downtime, used downtime, remaining budget, watch gate, and projected pace.

Service-level indicators (SLIs), service-level objectives (SLOs), and service-level agreements (SLAs) use related but different language. An SLI is the measurement, an SLO is the internal or published target, and an SLA usually adds contractual consequences when the target is missed. The same availability arithmetic may support all three, but the policy around outages, exclusions, and credits can differ.

The largest risk is treating a single percentage as a complete reliability answer. A monthly result can hide when the downtime happened, whether the service was degraded rather than fully down, whether planned maintenance was counted correctly, and whether the current pace would still pass by the end of the window.

Technical Details:

Time-based availability converts a period into available and unavailable time. The SLA target defines the maximum unavailable share. For example, a 99.95% target leaves 0.05% of the reporting window as downtime allowance. A 30-day month has 43,200 minutes, so that target allows 21.6 counted minutes before the window misses the target.

Maintenance treatment changes the counted downtime, not the length of the reporting window. Unplanned outage minutes count fully. Planned maintenance is multiplied by the selected counted share, so a two-hour maintenance window contributes zero minutes when fully excluded, 60 minutes when half counted, and 120 minutes when fully counted. Keeping the excluded minutes visible helps separate engineering evidence from contract policy.

Formula Core:

The current-window calculation starts with the SLA target, period length, unplanned downtime, and the counted share of planned maintenance.

\begin{array}{lcl} Budget minutes & = & period minutes \times \frac{100 - SLA percent}{100} \\ Counted maintenance & = & planned maintenance \times \frac{maintenance counted percent}{100} \\ Counted downtime & = & unplanned downtime + counted maintenance \\ Achieved availability & = & \frac{period minutes - counted downtime}{period minutes} \times 100 \\ Burn rate & = & \frac{counted downtime / budget minutes}{elapsed window share} \end{array}

A burn rate of 1.00x means the counted downtime pace matches the period allowance. Values above 1.00x project a miss if the same pace continues. Values below 1.00x leave room if the outage pattern does not worsen.

Input Rules and Limits:

Input rules for the SLA availability calculation
Input	Accepted rule	Why it matters
`SLA target`	Greater than `0%` and less than `100%`.	Defines the unavailable share that becomes the downtime budget.
`Reporting window`	Positive value in hours, days, weeks, months, quarters, or years.	Sets the total minutes used for both budget and availability percentage.
`Unplanned downtime`	Non-negative duration in seconds, minutes, hours, or days.	Counts fully against the SLA budget.
`Planned maintenance`	Non-negative duration in seconds, minutes, hours, or days.	Counts only by the selected maintenance policy share.
`Maintenance counted`	`0%` to `100%`.	Controls how much scheduled downtime burns the budget.
`Window elapsed`	`1%` to `100%`.	Drives burn rate, projection, and budget-exhaustion timing.
`Budget watch gate`	`1%` to `99%`.	Marks early review before the budget reaches full use.

Result Signals:

SLA availability result signals and interpretation
Result	Meaning	Review cue
`Budget position`	Remaining counted minutes, or minutes already over budget.	Use this before the percentage when discussing breach risk.
`Achieved availability`	Full-window availability after counted downtime is applied.	Compare it with the SLA target for the formal pass or miss.
`Projected period availability`	End-of-window availability if the elapsed downtime pace continues.	Use it only when `Window elapsed` is less than `100%`.
`Downtime burn rate`	Current pace compared with the sustainable pace for the whole period.	A value above `1.00x` needs attention even before the budget is gone.
`Projected budget exhaustion`	Estimated day when counted downtime reaches the full allowance.	Treat it as a pace estimate, not a promise about future incidents.

Everyday Use & Decision Guide:

Start with the contract or review period you actually report against. For a monthly customer SLA, enter the billing month as the Reporting window. For an internal review, use the same window used by monitoring and incident review so the downtime ledger and the service dashboard agree.

Use the SLA preset only as a starting point. The preset fills SLA target for common two-nines through five-nines targets, but the custom percentage is the value that drives the math. If the agreement says 99.95%, do not round it to 99.9% just because the result looks easier to meet.

Enter incident time in Unplanned downtime and keep the same outage-counting rule used by the agreement or SLO policy.
Enter scheduled work in Planned maintenance only when it should appear in the evidence. Then set Maintenance counted to match the contract treatment.
Use Window elapsed below 100% for an in-progress month or quarter. The current position may be inside the target while the projection warns that the pace is too high.
Set Incident count when average outage duration matters for a review. It does not change availability.
Adjust Budget watch gate to the percentage of budget use that should trigger reliability review before a formal miss.

This is a good fit for incident review, SLA evidence, SLO check-ins, and maintenance policy comparison. It is a poor fit for proving customer impact by itself. Degraded service, partial-region failures, dependency outages, exclusions, and measurement rules still need the supporting logs and contract language.

Check SLA Ledger first, then open Breach Guidance if the summary says watch zone, projected breach, or budget exceeded. Use Downtime Curve and Budget Points when you need to explain pace across the window instead of sharing one final percentage.

Step-by-Step Guide:

Work from the SLA promise to the incident ledger, then use the projection fields only when the window is still open.

Enter the service label in Service or SLA name if you want exports and JSON evidence to identify the review slice.
Choose a SLA preset or type the exact SLA target. The summary badges update with the target and budget-used percentage.
Set Reporting window with the value and unit that the agreement uses. The Allowed downtime budget row in SLA Ledger shows the resulting allowance.
Enter Unplanned downtime, Planned maintenance, and Maintenance counted. Review Counted planned maintenance and Excluded planned maintenance so the policy treatment is visible.
Set Window elapsed below 100% for an active period. Check Projected period availability, Downtime burn rate, and Projected budget exhaustion before assuming the current cushion is safe.
If an input alert appears under Check SLA inputs, fix that issue before using the result. Common causes include a target outside the allowed range, logged downtime greater than the reporting window, or counted downtime greater than the elapsed part of an active window.
Open Allowance Ladder to compare the same counted downtime across daily, weekly, monthly, quarterly, yearly, and entered-window allowances. Use JSON only after the ledger matches the evidence you intend to keep.

Interpreting Results:

Budget position is the clearest first read. A positive value means counted downtime is still inside the allowance. A negative value means the current window has already exceeded the allowance under the selected maintenance policy.

Achieved availability answers the full-window percentage check, while Projected period availability answers the pace question for an unfinished window. Do not treat a passing current availability as safe when Downtime burn rate is above 1.00x or the summary says projected breach.

inside SLA means current counted downtime is within budget and the projection is not over budget.
watch zone means current or projected budget use has reached the configured Budget watch gate.
projected breach means the window is inside now but the current pace would exceed the budget by period end.
budget exceeded means counted downtime is already beyond the allowed downtime budget.

Worked Examples:

Monthly SLA Still Inside Budget

A 99.9% target over 30 days allows 43.2 min of counted downtime. With 18 minutes of unplanned downtime, no planned maintenance, Window elapsed at 100%, and Incident count set to 2, SLA Ledger shows Budget position as 25.2 min remaining, Achieved availability as 99.9583%, and Total counted downtime as 41.7% of budget. The incident average is 9.00 min per incident.

Inside Now, Failing on Pace

A 99.95% target over 30 days allows 21.6 min. If 12 minutes of downtime has happened after only 25% of the window, Budget position still reads 9.60 min remaining, but Downtime burn rate is about 2.22x. Breach Guidance treats the period as a projected breach because the same pace would reach about 48.0 min counted downtime by period end.

Maintenance Policy Changes the Outcome

With a 99.9% target over 30 days, 10 minutes of unplanned downtime and 2 hours of planned maintenance can pass or fail depending on Maintenance counted. At 0%, Budget position is 33.2 min remaining. At 50%, counted maintenance becomes 1.00 hr, Total counted downtime becomes about 1.17 hr, and Budget position becomes 26.8 min over budget.

Validation Stops a Bad Window

If the Reporting window is 1 hour and logged downtime totals 2 hours, the input alert says Logged downtime cannot exceed the reporting window. For an in-progress window, another alert appears when counted downtime is greater than the elapsed part of the window. Fix the period, elapsed share, or downtime units before using SLA Ledger or exports.

FAQ:

Is SLA availability the same as uptime?

The arithmetic is similar, but an SLA adds a policy. The selected Maintenance counted value can make policy availability differ from a raw interruption total.

Why can the result pass now but show a projected breach?

Window elapsed controls the pace calculation. If a small part of the period has already used a large share of the downtime budget, Projected period availability can fall below the target even while Budget position is still positive.

Should planned maintenance be excluded?

Use the rule in the agreement or SLO policy. 0% excludes planned maintenance from counted downtime, 100% counts it fully, and values between those points model partial charging.

Why does the tool reject my downtime values?

The validation checks prevent impossible windows. Logged downtime cannot exceed the reporting window, and counted downtime cannot exceed the elapsed part of the window when Window elapsed is below 100%.

Does the calculation prove an SLA breach?

No. It shows the result under the values and maintenance policy you enter. A formal breach review still needs contract wording, monitoring evidence, incident timelines, excluded events, and customer-impact rules.

Glossary:

SLA: Service-level agreement, usually a customer-facing commitment with stated consequences if targets are missed.
SLO: Service-level objective, a target used to judge whether a service is reliable enough for its users.
SLI: Service-level indicator, the measurement used to evaluate an SLO or SLA.
Downtime budget: The maximum counted unavailable time allowed by the selected availability target and reporting window.
Burn rate: The pace at which counted downtime is using the downtime budget compared with the sustainable pace.
Planned maintenance: Scheduled interruption time that may be excluded, counted fully, or counted partly depending on the policy.

References:

Availability, AWS Well-Architected Framework.
Service Level Objectives, Google SRE Book.
Alerting on Your Burn Rate, Google Cloud Observability documentation.
Implementing SLOs, Google SRE Workbook.