Source: https://atomicwork.docs.pageloop.ai/product/analytics/operational-reports/incidents-report

# Incidents report

The **Incidents report** gives you comprehensive visibility into how your team identifies, responds to, and resolves service disruptions. Track incident volume, response times, resolution performance, and backlog composition to identify patterns and improve your incident management process.

While you can view incident data by filtering the [Overview](/product/analytics/request-and-service-health/requests-overview) or [Request Aging ](/product/analytics/request-and-service-health/request-aging-report)reports by request type, the **Incidents report is purpose-built for incident managers**. They include incident-specific breakdowns like most/least reported forms and categories, and are pre-filtered to show only incidents, saving you from manual configuration every time.

To access this report, go to **Analytics > Workspaces > \[Workspace name] > Incidents** in the left navigation bar.

### Report filters

You can refine the data shown in the report using the global filters. These filters apply to all widgets and metrics on the dashboard.

- **Duration:** Select a time period such as this month, last quarter, or this year.

- **Attributes:** Filter by specific incident attributes including **Status**, **Priority**, **Impact**, and more.

For example, to analyze urgent incidents assigned to the Engineers group from the past month, set **Duration** to **Last month**, **Group** to **Engineers**, and **Priority** to **Urgent**. This helps you identify if a specific team is being overwhelmed with critical incidents.

For the full set of filters and operators, and how to save a filter combination as a view, see [Filtering reports and saving views](/product/analytics/request-and-service-health/filtering-reports-and-saving-views).

### How the Duration filter works

The **Duration** filter (Today, Yesterday, This week, This month, This quarter, This year, Last week, Last month, Last quarter, or a custom range) sets the start and end of the reporting period in your time zone. You can't pick future dates.

Not every metric uses the same date to decide what falls inside the period:

- Most metrics count incidents **created** in the period. An incident moved in from another workspace counts as created on the date it was moved.

- Completion and resolution metrics count incidents **closed or resolved** in the period, whenever they were created.

- Satisfaction metrics count survey **responses received** in the period.

Each metric's description below says which date it uses. A **% change** compares the selected period with the period of the same length just before it. Deleted incidents are always left out, and other filters narrow the results further.

### Understanding incident analytics

| **Metric**                         | **Description**                                                                                                                                                                                                                                                                                                                                   | **Why it matters**                                                                                                                                                            |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Total incidents created**        | Shows the total number of incidents created (or moved in) within the selected duration, with a % change against the previous period.                                                                                                                                                                                                              | Tracks incident trends over time. A sudden spike may indicate a systemic issue or outage.                                                                                     |
| **Created vs completed**           | Compares the number of incidents created against those completed over time. View trends on a **Daily**, **Weekly**, or **Monthly** basis. The created line uses creation (or move-in) dates in the selected duration; the completed line uses close dates in the selected duration.                                                               | Reveals whether your backlog is growing or shrinking. Consistent gaps signal capacity issues or inefficient resolution processes.                                             |
| **Time to first response**         | Measures how long it takes from incident creation until the first response. Toggle between **Median** and **Average** views. Includes incidents created in the selected duration; those without a first response yet are left out.                                                                                                                | Indicates how quickly your team acknowledges incidents. Long response times can erode employee trust and delay resolutions.                                                   |
| **Time to resolution**             | Shows how long incidents took to resolve, minus any time the SLA clock was paused. Toggle between **Median** and **Average** views. Includes incidents resolved in the selected duration, whenever they were created. If an incident was reopened and resolved again, its total time is used; incidents that are currently reopened are left out. | Reveals overall incident management efficiency. Compare against SLA targets to identify where improvements are needed.                                                        |
| **First response SLA compliance**  | Shows incidents that met (**Hit**) vs missed (**Miss**) their first response SLA. An incident is missed if the response was late, or if there's still no response and the due time has passed. SLA pauses are taken into account. Includes incidents created in the selected duration, judged as of now; incidents without an SLA are left out.   | Measures how well your team meets response commitments. Low compliance indicates need for better routing, staffing, or SLA definitions.                                       |
| **Resolution SLA compliance**      | Shows incidents that were resolved on or before (**Hit**) vs after (**Miss**) their resolution SLA due time. SLA pauses are taken into account. Includes incidents resolved in the selected duration; incidents without an SLA are left out.                                                                                                      | Tracks resolution performance against commitments. Identifies if SLA targets are realistic or if process improvements are needed.                                             |
| **Unresolved incidents by Status** | Shows the number of incidents in each current status, open or closed, such as **Open**, **Pending**, **Waiting for approval**, and **Waiting on vendor**. Includes incidents created in the selected duration.                                                                                                                                    | Pinpoints bottlenecks. If most incidents are "Waiting on vendor," you may need better vendor SLAs or escalation processes.                                                    |
| **Unresolved incidents by Impact** | Shows the number of incidents, open or closed, at each impact level, such as **Medium** and **High**. Includes incidents created in the selected duration.                                                                                                                                                                                        | Helps prioritize team focus. A backlog heavy with high-impact incidents signals urgent capacity or process issues.                                                            |
| **Most reported incident forms**   | Shows the top 10 incident forms (e.g., **Plumbing issues**, **Battery Drain Issue**, **Device audio issues**) by number of incidents created in the selected duration.                                                                                                                                                                            | Identifies recurring problem areas. High volumes in specific categories suggest opportunities for preventive measures or knowledge articles.                                  |
| **Least reported incident forms**  | Shows the bottom 10 incident forms by number of incidents created in the selected duration. Forms with no incidents in the period don't appear.                                                                                                                                                                                                   | Helps identify rarely-used forms that may need review, or areas where proactive maintenance is working well.                                                                  |
| **Most reported categories**       | Shows the top 10 categories (e.g., **Hardware**, **Facilities**) by number of incidents created in the selected duration.                                                                                                                                                                                                                         | Identifies which areas drive the most incident volume. High concentration in one category may indicate recurring issues or inadequate preventive measures.                    |
| **Least reported categories**      | Shows the bottom 10 categories by number of incidents created in the selected duration. Categories with no incidents in the period don't appear.                                                                                                                                                                                                  | Helps identify rarely-used categories that may need review, or areas where proactive measures are working well.                                                               |
| **Age of incidents**               | Groups incidents that are still open into up to 8 time buckets, based on how long they've been open. Buckets are dynamically sized based on the oldest incident. Includes incidents created in the selected duration that are still open today; age is measured up to today.                                                                      | Shows backlog composition by age. A large number of old incidents indicates process bottlenecks or deprioritization of certain types.                                         |
| **Employee satisfaction by week**  | Shows the percentage of positive survey responses on incidents, plotted by response date, with the overall percentage and the change against the previous period. Only the latest response per incident counts. Includes responses received in the selected duration, whenever the incident was created.                                          | Measures how well your incident resolution process meets employee expectations. Declining scores may indicate longer resolution times, poor communication, or quality issues. |

You can analyze these metrics in combination to diagnose specific issues and drive improvements. For example, say you notice:

- **Created vs completed** shows incidents being created faster than they're resolved (60 created, 8 completed)

- **Unresolved incidents by Status** reveals most are stuck in **Open** status

- **Most reported incident forms** shows **WiFi connectivity issues** dominating

- **Time to first response** averages 2 days 23 hours

- **First response SLA compliance** is only 5.8%

This means, WiFi-related incidents are overwhelming your team. They're not being responded to quickly (2+ days), causing severe SLA breaches, and creating a growing backlog of unresolved incidents.

**What you can do:**

- Create a verified answer or troubleshooting guide for common WiFi issues (wrong network, password reset, router restart)

- Review if WiFi incidents need dedicated routing to Network Engineering vs. general IT helpdesk

- Investigate if the spike indicates a broader infrastructure issue (failing access points, network configuration problems) rather than individual user problems

### Drilling down and exporting data

Click **View breakdown** on any tile or chart to open a detailed view of the exact incidents behind that number. The drill-down view lets you:

- View a list of all individual incidents contributing to that metric

- See details such as **Subject**, **Requester**, **Groups**, **Category**, **Incident Form**, **Impact** and more

- Add or remove columns to customize the view

- Apply additional filters to refine the list further

You can also download the data from any widget or drill-down view as a CSV file for external analysis, stakeholder reporting, or custom calculations.

To export data, open a drill-down view and click **Download as CSV**.
