# Number of Pages

{% hint style="warning" %}
Note: this metric is **only shown at a team level**, not an individual level.
{% endhint %}

![Number of Pages graph](https://cdn.prod.website-files.com/610c8a14b4df1ae46b1a13a3/6621a653104d09e01a7e75d8_Number%20of%20pages%20pagerduty.png)

**What it is:**  This is the number of pages grouped by service or escalation policy. You will need to [integrate with PagerDuty](https://docs.multitudes.com/integrations/pagerduty) to get this metric.

**Why it matters:** This metric indicates the stability of your teams’ software. More pages means more incidents, and therefore disruptions to your team's focus. By looking at which services and escalation policies are generating the most pages, you can tune your monitoring to ensure that the pages you get are high signal.

**How we calculate it:** We count the number of unique `incident.acknowledged` events that occurred within the selected date range. We then group by service or escalation policy, and stacked by urgency or priority based on the filter at the top of the Quality of Work page.\
‍\
One incident may have multiple pages, and therefore multiple acknowledgements. These are counted separately.\
If an incident was resolved without getting acknowledged, we count the `incident.resolved` event as the acknowledgement for that incident.

This metric is not available on historical data, because we don't have access to the incident's history of events.

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

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

Generally, fewer pages means fewer things getting broken in production! However, what's most important is that the pages you do get are indeed significant outages that are worth a wake-up call, and not false alarms.

Click on the stacked bars to see if the pages look like signal, or noise.
{% endhint %}