Calculate uptime percentage from incident durations
A 30-day month of 43,200 minutes with three incidents totalling 45 minutes gives just under 99.9 % uptime, which counts as two nines. Enter your period and incident durations in one unit and get the same breakdown. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Period
- 43,200 minutes
- Incidents
- 10, 20, 15
- Incident count
- 3 minutes
- Total incident time
- 45
- Available time
- 43,155
- Uptime percentage
- 99.8958333333
Turn a monitoring window and its incident durations into a clear availability result. This uptime calculator adds the downtime, checks that it can fit inside the period, subtracts it from the monitored time, and reports both the uptime percentage and its familiar nines classification. Choose seconds, minutes, hours, or days, but use the same unit for every value. The calculation is deterministic, runs without network access, and makes no assumptions about calendars, timestamps, or overlapping events.
Prepare a monitoring period and reliable incident totals
Start with the complete interval covered by the report, such as 30 days, 720 hours, or 43,200 minutes. Then list the duration of every incident that reduced availability during that same interval. The period and incidents must share one unit; selecting minutes means that both the period and every incident value are minutes.
Use zero only for an individual incident that had no measurable duration, and use an empty incident list when the service had no downtime at all. The calculator treats the supplied durations as distinct downtime, so it does not attempt to discover whether two incidents overlap. If monitoring tools recorded simultaneous incidents for the same service, consolidate that overlap before submitting the values.
This prevents the same unavailable minute from being counted twice. The monitoring period must be positive, and every duration must be finite and non-negative. These rules keep the result meaningful and make it suitable for status reports, service reviews, and automated checks.
Understand the percentage and nines calculation
The calculation first adds every incident duration to obtain total incident time. It subtracts that total from the monitoring period to get available time, then divides available time by the full period and multiplies by 100. For example, a result of 99.9 percent means downtime occupied one thousandth of the monitored interval.
The nines classification is based on the downtime fraction: the calculator takes the whole-number floor of the negative base-ten logarithm of that fraction. A downtime fraction of 0.001 therefore produces three nines, while 0.0001 produces four nines. Values between exact thresholds stay in the lower classification, which avoids claiming a service objective that the measured result did not reach.
If no incident time occurred, the result says perfect uptime and omits a finite nines count because there is no mathematical upper limit to the number of leading nines.
Use the result in status pages and service reviews
The returned fields are designed to support both a human summary and an automated workflow. The incident count confirms how many duration entries were evaluated. Total incident time and available time preserve the selected unit, making the arithmetic easy to audit against an incident register.
Uptime percentage provides the exact availability figure used in reports, and the classification supplies a concise label such as three nines. Before publishing the number on a status page, confirm that the monitoring period matches the report dates and that scheduled maintenance is included or excluded according to the policy you disclose to customers. For service-level objective reviews, compare the calculated percentage with the contractual threshold rather than relying only on the label: two results can share the same nines classification while having materially different remaining error budgets.
In automation, treat an invalid-input response as a data-quality signal. A total incident duration greater than the period often indicates duplicate incidents, mixed units, or a window assembled from mismatched reports.
What you can do with it
Publish a monthly status summary
Combine the month length and confirmed incident durations into an auditable uptime percentage and nines label.
Review a service-level objective
Calculate measured availability before comparing it with an SLO threshold or error-budget policy.
Validate an incident export
Detect impossible reports where recorded downtime exceeds the monitoring window, often revealing duplicates or mixed units.
FAQ
What units can I use?
Use seconds, minutes, hours, or days. The period and every incident duration must use the one selected unit.
How are nines classified?
The finite count is the floor of the negative base-ten logarithm of the downtime fraction. Thresholds are never rounded upward.
What happens when there are no incidents?
An empty list or only zero-duration entries produces 100 percent and the classification perfect uptime; no finite nines count is returned.
Does the calculator handle overlapping incidents?
No. Durations are added as supplied, so overlapping downtime for the same service should be consolidated first.
Why does a result just under 99.9 % count as only two nines?
Because values between exact thresholds stay in the lower class. Three nines allows downtime of at most one thousandth of the period, and 45 minutes out of 43,200 is slightly more, so the result does not claim a target it did not reach.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/web/status-page-uptime-percent \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"period":60,"incidents":[10,20,15]}'const res = await fetch("https://api.kit.forhosting.com/web/status-page-uptime-percent", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"period": 60,
"incidents": [
10,
20,
15
]
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/web/status-page-uptime-percent",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"period": 60,
"incidents": [
10,
20,
15
]
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/web/status-page-uptime-percent", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"period":60,"incidents":[10,20,15]}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"period":60,"incidents":[10,20,15]}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/web/status-page-uptime-percent", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"period": 60,
"incidents": [
10,
20,
15
]
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "web.status_page_uptime_percent",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
max_incidents | 10000 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Prepare a monitoring period and reliable incident totals
If the combined incident time is longer than the period, the request is rejected instead of returning a misleading negative availability figure.
Understand the percentage and nines calculation
Percentage output is rounded to twelve decimal places for stable display and repeatable API responses, while the classification is calculated from the unrounded ratio so a display rounding boundary cannot award an extra nine.
Use the result in status pages and service reviews
The browser calculation is useful for quick checks, while API calls cost $0.002 per request when the same logic is incorporated into reporting pipelines.
Technical questions
What does an API calculation cost?
Each API request costs $0.002. The same deterministic calculation can also run in the browser.