Software companies
How to export PagerDuty incident history
By SourceX Editorial · Updated
Short answer
To export PagerDuty incident history in full, use the PagerDuty REST API: pull each incident with its log entries, notes and alerts, save the raw JSON and reconcile counts against the web app. Spreadsheet downloads from incident and reporting views are summaries; they rarely carry the timeline that shows how responders actually handled each incident.
Key takeaways
- The API export is the record; any spreadsheet download from the web app is a convenience copy.
- Log entries are the incident timeline, and they are the layer most quick exports leave out.
- Export services, teams, escalation policies and users first so every ID in the incident data still resolves later.
- Redact on a copy: pseudonymize responders, strip contact methods and mask hosts consistently rather than deleting them.
- Finish and verify the export before an account is downgraded, merged or closed.
What is the best way to export PagerDuty incident history?#
The best way to export PagerDuty incident history is through the PagerDuty REST API, pulling each incident together with its log entries, notes and alerts. The web app's incident and reporting views can produce spreadsheet downloads, but those files are built for counting and review, not for preserving how each incident unfolded.
The difference matters once the export has a purpose beyond an operations review. A tool migration, an acquisition, an audit request or a data licensing review all need the timeline: who was paged, who acknowledged, when the incident escalated, what responders wrote and how it was resolved. A row per incident with a start time and a resolve time cannot answer those questions.
Check the current API reference before you start, because endpoints, pagination behavior and rate limits change over time.
Which export path fits which job?#
PagerDuty export paths differ mainly in depth. Pick the path by the question the data must answer later, not by which button is easiest to find.
| Export path | What you usually get | What is usually missing | Good for |
|---|---|---|---|
| Incident list download in the web app | One row per incident: title, service, urgency, status, assignee and key times | Timeline entries, note text, alert payloads | Quick counts and spot checks |
| Reporting and analytics views | Metrics such as time to acknowledge, time to resolve and interruptions, depending on plan | The narrative of each incident | Operations reviews and staffing decisions |
| REST API, incident list plus detail calls | Incidents, log entries, notes, alerts, assignments and references to services and teams | Postmortems kept in other tools | Archives, migrations, audits and licensing reviews |
| Postmortem documents | Written analysis, contributing factors and follow-up actions | Often stored outside PagerDuty entirely | Root cause history and learning reviews |
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
Fields to keep for every incident#
Fields worth keeping fall into six record groups, and the timeline group is the one most exports drop. Keep identifiers in every group so records can be joined back together after export.
If your team writes postmortems inside PagerDuty, confirm whether your plan exposes them for export. Many software companies write postmortems in Confluence, Notion or Google Docs instead, so the archive needs a mapping from each incident number to its postmortem document.
| Record group | Fields worth keeping | Why it matters later |
|---|---|---|
| Incident | ID, incident number, title, service, escalation policy, urgency, priority, status, created, acknowledged and resolved times | Anchors every other record and supports time-based analysis |
| Timeline (log entries) | Entry type, timestamp, actor and channel for trigger, notify, acknowledge, escalate, reassign and resolve events | Shows the real sequence of response, including escalations and handoffs |
| Notes | Author, timestamp and full text | Holds responder reasoning: hypotheses, actions tried and decisions made |
| Responders and assignments | User or team, role, response requests and acknowledgment time | Shows who was pulled in and when, even after names are replaced |
| Alerts | Source integration, summary, deduplication key, severity and custom details payload | Connects the human response to the signal that started it |
| Links out | Postmortem URL, Jira or Linear keys, Slack channel name, deploy or change references | Joins the incident to the fix and the follow-up work |
Step by step: an API export you can verify#
An API export you can verify follows a fixed order: reference data first, incidents second, detail records third, reconciliation last. Script every step so a second engineer can rerun it and get the same counts.
Keep timestamps in UTC as delivered and say so in the README. Mixed time zones can make an exported timeline look out of order, which undermines the main reason for keeping it.
- Create a dedicated read-only API key if your account settings allow one, owned by a service account, and record who created it and when it will be revoked.
- Export reference data first: services, teams, escalation policies, schedules and users, so every ID in the incident data can be resolved later.
- List incidents in bounded date windows, such as one month at a time, because list endpoints paginate and enforce rate limits that a single long query can hit.
- For each incident, request its log entries with full detail, its notes and its alerts, and save each response as raw JSON exactly as returned.
- Build a flattened table for analysts from the raw files, but keep the raw JSON as the source of record.
- Reconcile incident counts per service per month against the web app, and read several long incidents end to end in both places.
- Store the archive read-only with a README covering export date, script version, time zone handling and a field guide.
What to redact before incident data leaves engineering#
Incident data carries more personal and security detail than most teams expect, so redaction belongs on a copy made before anyone outside engineering sees it. The raw archive stays internal, read-only and access-controlled.
Consistent replacement matters more than aggressive deletion. A timeline where every host becomes the same blank token loses the story; a timeline where host A and host B stay distinct keeps it.
- Responder identities: replace names and emails with stable pseudonyms, keeping role and team so the escalation pattern still reads correctly.
- Contact methods: remove phone numbers, email addresses and device details that appear in notification entries.
- Infrastructure: mask hostnames, IP addresses, internal URLs, database names and cloud account identifiers, giving each one its own placeholder.
- Alert payloads: scan custom details for API keys, tokens, connection strings and stack traces with file paths, a common hiding place for secrets.
- Customer references: replace customer names and tenant or account IDs in titles and notes, which often name the affected customer.
- Bridges and chat: drop conference links, dial-in PINs and pasted chat transcripts that name people outside the response.
Illustrative: an inspection software company consolidates on-call tools#
Illustrative: a fictional software company sells inspection scheduling and compliance software to elevator maintenance contractors. Its platform team has run on-call through PagerDuty for years, with alerts from its monitoring stack, postmortems in Confluence and follow-up work in Jira. After acquiring a smaller competitor, leadership decides to consolidate on-call tooling and retire one PagerDuty account.
The CTO asks for a full archive before the account closes. The first spreadsheet download shows titles and resolve times but no escalation history, so the team scripts an API export month by month, pulls log entries, notes and alerts, and reconciles counts per service. The review finds personal mobile numbers in notification entries and database hostnames and customer account IDs in alert payloads.
The team keeps the raw export read-only in its own storage and builds a separate redacted copy with pseudonymous responders, masked infrastructure and a mapping from each incident number to its Confluence postmortem and Jira follow-ups. When the company later runs a metadata-only fit check for licensing, it describes the redacted copy, not the raw one.
Why linked incident history beats a log dump#
Linked incident history beats a log dump because it records judgment under pressure: which signal mattered, who was pulled in, what was tried and what fixed it. A pile of alerts with no responder actions shows noise; an incident joined to its notes, postmortem and follow-up fix shows how a team diagnoses and recovers.
That linkage is what AI developers look for when they build and evaluate agents for IT incident recovery and on-call support. In the SourceX Enterprise Data Value Framework, domain expertise, human-generated signal and AI utility raise value, while privacy burden and preparation cost reduce net value, so a joined, carefully redacted export usually compares well against a larger but disconnected one.
How SourceX approaches incident records#
SourceX treats incident history as one record family within the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The fit check asks only for metadata, such as which on-call and postmortem tools you use, roughly how much history is still exportable and whether incidents link to tickets and fixes; no exports are requested at that stage.
If a package proceeds, the supplier approves what is included, and SourceX documents provenance, licensing rights, permitted use, the privacy record and release authorization in a SourceX Evidence Packet. Large archives stay in the company's own storage, and the data is licensed, not sold, so the company keeps ownership.
Frequently asked questions
Does canceling a PagerDuty account delete incident history?
Assume it may. What happens to data after cancellation depends on your agreement and PagerDuty's current policies, so check both and complete a verified export before the subscription ends. A downgrade may also remove features the export relies on, such as certain API access or analytics views, so export first and change plans second.
Can we export incidents for only some services or teams?
Usually yes. Incident list queries typically accept service and team filters; confirm the parameters in the API reference. Record the filter in the README, and check for incidents reassigned across teams, because a team filter can miss the part of an escalation that happened elsewhere in the organization.
How far back can we export?
As far back as the account still holds records, subject to your plan and any retention settings. Test the oldest month first rather than the newest. If early incidents are missing or incomplete, you want to know before designing the archive around them, and before anyone promises a history length in a migration plan.
Should the export include alerts that never became incidents?
Usually not for an archive meant to show response work. Alerts grouped into incidents matter because they explain what triggered a response. Standalone alert noise is bulky, low in human signal and heavy with infrastructure detail, so keep it only if a monitoring review or alert tuning project needs it.
Do responders need to be told before incident data is shared outside the company?
An internal archive rarely needs a notice, but sharing outside the company is a separate decision. Notes and timelines record individual employees' work, so review employee notices, internal policies and any privacy laws that may apply with counsel, and explain the purpose and safeguards to the team before anything is released.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.