PagerDuty On-Call Hours Export for Payroll

Every month, someone on the engineering or HR team has to produce on call pay figures. If your organisation uses PagerDuty, the data is in there — but getting it into a format payroll can actually use is a different problem. This guide covers exactly what PagerDuty gives you, what it doesn't, and the most reliable ways to bridge the gap.

What PagerDuty exports natively

PagerDuty offers a few built-in ways to get data out:

Incident CSV export

From the Incidents view, you can export a CSV of all incidents in a date range. This includes incident ID, service, status, creation time, resolution time, and the assigned user. It is useful as a raw incident log, but it does not tell you who was on call during non-incident time, and it does not calculate any pay figures.

Schedule view

The schedule view shows who is on call and when, but it is a visual tool — there is no export button that produces a clean list of on call intervals per user. You can screenshot it, but you cannot download it.

Analytics (Business and Enterprise plans)

Higher-tier PagerDuty plans include an Analytics module that aggregates incident data — MTTD, MTTR, incident volume by team, responder load. This is useful for operational insights but is not designed for payroll: it summarises trends rather than listing the raw on call intervals your finance team needs.

The PagerDuty API: what is actually available

The API is where the real data lives. Two endpoints matter most for payroll:

• GET /oncalls — returns on call schedule entries for a given date range, user, or schedule. Each entry includes the user, the schedule, and the exact start/end time of that on call window. This is the foundation of any stipend calculation.
• GET /incidents — returns incidents in a date range, with trigger time, resolution time, assigned user, and service. This is the foundation of any callout fee or hourly rate calculation.

Both endpoints are paginated and rate-limited. For large organisations or long date ranges, you may need to handle pagination carefully (PagerDuty uses offset-based pagination with a limit of 100 items per page) and back off gracefully when you hit rate limits.

What you still have to build yourself

Even with API access, you need to handle:

• Time zone conversion — PagerDuty returns timestamps in UTC. Weekday/weekend boundaries are local-time concepts. An on call shift that ends at 01:00 UTC on a Monday is still Sunday in the UK.
• Day classification — for each day in the on call period, you need to determine whether it is a weekday, weekend, or bank holiday. This requires a bank holiday data source, ideally one that knows about regional differences (England vs Scotland vs Northern Ireland).
• Partial days — on call intervals rarely align perfectly with calendar day boundaries. An engineer might go on call at 18:00 on a Friday. You need to decide whether to pay a partial day rate or a full day rate, and implement that logic consistently.
• Incident matching — joining incidents to on call intervals to determine which incidents fall within a user's on call period (not just which incidents were assigned to them).
• Minimum hours — applying the callout minimum-hours rule correctly, including when multiple short incidents occur in the same shift.
• Spreadsheet formatting — payroll typically wants a structured file with one row per day or per incident, clear column headers, and summary totals. Generating a well-formatted XLSX from API data takes non-trivial effort.

Practical options

Build a script

If you have engineering time to spare, a Python or Node script hitting the PagerDuty API and producing a CSV is achievable in a day or two. The challenge is maintaining it — pay policies change, API rate limits bite during busy months, and the script tends to become a critical piece of infrastructure with no owner.

Use a dedicated tool

Tools like CalloutPay handle the API calls, time zone logic, bank holiday classification, incident matching, minimum-hours rules, and XLSX formatting so you don't have to. You configure your rates once, hit generate, and get a file your finance team can submit directly to payroll. For most teams, this is faster and less error-prone than building and maintaining a custom solution.