Source connector

Pagerduty connector

Pagerduty integration for databases, warehouses and BI tools

Incident response, on-call schedules, and escalation. Datrise captures Pagerduty entities such as incidents, services, schedules, escalation policies, log entries and responders, then lands normalized and typed models for warehouse reporting, attribution, and AI workflows.

The PagerDuty REST API v2 authenticates with API key, OAuth 2.0, incremental runs key on since / until (date_range query parameters on GET /incidents; most other list endpoints have no equivalent).

Of the 6 objects, 5 sync as upserts keyed on the primary key and 1 as append-only streams, so each incremental run moves only what changed since the last watermark. Every object lands in its own table (for example `pagerduty_incidents`) with a schema derived from the Pagerduty API rather than a flattened CSV, in any of the 43 supported destinations.

Datrise is in early access: pick a destination below to open the Pagerduty pipeline page, and join the waitlist to get the Pagerduty connector with guided onboarding.

Incremental syncSchema-aware mapping43 destinations available

What Pagerduty data Datrise extracts

Each object lands in its own typed table. Sync mode is derived from the object: history-style objects append, everything else upserts.

Object	Landing table	Sync mode
incidents	pagerduty_incidents	Upsert by primary key, incremental on updated-at
services	pagerduty_services	Upsert by primary key, incremental on updated-at
schedules	pagerduty_schedules	Upsert by primary key, incremental on updated-at
escalation policies	pagerduty_escalation_policies	Upsert by primary key, incremental on updated-at
log entries	pagerduty_log_entries	Append-only, incremental by timestamp
responders	pagerduty_responders	Upsert by primary key, incremental on updated-at

Pagerduty API: setup facts for the connector

Verified against the vendor documentation on 2026-09-02. Unknown values are left blank rather than guessed.

API	PagerDuty REST API v2
Authentication	API key, OAuth 2.0 — Account-level API Access Key sent as a Token header, or OAuth2 with Scoped OAuth (granular) or Classic User OAuth (broad, on behalf of a user) app registration.
Pagination	offset — limit/offset with a default limit of 25 and a documented maximum of 100; classic offset pagination has a hard 10,000-record ceiling (limit+offset over that returns HTTP 400).
Rate limit	Not published
Incremental cursor	since / until (date_range query parameters on GET /incidents; most other list endpoints have no equivalent) — Only a handful of endpoints (notably incidents) support since/until; most resources must be fully re-listed and diffed for changes.
Webhooks	Yes — V3 Webhook Subscriptions (service_reference, team_reference, account_reference filters)
Bulk export	No
Deletes detectable	No

Official API reference

What bites when replicating Pagerduty

PagerDuty does not publish a fixed numeric requests-per-minute limit; the official REST API Rate Limits page describes only 'generous rate limits' and directs integrators to the `ratelimit-limit`, `ratelimit-remaining`, and `ratelimit-reset` response headers instead of a documented threshold.
Classic offset pagination on GET /incidents (and similar list endpoints) hard-caps at 10,000 total records: once `limit + offset` exceeds 10,000, the API returns HTTP 400 Invalid Request rather than an empty page.
The `since`/`until` date_range filters are only documented on the incidents endpoint; most other resources (services, users, schedules) have no incremental filter and must be re-listed in full to detect changes.
V1 webhooks reached end-of-support on October 31, 2022 and receive no new features or bug fixes, so new integrations should use V3 Webhook Subscriptions with an explicit service_reference/team_reference/account_reference filter.

Compare this against every other documented API

Popular destinations for Pagerduty

Choose a destination below to open the ready pipeline page.

A
Airtable
Relational spreadsheet destination for ops and go-to-market teams.
View pipeline
A
Amazon Athena
Serverless SQL over S3 data lake tables.
View pipeline
A
Amazon DynamoDB
Serverless key-value and document store on AWS.
View pipeline
A
Amazon QuickSight
AWS serverless BI with SPICE and embedded analytics.
View pipeline
A
Amazon Redshift
AWS petabyte-scale warehouse with Spectrum.
View pipeline
A
Amazon S3 Data Lake
Object storage landing zone for parquet and snapshots.
View pipeline
A
Apache Superset
Open-source BI for SQL exploration, charts, and dashboard publishing.
View pipeline
A
Azure Data Lake Storage
ADLS Gen2 object storage for analytics workloads.
View pipeline
A
Azure Synapse
Microsoft analytics workspace with SQL pools.
View pipeline

Pagerduty connector FAQ

What Pagerduty data does the connector extract?: 6 objects: incidents, services, schedules, escalation policies, log entries and responders. Each lands in its own table with types preserved; history-style objects (1: log entries) load as append-only streams.
Is the Pagerduty integration incremental?: Yes. After the initial full load, every run reads only records changed since the last watermark (updated-at or event timestamp) and applies an upsert or an append depending on the object.
Where can I load Pagerduty data?: Into 43 destinations: relational databases, cloud warehouses, data lakes, spreadsheets and BI tools. Each Pagerduty → destination pair has its own page with the object-to-table mapping.

Related sources

Other sources in the same category, each with its own connector page.

Early access

Launch your Pagerduty pipeline with guided onboarding

Join the waitlist to get priority access for Pagerduty integrations with guided setup, schema-aware mapping, and production-grade incremental sync.