Core dashboards are the built-in dashboards on the Insights homepage. Each one answers a specific question about how your team is running incidents and on-call, with nothing to set up first.
Insights is available on Pro and Enterprise plans, and access is controlled by the View Insights permission in Settings → Users → Roles. Every panel on a core dashboard can also be added to a custom dashboard, which is how you filter it permanently, combine it with other panels, or put it on a schedule.
What each dashboard answers
A dashboard hides itself when it has nothing to show. If you don’t see one in the list, you’re either missing the product it reports on, you haven’t finished the setup it depends on, or you have no data of that kind yet. Open it and we’ll tell you which of the three applies.
Some dashboards can include private alerts and escalations for people with global access to all private data in your account. Private incidents are always excluded.
For the full list of panels behind these dashboards, and which of them you can add to a custom dashboard, see supported measures.
Pager load is the dashboard to take to a leadership review when you want to talk about on-call burden rather than incident count. It answers how often each person is being paged, when in their day those pages land, how quickly they acknowledge, and how often a page went unanswered.
Pages counts every page sent to a person through an incident.io escalation path, over time and per person, split by time of day.
Escalation MTTA covers response: time to acknowledge over time, acknowledgement per person at high and low urgency, and Missed escalations, where a level timed out before anyone acknowledged it, so the escalation moved on to the next one.
On a trial account, Insights shows anonymised sample data so you can see how the dashboards work before you’ve gathered much of your own. An admin can switch to your real data with the Sample data toggle on the Insights homepage.
Filter and group the numbers
Filters apply to every panel on the dashboard: user, escalation path, schedule, urgency, trigger type, and any alert attribute.
The charts and tables can be grouped by user, escalation path, trigger type, or any alert attribute. Once you have teams set up in Catalog, you also get two team group-bys: Escalation Path => Team, derived from the team that owns each escalation path, and User => Team, derived from the teams the paged person belongs to.
Someone who belongs to more than one team contributes a row per team under User => Team, so the grouped totals
add up to more than the overall total. Group by Escalation Path => Team if you need the shares to sum.
How out-of-hours is decided
Every page is put into one of three bands based on the hour it arrived:
The dashboard labels them Working (8am – 7pm), Late (7pm – 11pm) and Overnight (11pm – 8am). Those labels appear in the trend tiles, the chart legend, and the per-user table headers.
The hour is calculated in the timezone of the person who was paged, not your organization’s timezone and not the viewer’s. A 3am page for someone in Sydney counts as overnight even if the person reading the dashboard is in London and saw it arrive over lunch.
We resolve that timezone in this order:
- The person’s timezone in incident.io. For Slack organizations we keep this in step with their Slack profile timezone, unless they have set their own in account settings, which then takes precedence.
- If we have no timezone for them, the most common timezone across your organization’s users.
The timezone is recorded as it was at the moment of the page, so someone relocating doesn’t retroactively move their old pages into different bands. Everyone sets their own timezone, and nobody can set it for them. So when someone’s pages land in the wrong band, ask them to correct it in their account settings. That fixes future pages and leaves the ones we’ve already counted where they are.
The same bands and the same per-person timezone rule are used for workload metrics on the Time spent on incidents dashboard, so paging load and hours worked stay comparable.
Pager load isn’t limited to paging that went through incident.io On-call. Connect PagerDuty or Opsgenie and we import the paging those tools did, then report on it in a separate Pager load (PagerDuty) or Pager load (Opsgenie) dashboard.
You get pages over time by time of day, and pages per person, filterable by external user and by escalation policy, service, or team. Time of day is banded exactly as described above, using the paged person’s timezone. These pages arrive the day after they happen, and history builds from the day you connect the integration. Escalation MTTA and missed escalations stay specific to incident.io On-call, because we can see that the other tool paged someone but not what they did next.
When both are in play, the native dashboard is renamed Pager load (incident.io) so the two are easy to tell apart.
How fresh the data is
Most dashboards read your data as it happens, so a follow-up you close now shows up as soon as you reload.
Alerts and pager load are the exception, and refresh every few hours. Hover the cloud badge next to the dashboard title to see when the data you’re looking at was last refreshed. Time spent on incidents counts whole hours, so the hour in progress isn’t in the totals yet.
Getting the data out
Every panel and every underlying-data drawer has an Export button, scoped to the filters you have applied. That’s the quickest route to the numbers behind a chart, including per-person pager load and the time-of-day split.
For a standing feed, our API serves the underlying incidents, follow-ups, alerts, and escalations. Load them into BigQuery, Snowflake, or Redshift on a schedule with Fivetran’s incident.io connector or our Singer tap.
Scheduled reports send a dashboard snapshot by email or to Slack on a cadence you pick. Build a custom dashboard with the panels you want first, since schedules run on those rather than on the core dashboards. 
