{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Status {{ resultsReady ? budgetStatusLabel : 'Check inputs' }} Budget used {{ resultsReady ? formatPercent(analysis.budget_used_percent, 2) : '—' }} Burn pace {{ resultsReady ? burnPaceLabel : '—' }}
{{ summaryAnnouncement }}
Availability budget inputs
The preset fills the editable target below.
%
Enter a target from 90% through 100%.
A year is treated as 365 days.
Use the same duration recorded by the incident review.
The neutral default is zero maintenance.
{{ formatPercent(Number(maintenance_impact_percent), 0) }}
0% exempts maintenance; 100% charges it fully.
{{ formatPercent(Number(elapsed_percent), 0) }}
At 0%, current budget status remains available but pace and projection are unavailable.
Use zero when incident cadence is not part of the review.
Budget review
{{ row.label }}{{ row.display }}
Calculation method:
Full precision is retained in the model; readable durations are rounded only for display.
allowed = period × (1 − target ÷ 100)
Run-rate guidance
{{ row.title }}

{{ row.text }}

{{ chartExportStatus }}

The chart renderer is unavailable. Exact target rows remain available in the CSV export after the renderer loads.

PeriodAllowed downtimeBudget usedCurrent statusCopy
{{ row.label }}{{ formatDuration(row.allowed_seconds) }}{{ formatPercent(row.budget_used_percent, 2) }}{{ row.status_label }}
{{ tableExportStatus }}

An availability target turns a percentage into a finite allowance for interruption. Over a 30-day window, 99.9% availability permits 43 minutes 12 seconds of unavailable time. Raising the target to 99.99% cuts that allowance to 4 minutes 19.2 seconds, so each additional nine can demand a large operational improvement.

Availability and reliability overlap but are not identical. Availability asks whether a service can perform its intended function during the measurement window. Reliability also considers how consistently it behaves, including failures that may not create a complete outage. A degraded service can remain technically reachable while slow responses or failed requests still harm users.

Reliability planning terms
TermRoleImportant boundary
SLIA service level indicator measures actual service behavior.The indicator must reflect a user-relevant event or time basis.
SLOA service level objective sets the target for an SLI.It is an internal objective unless a contract says otherwise.
SLAA service level agreement defines a commitment and its consequences.Its exclusions and measurement clauses govern compliance.
Error budgetThe allowed amount of failure implied by an SLO.It belongs to a specific window and measurement definition.

Maintenance policy can change the scored result without changing what users experienced. Exempting planned work may be appropriate for one agreement, while another counts it fully. For that reason, policy-effective availability should be kept beside raw availability, and both should use the same reporting window, incident timestamps, and outage definition.

How to Use This Tool:

Use one measurement window and one outage policy throughout the review.

  1. Select a Target preset or enter a custom Availability target from 90% through 100%, then set the reporting period. One year is treated as 365 days.
  2. Enter Unplanned downtime using the duration recorded by the incident review. Add planned maintenance separately.
  3. Set Maintenance charged to the percentage that consumes the chosen SLA or SLO budget. Zero exempts maintenance; 100% counts all of it.
  4. Set Period elapsed for burn pace and straight-line projection. At 0%, current budget status remains available but pace and projection do not.
  5. Add Incident count only when average repair and interval figures are meaningful for the same incident definition. Review policy and raw availability together before drawing a compliance conclusion.

Interpreting Results:

Allowed downtime is the total error budget for the selected window. Policy-effective downtime combines unplanned interruption with only the charged share of maintenance. A status is over budget only when effective downtime is greater than the allowance; equality remains within budget with nothing left.

Burn pace compares the share of budget consumed with the share of the reporting period elapsed. A straight-line projection assumes the observed pace continues, so it is not an outage forecast. Check raw availability whenever maintenance exclusions or partial charging make the policy result look better than the user-visible interruption record.

Technical Details:

This model measures time-based availability. The reporting period and all interruptions are converted to seconds, then a policy factor is applied to maintenance. It does not weight interruptions by request volume, affected users, region, dependency, or degree of degradation.

Formula Core:

The unavailable fraction of the target sets the allowance. Budget consumption and achieved availability then use the policy-effective interruption time.

B=T×(1A)
E=U+M×c
Apolicy= (1ET)×100%
R=E÷Be

T is the period in seconds, A is the target as a fraction, U is unplanned downtime, M is planned maintenance, c is its charged fraction, and e is the elapsed fraction. Raw availability replaces E with all unplanned plus all maintenance time. Availability outputs are bounded from 0% through 100%.

Rule Core:

Uptime budget status and pace rules
SignalExact conditionMeaning
Over budgetE > BCharged downtime exceeds the target allowance.
Near limitEB and remaining budget ≤ 10% of BThe window still passes, but little allowance remains.
Within budgetAll other non-over-budget casesMore than 10% remains, or the zero-budget case has no downtime.
Sustainable paceR ≤ 0.9Budget is being consumed more slowly than the warning range.
Warning pace0.9 < R ≤ 1.2Consumption is near or above the even budget path.
Danger paceR > 1.2, or the current window is already over budgetThe straight-line pace is not sustainable.

Pace requires elapsed time above 0% and an allowance above zero. Projection requires elapsed time above 0% and scales current effective downtime by 1 ÷ e. Mean time to repair is unplanned downtime divided by incident count, while mean time between incidents is the full reporting period divided by incident count; both are omitted when the count is zero.

Limitations:

A time-based percentage is only as sound as its window, outage definition, and evidence. It should not be treated as an SLA ruling without applying the agreement's exact measurement and exclusion clauses.

  • Partial outages and traffic-weighted failures may be better measured with successful events divided by valid events.
  • Straight-line projection ignores clustering, seasonality, planned risk, and incident likelihood.
  • Maintenance charging changes policy availability but does not erase user impact.
  • Readable durations are rounded for display; the model retains full precision.

Worked Examples:

Thirty-day window with partly charged maintenance

A 99.9% target permits 2,592 seconds, or 43 minutes 12 seconds, over 30 days. With 18 minutes of unplanned downtime and half of a 12-minute maintenance window charged, effective downtime is 24 minutes. That uses 55.56% of the budget; at 60% of the period elapsed, the burn pace is about 0.93× and enters the warning range.

References: