Uptime, downtime and outages
How uptime percentage, downtime and outage counts are computed, why they don't add up to each other and how maintenance and probe results change them.
Last reviewed
On this page
OctoPing reports three related numbers for a site: uptime, downtime and the count of outages. They answer different questions and are computed differently on purpose, so they don't have to add up to each other.
| Number | Question it answers | Computed from |
|---|---|---|
| Uptime percentage | What share of the checks that were made succeeded? | Every check from every vantage point in the window |
| Downtime | For how long was the site down? | Wall-clock time between failing and recovering, seen by the primary checker |
| Outages | How many separate times did it go down? | The same runs of failures that downtime adds up |
What counts as success
One rule applies everywhere. A check succeeds when the HTTP status is at least 200 and below 400. A missing status, a status of 0 and a request that was refused before it left OctoPing all count as failures.
Uptime percentage
Uptime is the number of successful checks divided by the number of checks, as a percentage with two decimals. It pools the primary checker and the probe regions, so a site checked from several vantage points contributes samples from all of them.
- The window is 30 days on a site's statistics and on its uptime badge by default, and 90 days on a public status page.
- A primary check that failed and was contradicted by every probe region counts as a success, because visitors could reach the site.
- Checks made during a maintenance window are left out of both the successes and the total. A period that contains only maintenance checks has no uptime value at all, which is different from 0%.
- A window with no checks at all also has no value. The app shows a dash and not 0%.
- If retention has already deleted the oldest checks in a window, the figure covers the checks that remain.
Example: a site has 1000 checks in the window and 990 of them succeeded. Its uptime is 99.00%.
Downtime and outages
An outage is a run of consecutive failing checks on the primary checker, from the first failure to the first success. Downtime is the total length of the outages in a window, and the number of incidents is the number of outages.
- Probe regions describe where a failure is visible. They never decide when an outage starts or ends.
- A failure that the probe regions contradicted isn't part of any outage. If a probe region later fails, the run becomes an outage from that point.
- Checks made during a maintenance window never open or extend an outage. Planned downtime is neither uptime nor downtime.
- An outage is counted once, however many alerts it sent. Repeat notifications don't multiply incidents.
- An outage that hasn't ended is included and measured up to now. An outage that began before the window is measured from the start of the window.
Example: the first failing check is at 10:00 and the first success after it is at 10:25. That is one outage of 25 minutes, even if the notification repeated several times in between.
The same outage figures feed the site's outage list, the recovery alert, the monthly summary email and the activity log, so they agree with each other.
Daily status bars
The bars on a site and on a status page show one block per day. A day takes the first status that applies in this order.
| Day status | Colour in the app | When it applies |
|---|---|---|
| Error | Red | At least one check that day failed and wasn't contradicted or made during maintenance. |
| Partial | Amber | The only failures that day were contradicted by the probe regions. |
| Maintenance | Blue | The day included maintenance checks and no real failure. |
| Changed | Amber | A content change was detected that day. |
| Success | Green | None of the above. |
A public status page has no amber for Partial. A Partial day is drawn as a successful day there, or as a changed day if the page text changed that day.
Heartbeat uptime
A heartbeat has no HTTP checks, so its uptime is slot coverage. OctoPing cuts the window into slots as long as the heartbeat's expected interval and counts the slots that contain at least one ping.
- The grace period isn't part of the calculation. It only delays the missed alert.
- Slots that overlap a maintenance window are left out of both the covered and the expected count. A period made only of maintenance has no value.
- Pings older than the workspace's retention period have been deleted, so the window starts no earlier than the retention limit.
See the checks reference for heartbeat settings and the statuses page for what a maintenance window shows.
Related
- DocsStatusesThe statuses a site and a heartbeat can have in the app and on a public status page, and the order in which the rules apply.
- DocsVantage points and confirmationHow the primary checker and the probe regions confirm a failure, what Partial means and why OctoPing alerts when the probes are silent.
- DocsChecks referenceWhat each of the eight checks and heartbeats measures, whether it is on by default, how often it runs and what counts as a failure or a change.
- FeatureWebsite uptime monitoring with the cause in every alertCheck client sites as often as every 30 seconds, see why a check failed, and flag slow responses as degraded. Planned work stays out of your uptime numbers.