> ## Documentation Index > Fetch the complete documentation index at: https://docs.scaling.cloud/llms.txt > Use this file to discover all available pages before exploring further. # Insights > Response-quality metrics for your organization — incident volume, response times, out-of-hours paging, longest silence, and time to mobilize. **Insights** is a dashboard view that summarizes how your team responds to incidents across a date range. Open it from **Insights** in the dashboard. Every metric is scoped to your organization and recomputed each time you load the page for the selected range. Pick a range (last 7, 30, or 90 days) and Insights shows the metrics below alongside a **prior-period comparison** — the same metric over the immediately preceding window of equal length — so you can see whether a number is trending up or down. ## Why durations use the median Every duration metric on this page — MTTA, MTTR, longest silence, and time to mobilize — is aggregated as the **median**, not the mean. A single outlier poisons a mean. One incident that stayed open for a week drags an arithmetic average so far that the trend line stops describing a typical incident. The median is robust to that outlier: it reports the middle incident, so the number stays representative of what your team actually experiences. Only incidents that reached a metric's endpoint enter that metric's sample. An incident that was never acknowledged does not count toward MTTA; one that was never resolved does not count toward MTTR. When no incident qualifies, the metric reports no value rather than zero. ## Incident volume The total number of incidents opened in the range, with a per-day breakdown. Days are bucketed in UTC. ## Response times | Metric | What it measures | | -------- | ----------------------------------------------------------------------------- | | **MTTA** | Median time to acknowledge — from incident creation to first acknowledgement. | | **MTTR** | Median time to resolve — from incident creation to resolution. | Both are medians (see [above](#why-durations-use-the-median)). The prior-period percentage change is computed on the medians themselves, not on a separate average. ## Out-of-hours paging How often your responders are paged outside business hours — an early burnout signal. Insights shows the out-of-hours page count and its **share of total pages** for the range. A page is classified **out-of-hours** when it falls outside your organization's working hours. The hours used depend on whether you've designated a default: * If your organization has designated a [default working hours set](/concepts/working-hours#org-default-working-hours-and-insights), the metric classifies pages against **that set's windows and timezone** — so the number reflects your organization's real hours. * Otherwise, the metric falls back to a **fixed convention** of **09:00–17:00, Monday–Friday**. The window is inclusive of 09:00 and exclusive of 17:00; weekends are always out-of-hours. When the **fixed convention** applies, its window is evaluated in a timezone resolved in this order: 1. The **timezone of the on-call schedule** that was paged. 2. If the page targeted a literal list of users rather than a schedule, the **organization timezone**. 3. If neither is set, **UTC**. A designated default set instead carries its **own** timezone, and classification never uses the working hours set that gated the escalation layer which dispatched the page — that would measure your [skip logic](/concepts/working-hours#layer-conditions-follow-the-sun-escalation) rather than human disruption. Classification is computed at read time from existing paging timestamps. The window is anchored to a single timezone — the default working hours set's, or under the fixed convention the paged schedule's — rather than each individual responder's, so a page to a responder in a different region may be classified against those hours rather than their own. This is a deliberate trade-off — the metric is a trend signal, not a per-page audit. ## Longest silence The longest a resolved incident went without a human update — the gap that erodes customer and stakeholder trust during an incident. Per resolved incident, Insights measures the **longest gap between consecutive human updates** on the timeline. Incident creation and resolution bound the window as implicit posts, so: * A resolved incident with **no human updates** scores its **entire** creation-to-resolution duration — the worst case is never invisible. * Only human updates count as touches. An [automated update](#automated-actions-and-origin) such as an auto-resolution is not communication, so it does not break a silence. These per-incident longest gaps are then aggregated as the **median** across the resolved incidents in the range. ## Time to mobilize For incidents a machine opened, how long until a person actually engaged. Acknowledging an alert means a human became aware; it does not mean anyone started working. Time to mobilize measures that next step. It is the duration from a **system-origin** incident's creation to its **first human update** (of any visibility — internal or public). See [Automated actions and origin](#automated-actions-and-origin) for what makes an incident system-origin. * Only **auto-opened (system-origin) incidents** are sampled. Incidents a person opened are excluded entirely — opening an incident yourself is mobilization at the moment of creation, so including them would distort the median. * An auto-opened incident that no person ever touched (for example, one that auto-opened and auto-resolved) has no mobilization endpoint and is dropped from the sample, the same way MTTA ignores never-acknowledged incidents. The qualifying durations are aggregated as the **median**. ## Automated actions and origin Some incidents and updates are created by people; others are created by the platform — an incident auto-opened from an ingested alert, an auto-resolution when the upstream alert clears, or a provisional status page being promoted. Each incident and each [Incident Update](/concepts/incidents#incident-updates) carries an **origin** of either `human` or `system` that records which. The longest silence and time to mobilize metrics rely on `origin` to tell communication from automation: a system auto-resolution is not a human touch, and a system-opened incident is the only kind time to mobilize measures. The same `origin` field drives how actions are attributed on the timeline and on your public status pages. See [Incidents — Origin](/concepts/incidents#origin-human-vs-system) for that behavior and for where `origin` appears in the API.