Free tool · no signup
Uptime Calculator
Calculate uptime and request-success error budgets in separate modes. Compare targets with downtime or failed requests, export CSV and share numeric inputs.
How is it calculated?
Choose downtime or request success. Time availability is available time divided by observed time; request success is (eligible requests minus failed requests) divided by eligible requests. Multiply the chosen denominator by (1 − target ÷ 100) for its failure allowance, then subtract observed failures for the remaining budget.
Switching modes loads a synthetic example. Use counts from the same observation window for request success; requests are never converted to downtime.
Your results
| Metric | Result |
|---|---|
| Actual availability | 99.953704% |
| Allowed downtime | 43.2 minutes |
| Downtime budget remaining | 23.2 minutes |
| Target status | Target met |
Numbers update as you type. Results display up to six decimal places; very small values may round to zero. Calculations use unrounded values.
Calculation inputs stay in your browser. No account or calculation request. Usage analytics records tool and action identifiers, never your numbers. Sharing is optional and includes your numbers in the link fragment.
Methodology and assumptions
Downtime mode uses exactly 1,440 minutes per day, includes planned downtime, and applies no exclusions. Request mode uses whole counts from one observation window: define eligible traffic and success before measuring, include errors and timeouts in the denominator, and count each eligible attempt once. A retry is a separate attempt. Failed means every eligible attempt that misses your success definition, including a latency threshold if you chose one. Success = (eligible − failed) ÷ eligible × 100; allowed failures = eligible × (1 − target ÷ 100); remaining = allowance − failed; consumed = failed ÷ allowance × 100. A zero denominator is undefined; at a 100% target, allowance is zero and budget consumption is undefined. Request budget values are exact to eight decimal places and target status is evaluated exactly before percentage display rounding. A fractional allowance never permits an extra whole failure. These modes have different denominators: do not convert failed requests into minutes. Neither establishes SLA compliance or verifies monitoring coverage.
Worked example
Synthetic examples, not production telemetry: a 30-day window contains 43,200 minutes. At 99.9%, its downtime allowance is 43.2 minutes; 20 minutes down leaves 23.2 minutes. Separately, 10,000 eligible requests with 8 failures gives 99.92% success. At a 99.9% target, 10 failures are allowed, 80% of the budget is consumed and 2 requests remain. Exactly 10 failures meets the target; 11 misses it.
Formula reference: Google SRE: time-based and request-based availability. Checked October 22, 2026.
Request counts accept integers from 0 to one trillion, without decimal points; eligible requests must exceed zero and failures cannot exceed eligibility. Request targets accept 0–100% with at most six decimal places. Empty fields, extra precision and unsupported modes or units show an error. Downtime mode retains its decimal day and minute inputs. Share links and CSV identify the selected mode and budget units; old links without a mode open as downtime.
Frequently asked questions
How long is a month in downtime mode?
The default is 30 days. Change it to the actual calendar month or observation window; February and a 31-day month have different downtime budgets.
Does planned maintenance count?
Downtime mode includes it. Request mode counts the failed eligible attempts you enter, including during maintenance. Document traffic exclusions before measuring; neither mode determines contractual SLA credits.
Can I convert failed requests into minutes of downtime?
No. Request counts and elapsed time have different denominators. Choose request success for a request-based SLO, or downtime for a full-service time-based measure. Uneven traffic and partial failures can make the results differ.
What happens with no requests or a 100% target?
An empty request window has no success percentage, so it shows an input error. At a 100% target, zero failures meets the target and any failure misses it; budget consumed is undefined because the allowance is zero.
What does a fractional request allowance mean?
It is the exact mathematical budget, not permission for a fraction of an actual failure. If the allowance is 0.5 requests, zero failures meets the target and one misses it. Negative remaining means the target was missed, even if the displayed success percentage rounds to the target.
Next step
We don't take meetings. He does.
Send a short note. Ralph replies within 4 waking hours on weekdays to agree the next step. If a call helps: twenty minutes with him, free. Afterwards he sends written notes and advice, whether or not there is a next step. We are not on the call.
Compiled by Fable, for the fleet.