PagerDuty On-Call Reporting: A Manager's Guide

If you manage an on call engineering team, you probably deal with two kinds of on call reporting: operational reporting (incident volume, response times, who is burning out) and payroll reporting (what does everyone get paid this month). PagerDuty handles the first type reasonably well. The second is largely left to you. This guide covers both — and how to make the payroll side reliable enough that finance stops sending it back.

Operational on call reporting

For operational insights, PagerDuty has solid built-in tooling depending on your plan:

Incident reports

The Incidents view lets you filter by date range, team, service, urgency, and assignee. You can export a CSV of incidents for any period. This is useful for reviewing incident load per engineer, identifying noisy services, or tracking MTTR trends.

Schedule reports

The schedule view shows who is covering each rotation. If you want to see how on call burden is distributed across the team, the schedule view gives you a visual picture — though you cannot export it directly as data.

Analytics (Business/Enterprise)

Higher-tier plans include an Analytics module covering responder load, notification volume, MTTD and MTTR by team and service. This is valuable for identifying who is being over-burdened and which services need reliability investment. It is not designed for payroll — it summarises trends rather than producing per-engineer per-day pay figures.

Payroll on call reporting

This is where most teams struggle. A payroll-ready on call report needs to answer, for each engineer and each pay period:

• How many weekday, weekend, and bank holiday on call days did they work?
• How many incidents were they paged for outside business hours?
• How many hours of active incident work did they perform (if your policy includes an hourly rate)?
• What is the total gross on call pay for the period?

PagerDuty does not produce this report. You have to build it from the raw API data.

Building a reliable reporting process

1. 1Define the reporting period clearly — calendar month is most common. Decide whether you use the schedule start/end time or the incident trigger time as the boundary for edge cases (e.g. an incident triggered at 23:58 on the last day of the month).
2. 2Pull on call intervals from the PagerDuty /oncalls API for each engineer in the period. These give you the raw start and end times of each on call window.
3. 3Classify each day in each on call window as weekday, weekend, or bank holiday using the correct regional calendar for each engineer's location.
4. 4Pull incidents from the /incidents API for the same period. Match them to on call intervals to determine which incidents fall within each engineer's shift.
5. 5Apply your policy rules: callout fees, minimum hours, business hours exclusions, and any applicable caps.
6. 6Produce a structured file with one section per engineer: a day-by-day breakdown of on call days and incidents, and a summary row with the total pay figure.
7. 7Have the engineer or their manager review and sign off before submitting to payroll. A single line item they can query is much better than a black-box total.

What finance needs to see

Finance and HR teams are not PagerDuty users. They need a report that:

• Requires no PagerDuty access or knowledge to verify
• Shows the calculation clearly — not just a total, but the line items that add up to it
• Uses the same column structure every month so they can process it without relearning the format
• Clearly attributes each figure to a named employee with their cost centre or department
• States the pay period and the policy version it was calculated against

Common reasons finance sends it back

• The total does not match their expectation from the previous month with no explanation
• The format changed — different columns, different date format, different employee identifiers
• The bank holiday dates used are not the ones in the company HR system (a common mismatch when England rates are applied to Scottish employees)
• There is no breakdown — just a per-person total with no supporting detail

Making it consistent

The single biggest improvement most teams make is switching from a monthly ad-hoc process to a consistent, repeatable one. That means the same tool, the same settings, the same report format every month — so that differences in the pay figure are explainable by differences in on call load, not by differences in who built the report.

Whether you build that consistency through a well-maintained internal script or a dedicated tool, the key is that anyone on the team can produce the report in the same way, and the output can be verified against the raw PagerDuty data.