# Page Disruptions

<figure><img src="/files/VeRqcAQ6mfSRXpWSes9P" alt="Chart showing Team Yetis had the most disruptions in the past 6 weeks. "><figcaption><p>Page Disruptions</p></figcaption></figure>

**What it is:** The number of pages over time. You can see `Out-of-hours pages` (the ones outside of the responder’s preferred working hours\*, which can contribute to burnout), or `All pages` (includes pages during work hours, whch are still disruptive to a team's focus).&#x20;

*💡 Use our in-chart toggles to view these based on either the number of pages, or the number of hours disrupted by pages.* &#x20;

{% hint style="info" %}
\*By default, this is set to 8am-6pm weekdays, local time. Given that more and more people are working flexible hours, our metric is configurable for different timezones and different preferred working hours and days on each team member's profile in Settings.
{% endhint %}

**You will need to** [**integrate with PagerDuty**](/integrations/pagerduty.md) **to get this metric.**

**Why it matters:** Being woken up in the middle of the night is never fun. Continued disruptions to sleep impact people's productivity, wellbeing, and satisfaction in their workplace. What's more, lots of pages disrupting a team (no matter the hour) can interrupt delivery.

**How we calculate it:** We use the time of acknowledgement as a proxy for when the page was sent out (when the responder was disturbed). We count the number of acknowledgements on incidents, using the time that each `incident.acknowledged` event occurs\*. We then compare this time to the responder's preferred working hours, and figure out if it was an out-of-hours page.

If multiple people acknowledged the incident on PagerDuty, the chart will count all acknowledgements. For example, if Person A acknowledges an incident, then reassigns to Person B who also acknowledges it, both Person A and Person B (and their respective teams) will have +1 to their Page Disruptions on this chart.

\*If an incident was resolved without getting acknowledged, we count the `incident.resolved` event as the acknowledgement for that incident.

{% hint style="info" %}
This metric is not available on historical data, because we don't have access to the incident's history of events.
{% endhint %}

Incidents with the keyword `[test]` in the title (case insensitive) will not be processed.

**Disrupted hours:**  This view shows the number of distinct calendar hours disrupted by pages.  \
For example, if there are pages at 6.30pm, 7.15pm and 7.25pm we would count **two disrupted hours** (6-7pm, and 7-8pm).  &#x20;

Viewing the disrupted hours accounts for the difference (and human impact) between being paged 10 times in one hour for an incident vs five pages over five distinct hours. &#x20;

{% hint style="success" %}
**What good looks like**

Generally, the less pages means the more reliable your tech stack, and the less disruptions to workflow. If the number rises above 1-2, especially for out-of-hours pages, it’s important to ensure that it doesn’t become a trend so that people aren't doing sustained days of long hours and interrupted sleep. Multiple weeks of someone being paged out-of-hours might indicate some QA process changes or reliability work is needed.
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.multitudes.com/metrics-and-definitions/people-metrics/wellbeing/page-disruptions.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
