Define an availability measurement window
Percentages are meaningful only with a method.
Name the service being measured
Decide whether you are checking the homepage, a login flow, an API or an entire customer task. A homepage returning HTTP 200 does not prove that checkout or authentication works. Record the expected response and the locations from which observations are made.
Keep the denominator visible
A 30-day window contains 43,200 minutes, while a 31-day window contains 44,640. The same number of downtime minutes therefore produces a different percentage. State the start and end time, time zone and window length with every reported figure.
Choose a time or request measure deliberately
This calculator measures time: available minutes divided by all minutes in the window. A request-success measure instead divides successful requests by total observed requests. These answer different questions. In an illustrative month, 30 unavailable minutes out of 43,200 gives 99.93056% time availability. If 2,000 of 100,000 requests fail, request success is 98%. A busy outage can affect many requests in little time; do not convert one figure into the other without traffic evidence.
Document what your observation misses
Backend logs cannot record requests that never reach the backend. A synthetic check can miss failures confined to particular users or locations. Choose observations that represent the task you care about, record coverage gaps, and report the measurement method alongside the percentage.
Handle partial and overlapping incidents
Two monitors reporting the same ten-minute outage do not necessarily create twenty minutes of downtime. Keep an incident timeline and define how overlap is merged. Record partial failures separately unless the measurement policy explicitly converts them into a single availability figure.
Distinguish observed availability from contractual terms
A contract may use a different scope, exclusions and reporting process. This calculator does not interpret those terms. Use it to understand the arithmetic and preserve the underlying observations so the result can be independently checked.
Common questions
Why does the measurement window change the availability percentage?
A 30-day window contains 43,200 minutes, while a 31-day window contains 44,640. The same number of downtime minutes therefore produces a different percentage in each window. State the start and end time, time zone and window length with every reported figure, so the result can be independently checked.
Should availability be measured by time or by requests?
The two measures answer different questions. This calculator measures time: available minutes divided by all minutes in the window. A request-success measure instead divides successful requests by total observed requests. A busy outage can affect many requests in little time, so do not convert one figure into the other without traffic evidence.
What can a measurement miss?
Backend logs cannot record requests that never reach the backend, and a synthetic check can miss failures confined to particular users or locations. Choose observations that represent the task you care about, record coverage gaps, and report the measurement method alongside the percentage.
Keep working through the question
Unkillable Window ยท Published . Updated . Prepared with AI assistance; editorial approach and corrections are described on our method page. Examples are illustrative, not case-study results.
References and further reading
- Google SRE Workbook: implementing SLOs โ Explains good-event ratios and measurement coverage. The time and request examples above are our own.