SLA Availability Calculator

SLA target:

Enter the committed availability percentage.

SLA preset:

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

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.

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 }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

High availability percentages hide small downtime budgets. At 99.9%, a 30-day window allows only 43.2 minutes of counted downtime. At 99.99%, the same window allows about 4.32 minutes, so one short incident can move a service from comfortably inside the promise to over budget.

Availability is the share of a defined reporting window where the service is counted as usable. Reliability is broader. It includes how often the service fails, how fast it recovers, whether partial degradation counts, and whether users receive correct behavior when the service is technically reachable. SLA availability math turns that wider reliability picture into a percentage, a downtime allowance, and a rule set that must be applied consistently.

Three terms often appear together in reliability reviews. A service level indicator (SLI) is the measurement, such as successful requests or available minutes. A service level objective (SLO) is an internal target for that measurement. A service level agreement (SLA) is the customer-facing or business-facing promise, often with notification, evidence, or service-credit consequences when the target is missed. The arithmetic may look similar, but the obligation behind the number is different.

A reporting window lane showing available time, downtime budget, and counted downtime.

The denominator matters as much as the outage. A monthly SLA may use a calendar month, a billing month, or a fixed 30-day period. Downtime may be measured from public probes, internal monitors, successful requests, support-ticket timestamps, or a status-page incident. Planned maintenance can be excluded, partly counted, or fully counted depending on the policy. Those choices can change the answer without changing the incident timeline.

Burn rate adds urgency to the same math. Spending half of the downtime allowance halfway through a window is different from spending half of it in the first week. A service may still be inside the SLA today while the current pace points toward a miss before the period ends. Availability reviews therefore compare current budget position with elapsed-window progress instead of waiting for the final day.

Reliability term	Practical meaning	Common mistake
Availability	Percent of the reporting window counted as usable.	Rounding a high percentage and missing that the minutes are already over budget.
Error budget	The unavailability allowance implied by the target.	Forgetting that stricter targets shrink the allowance very quickly.
Burn rate	How fast the allowance is being consumed relative to elapsed time.	Reading remaining budget without checking whether the current pace is sustainable.
Maintenance policy	The rule for whether scheduled downtime counts against the target.	Using the wrong exclusion rule for a customer agreement or internal objective.

How to Use This Tool:

Use one service, customer commitment, or SLO slice per run so the reporting window, downtime entries, elapsed percentage, and maintenance rule all describe the same promise.

Set SLA target, or choose an SLA preset from common two-nines through five-nines availability tiers.
Enter the full Reporting window and unit. Use the same period your agreement, billing cycle, or reliability review uses.
Add Unplanned downtime from incident records or monitoring data, then add Planned maintenance if scheduled downtime belongs in the review.
Move Maintenance counted to match the policy. Use 0% when approved maintenance is excluded, 100% when it counts fully, or a partial value for split treatment.
Open Advanced when you need a service label, in-progress Window elapsed, Incident count, or a custom Budget watch gate.
If an input warning appears, fix the stated value before using the result. Common fixes are lowering a target that is 100% or higher, increasing a nonpositive window, or correcting downtime that is longer than the reporting window or elapsed portion.
Read the summary first, then compare SLA Ledger, Breach Guidance, Downtime Curve, Allowance Ladder, Budget Points, and JSON when you need evidence for a review.

For an active period, set Window elapsed to the current progress instead of leaving it at 100%. That makes the burn-rate and projection outputs reflect the pace so far rather than treating the window as complete.

Interpreting Results:

Budget position is the pass-or-fail reading for the selected window. A positive value means counted downtime remains inside the allowance. A negative value means counted downtime already exceeds the availability target.

Achieved availability can still look close to 100% after a breach because strict targets leave only a small number of downtime minutes. Check remaining budget and Budget used before trusting the percentage alone.

Burn rate compares budget consumption with elapsed-window progress. A value at or below 1.00 means the current pace is sustainable for the full period. A value above 1.00 means the current pace would spend more than the allowance before the window ends if nothing improves.

Result signal	What it means	What to verify next
Inside SLA	Current and projected counted downtime remain below the selected budget watch gate.	Confirm the outage minutes use the same measurement boundary as the SLA records.
Watch zone	Current or projected budget use is at or above the watch gate, but the budget is not yet exceeded.	Check recent incidents and compare the Downtime Curve with the elapsed point.
Projected breach	Current downtime is inside budget now, but the burn-rate projection spends more than the full allowance.	Review open mitigations, upcoming maintenance, and whether the elapsed percentage is correct.
Budget exceeded	Counted downtime is greater than the full-window allowance.	Separate counted downtime from excluded maintenance before customer or service-credit review.

Technical Details:

SLA availability reduces the reporting period to a denominator and subtracts only the downtime that the policy says should count. The same incident history can produce different availability readings when the reporting window changes, when approved maintenance is excluded, or when an in-progress review uses only part of the window.

The downtime allowance is an error budget expressed in minutes. A 99.9% target means 0.1% of the window may be unavailable. A 99.99% target means 0.01% may be unavailable, which is ten times smaller. Burn rate compares the allowance already spent with the elapsed share of the window, which is why early outages can look worse than the final percentage alone suggests.

Formula Core

B = W \times \frac{100 - S}{100}

D_{c} = D_{u} + D_{m} \times \frac{M}{100}

A = \frac{W - D_{c}}{W} \times 100

R = \frac{D_{c} / B}{E / 100}

Symbol	Meaning	Displayed field or output
`W`	Reporting window in minutes.	Reporting window
`S`	Availability target as a percentage.	SLA target
`B`	Allowed downtime budget in minutes.	Allowed downtime budget
`D_u`	Unplanned incident downtime in minutes.	Unplanned downtime
`D_m`	Planned maintenance in minutes.	Planned maintenance
`M`	Percent of planned maintenance charged to the budget.	Maintenance counted
`D_c`	Total counted downtime.	Total counted downtime
`A`	Achieved availability percent for the selected window.	Achieved availability
`E`	Elapsed share of the reporting window, from 1% to 100%.	Window elapsed
`R`	Budget burn rate relative to elapsed progress.	Downtime burn rate

A 30-day window has 43,200 minutes. At 99.9%, the downtime budget is 43,200 multiplied by 0.001, or 43.2 minutes. With 18 minutes of unplanned downtime, 30 minutes of planned maintenance, and 50% of maintenance counted, counted downtime is 18 plus 15, or 33 minutes. Achieved availability is 99.9236%, remaining budget is 10.2 minutes, and the burn rate at 40% elapsed is about 1.91.

Unit	Minute conversion	Assumption
Hour	60	Fixed duration.
Day	1,440	Fixed 24-hour day.
Week	10,080	Seven fixed days.
Month	43,200	30-day month.
Quarter	129,600	90-day quarter.
Year	525,600	365-day year.

For in-progress windows, projected counted downtime is counted downtime divided by the elapsed share. Projected availability then uses that projected downtime against the full reporting window. The projected budget exhaustion day is the full-window budget divided by the current counted downtime per day, so it is meaningful only when the current pace is greater than zero.

Condition	State	Boundary rule
Input checks fail	Needs review	Fix the shown input error before interpreting availability.
Remaining budget is below 0 minutes	Budget exceeded	Counted downtime is greater than the full-window allowance.
Projected remaining budget is below 0 minutes	Projected breach	Current pace exceeds the full-window allowance when extended to 100% elapsed.
Current or projected budget used is at least the watch gate	Watch zone	The watch gate is inclusive, so 70% used reaches a 70% gate.
None of the above apply	Inside SLA	Current and projected downtime remain below the configured warning point.

Validation protects the denominator and the timeline. The SLA target must be greater than 0% and below 100%, the reporting window must be positive, downtime values cannot be negative, maintenance counted must stay from 0% to 100%, window elapsed must stay from 1% to 100%, and the budget watch gate must stay between 1% and 99%. Logged downtime cannot be longer than the full reporting window, and counted downtime cannot be longer than the elapsed portion when the period is not complete.

Accuracy Notes:

Availability math is only as authoritative as the measurement and agreement behind it. The calculation uses the entered downtime values; it does not fetch monitoring records, prove customer impact, decide whether an incident qualifies for exclusion, or calculate service credits.

Use the same reporting window and measurement boundary that your SLA, SLO, or incident review uses.
Check planned-maintenance notice rules before excluding scheduled downtime.
Run separate scenarios when legal wording, customer impact, or internal reliability practice disagree.
A rounded availability percentage can hide a breach when the target has a very small downtime allowance.

Worked Examples:

A monthly 99.9% target with partial maintenance

A checkout API has a 99.9% SLA target over 30 days. The incident log shows 18 minutes of unplanned downtime and a 30-minute maintenance event where 50% counts. The Allowed downtime budget is 43.2 minutes, Total counted downtime is 33 minutes, and Budget position remains 10.2 minutes. If Window elapsed is 40%, the Downtime burn rate is about 1.91x, so the result can be inside now and still show projected breach risk.

Four nines leaves only a few minutes

A 99.99% SLA target over 30 days allows about 4.32 minutes of downtime. Eight minutes of unplanned downtime puts Budget position at about 3.68 minutes over budget. Achieved availability is still about 99.9815%, which looks high until it is compared with the stricter target.

An in-progress window error

A 30-day window at 10% elapsed represents only 3 elapsed days. If the entered counted downtime is 5 days, the warning says counted downtime cannot exceed the elapsed part of the reporting window. Correct the downtime units, increase Window elapsed if the outage belongs later in the period, or use 100% elapsed for a completed review.

FAQ:

Is an SLA the same as an SLO?

No. An SLO is usually an internal reliability target, while an SLA is a commitment to a customer or business party. The calculator can use either kind of target, but the consequences of a miss come from your agreement or internal policy.

Why can achieved availability look high after a breach?

High-nines targets leave tiny downtime budgets. At 99.99% over 30 days, 8 counted minutes still rounds to about 99.9815% availability, but Budget position is already negative because the allowance is only about 4.32 minutes.

Should planned maintenance be counted?

Use the policy for the SLA or SLO being reviewed. Set Maintenance counted to 0% for fully excluded maintenance, 100% for fully charged maintenance, or a partial value when only some scheduled downtime burns budget.

What does a burn rate above 1 mean?

A burn rate above 1 means counted downtime is being consumed faster than the elapsed share of the window. The service may still have remaining budget, but the current pace projects a miss by the end of the period.

Why does the elapsed-window warning appear?

When Window elapsed is below 100%, counted downtime must fit inside the elapsed portion of the reporting window. Check the downtime unit first, then confirm whether the period should be treated as in progress or complete.

Can this calculate service credits?

No. It calculates availability, remaining budget, burn rate, and breach signals. Service credits depend on contract wording, customer impact, notice rules, exclusions, claim windows, and evidence requirements.

Glossary:

SLA: Service level agreement, a customer-facing or business-facing commitment for service behavior.
SLO: Service level objective, an internal target for a service level indicator.
SLI: Service level indicator, the measurement used to judge service behavior.
Error budget: The amount of unavailability allowed by the target during the reporting window.
Burn rate: The pace of budget consumption compared with elapsed-window progress.
Counted downtime: Unplanned downtime plus the portion of planned maintenance charged against the budget.
Reporting window: The period over which availability and downtime allowance are calculated.

References:

Service Level Objectives, Google Site Reliability Engineering.
Availability Table, Google Site Reliability Engineering.
Alerting on SLOs, Google SRE Workbook.
Error Budget Policy for Service Reliability, Google SRE Workbook.