> ## Documentation Index > Fetch the complete documentation index at: https://docs.squasher.ai/llms.txt > Use this file to discover all available pages before exploring further. # Reliability reports > Measure incidents, uptime, MTTR, MTTA, MTTI, response time, on-call escalations, and issues over a time window. Reports show how reliable a project was over a time window. Each report compares the window with the previous window of the same length, so you can see if response and uptime get better or worse. ## Open a report 1. Open your project and select **Reporting** in the sidebar. 2. Select a report. Reports are grouped in sections (see [Reports](#reports)). 3. Select a range: **7d**, **30d**, **90d**, or **Month to date**. 4. On a monitor-based report, select a monitor to show only that monitor. Each report has three parts: * **KPI cards.** Each card shows the value for the window and the value for the previous window of the same length. * **One chart.** Select the bucket size: hour, day, week, or month, when the report supports it. Buckets use your time zone. * **One table.** Each row links to its incident, monitor, or issue. You can export the table as a CSV file. A preset range starts at midnight in your time zone. For example, **7d** is today and the six days before it. Through the API, you can also give an explicit window of up to 400 days. ## Report on all projects To see one report over every project of your organization, select **All projects** at the top of a report. To go back, select **This project**. You can also open **Organization** in the sidebar and select the **Reporting** tab. An all-projects report covers the first 50 projects that you can open. It has no monitor filter. Each table row shows its project, and links open the incident, monitor, or issue in that project. The CSV export has a Project column. ## Reports | Section | Report | What it shows | | - | - | - | | Incidents | **Incidents** | Every incident: when it opened, how long it lasted, and its source. | | Incidents | **Incidents per monitor** | Incidents, total downtime, MTTR, and the longest incident for each monitor. | | Incidents | **Manual incidents** | Incidents that people declared, not monitors or integrations. | | Performance | **SLA** | Uptime per monitor and over time, with incidents, downtime, and MTTR. | | Performance | **MTTR** | Mean time to resolve, with median and P90. | | Performance | **MTTR per monitor** | MTTR for each monitor, to find where recovery is slow. | | Performance | **MTTA** | Mean time to acknowledge, with median and P90. | | Performance | **MTTA per monitor** | MTTA for each monitor, to find where response is slow. | | Performance | **MTTI** | Mean time to identify, with median and P90. | | Performance | **Response time** | Average and P95 response time of checks, per monitor and over time. | | Response | **Escalations** | On-call pages, time to acknowledge, unanswered pages, and notifications sent. | | Errors | **Issues** | New issues, resolved issues, and the mean time to resolve an issue. | | Infrastructure | **Heartbeats** | Uptime of heartbeat monitors: how often each job checked in on time. | The monitor filter is on every report except **Manual incidents** and **Issues**. ## How Squasher measures incidents A report counts the incidents that opened in the window. An incident that opened before the window is not in the report, even when it was still open. | Measure | From | To | | - | - | - | | MTTA | The incident opens | The first acknowledgement. A reopen does not erase it. | | MTTI | The incident opens | The first move to the **Identified** status. | | MTTR | The incident opens | The resolution. For a reopened incident, the latest one. | | Total downtime | The incident opens | The resolution, or now while the incident is open. | MTTA, MTTI, and MTTR use only the incidents that reached that point. For example, an incident that is not resolved is not in MTTR. The MTTR, MTTA, and MTTI reports also show the median and the P90. ## How Squasher measures uptime **SLA** and **Heartbeats** calculate uptime as healthy checks out of all checks that ran. Checks do not run while a monitor is paused, so a paused time does not lower uptime. **SLA** covers every monitor except heartbeat monitors. **Heartbeats** covers only heartbeat monitors. These two reports read daily check counts for each monitor. The days are in UTC, so these reports use UTC and support only day, week, and month buckets. **Response time** shows the average and the P95 latency of checks. Squasher samples about one check every 5 minutes for each monitor. ## How Squasher measures escalations and issues **Escalations** counts the [on-call pages](/features/on-call-escalation) that started in the window. It shows the number of pages, the mean time to acknowledge a page, the pages that nobody acknowledged (exhausted pages), and the texts and calls sent. The table has one row for each escalation policy, with its pages, acknowledged pages, time to acknowledge, unanswered pages, highest level reached, and notifications. **Issues** counts new [issues](/features/issues) by first seen time and resolved issues by resolution time. The mean time to resolve goes from first seen to resolved. ## Limits | Limit | Value | | - | - | | Longest window | 400 days | | Incidents, pages, or issues per window | 5,000. After that, the report shows the first 5,000. | | Table rows | 500. The table shows the full row count. | When a report reads only the first 5,000 records, the API response sets `truncated` to `true`. Use a shorter window to get exact numbers. ## Permissions You see a report only if you can read its data: | Reports | Permission | | - | - | | Incidents, per-monitor incident reports, MTTR, MTTA, MTTI | Read incidents | | SLA, Response time, Heartbeats | Read monitors | | Escalations | Read on-call | | Issues | Read errors | ## Use reports from the API and the CLI ```bash theme={null} squasher reports list --project squasher reports get --project sla --range 30d ``` See the [Reports API](/api-reference/reports) for all parameters and the response shape. ## Next steps Read reports from a script or an agent. Page responders until someone acknowledges. Check endpoints and open incidents when they fail. Send incidents to the channels your team watches. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.