# Uptime reports

Source: https://www.pingtower.com/docs/service/uptime-reports/

Uptime, outages and downtime for every check and status-page component over a period you pick, and how fast your team acknowledges and resolves alerts.

The report covers the whole team: every check in every project, every component on every status page, and the alert response times of each project. In the [web app](https://app.pingtower.com) it is **Uptime & SLA**; the iOS app shows the same report under Account → Uptime & SLA.

## Periods

Pick the last 7, 30 or 90 days, or a custom range of dates up to 366 days long. A custom range cannot reach past now. The report is computed from what Pingtower already keeps, so a range starting before a check or component existed simply has less in it.

## Checks

One row per check:

| Column | Meaning |
| --- | --- |
| `project`, `check` | Which check. |
| `uptime_percent` | The share of judged runs that passed. Empty when nothing in the period could be judged. |
| `outages` | How many separate outages. |
| `downtime_seconds` | Total downtime. |
| `longest_downtime_seconds` | The longest single outage. |
| `judged_runs` | How many runs the figure is made of. |

A check's figures come from its hourly history. A run is judged unless it was an error (the check could not reach a verdict) or it ran while a [maintenance window](/docs/service/maintenance/) covered it. A run that came back up or degraded counts as passing; only down counts against uptime.

Downtime is counted by the hour: an hour with down runs adds the hour times the share of its judged runs that were down. An outage is a stretch of consecutive hours each with at least one down run. An hour with no history, or nothing judged, ends it.

## Status-page components

One row per component, grouped by page:

| Column | Meaning |
| --- | --- |
| `page_id`, `page`, `component_id`, `component` | Which component, on which page. |
| `uptime_percent` | By the page's own rules, below. Empty when none of the period could be measured. |
| `outages`, `downtime_seconds`, `longest_downtime_seconds` | As for checks, from the component's timeline. |
| `maintenance_seconds` | How much of the period maintenance took out of the measure. |

A component's uptime is time in state, the same figure its status page shows. Downtime is major outage time plus 0.3 of partial outage time; degraded is not downtime. Where states overlap, the worst one wins, so an hour that was both partial and major counts once, as major. Time before the component was created is left out.

Maintenance is left out too, neither up nor down, and reported as `maintenance_seconds`:

- Time whose worst state was a shown window's maintenance. An outage during that window is worse than maintenance, so it stays in and counts.
- Time a window not shown on any status page covered, for a component whose every binding the window covers. That time is left out whole, outages included.

See [Maintenance windows: on a status page](/docs/service/maintenance/#on-a-status-page) for the difference. A window not shown on a status page is kept for 95 days after its last occurrence, so a custom range reaching further back than that no longer leaves its time out.

## Response times

One row for the whole team, then one per project:

| Column | Meaning |
| --- | --- |
| `alerts` | Alerts that opened in the period. |
| `acknowledged`, `resolved` | How many of those were acknowledged, and resolved. |
| `mtta_seconds` | Mean time from opening to acknowledgement. Empty when none was acknowledged. |
| `mttr_seconds` | Mean time from opening to resolution. Empty when none was resolved. |

An alert counts in the period it opened, whenever it was handled. The team row is over every alert of those projects, not an average of the projects' averages.

Resolved alerts leave the [alert history](/docs/service/alerts/) after thirty days by default. Before they go, the times these figures need (when the alert opened, was acknowledged and was resolved) are archived for a year from when it opened, so a range up to a year back still has them.

## Export

Each of the three tables downloads as CSV from the web app, with the columns above in that order. An empty cell means there is no figure, which is different from zero. A name a spreadsheet would read as a formula (starting with `=`, `+`, `-` or `@`) is written with a leading `'`.

## Who can see it

Every role, viewers included, and any [custom role](/docs/getting-started/concepts/#custom-roles) with `sla:read`. A member [limited to some projects](/docs/getting-started/concepts/#per-project-roles) sees checks and response times only for the projects whose grant role holds `sla:read`. They see every status-page component, but its uptime and outages leave out what came from a binding to a project outside their grants.