> ## Documentation Index
> Fetch the complete documentation index at: https://support.configview.com/llms.txt
> Use this file to discover all available pages before exploring further.

# PagerDuty setup

ConfigView reads your PagerDuty account through PagerDuty's REST API, using one **read-only account API key** that an Admin or the Account Owner creates.

You will end up with **1 secret** in ConfigView (`PAGERDUTY_API_KEY`), plus a second (`PAGERDUTY_REGION`) if your account is in PagerDuty's EU region.

> **Scope of this integration today.** ConfigView reads who has PagerDuty and with what role and license, how PagerDuty can reach each person (how many email, phone, SMS and push methods and notification rules, never the numbers themselves), teams and their members, on-call schedules, escalation policies and who is on call now, services and every tool that sends them alerts, every place PagerDuty sends incident data (extensions, webhook subscriptions, Incident Workflow connections), the apps people have authorized against PagerDuty, and the Audit Trail of who changed what. ConfigView only reads. It never creates, changes or deletes anything, and it never reads incidents, alerts, notes, phone numbers, integration keys or webhook secrets.

***

## Step 1: Open the PagerDuty page in ConfigView

Open ConfigView in a second browser tab and leave it open:

`https://{companyname}.configview.com/admin/integrations/pagerduty`

PagerDuty shows an API key once, when you create it, so paste it straight into ConfigView instead of keeping it in a notes file.

***

## Step 2: Check your service region

Look at the address bar when you are signed in to PagerDuty:

| Address in your browser | `PAGERDUTY_REGION` |
| - | - |
| `yourcompany.pagerduty.com` | leave it empty |
| `yourcompany.eu.pagerduty.com` | `EU` |

If your address ends in `.eu.pagerduty.com`, type `EU` into `PAGERDUTY_REGION` under **Credentials** and click the save icon. An EU key sent to the US address is rejected.

***

## Step 3: Create a read-only account API key

Use an account (General Access) key, not a personal one. A personal User API key only sees what that one person can see, can't read the Audit Trail unless they are an admin, and stops working when they leave.

1. Sign in to PagerDuty as an **Admin** or the **Account Owner** (only they can create account keys)
2. Open **Integrations → Developer Tools → API Access Keys**
3. Click **Create New API Key**
4. **Description:** `ConfigView`
5. Tick **Read-only API Key**, so the key can only make read (`GET`) calls
6. Click **Create Key** and copy the key
7. Switch to the ConfigView tab, paste it into `PAGERDUTY_API_KEY` under **Credentials**, and click the save icon

The REST API is on every current PagerDuty plan. Some data needs a particular plan (see **Plan requirements** below); without it, that table stays empty and nothing fails.

***

## Step 4: Connect and verify

1. Back on `https://{companyname}.configview.com/admin/integrations/pagerduty`, confirm the credentials show as saved
2. Click **Connect**. ConfigView creates its tables and schedules every collector at your default run time. Stop any you don't want under **Collectors**:

| Script | Notes |
| - | - |
| **Account Features** | The features the PagerDuty account's plan turns on (teams, SSO, audit trail, advanced permissions and so on), one row per feature. |
| **Users** | Every PagerDuty user: name, email, role (owner, admin, user, observer, stakeholder), teams, whether they came in through SSO or are still only invited, and how many ways PagerDuty can reach them (email, phone, SMS, push) and notification rules they have. The phone numbers and addresses themselves are not stored. |
| **Licenses** | The PagerDuty licenses the account has bought, how many of each are in use and free, and which user holds which license since when. |
| **Teams** | PagerDuty teams, whether each is private or open to the rest of the account, and who belongs to each team with their team role (manager, responder, observer). |
| **On-Call Schedules** | On-call schedules: time zone, which escalation policies use each one, and every person in its rotation. |
| **Escalation Policies** | Escalation policies: which services use each one, and at each level who gets paged (a person or a schedule) and how many minutes before it moves on. |
| **Who Is On Call** | Who is on call right now for each escalation policy and level, from which schedule, and until when. |
| **Services** | PagerDuty services: status, owning team, the escalation policy that pages people for it, when it last had an incident, and every tool that sends it alerts. Integration keys and inbound email addresses are not stored. |
| **Service Extensions** | Extensions attached to services that send incident data out of PagerDuty (Slack, ServiceNow, Jira, generic webhooks): the kind, the host it posts to, which services use it and whether PagerDuty has disabled it after failures. |
| **Webhook Subscriptions** | Webhook subscriptions that push incident events out of PagerDuty: the host they post to, whether they cover the whole account, one team or one service, which events they send and whether they are active. Runs after **Services** and **Teams**. |
| **Workflow Connections** | Accounts in outside tools that PagerDuty Incident Workflows are connected to (Microsoft Teams, Jira, ServiceNow, Zoom and others): the tool, the host, the permissions granted, who set it up and whether it is healthy. |
| **Connected Apps per User** | Apps each user has signed in to or authorized against PagerDuty (web, mobile and third-party integrations): the app, the permissions granted, and when the grant was made and expires. Runs after **Users**. |
| **Audit Trail** | Who changed what in PagerDuty: each change to a user, team, schedule, escalation policy or service, who made it, through which API key or app, from which IP, and the names of the fields changed. Kept as a growing history. |

3. Click **Verify now**. The health check confirms the key, reads the user list, then reads one record from each kind of data.

If a check fails:

* **"PagerDuty API key" fails with 401.** The key is wrong or was deleted, or your account is in the other region. Check `PAGERDUTY_REGION` (Step 2).
* **"PagerDuty users" fails.** The key is valid but can't list users. Use an account key created by an Admin or the Account Owner (Step 3), not a personal key.
* **A check is skipped with "not available".** The feature it names isn't on your PagerDuty plan, or the key can't reach it. Everything else still works; that table stays empty.
* **"Audit Trail" is skipped.** Your plan doesn't include Audit Trail (PagerDuty answers 402), or the key is a personal key of someone who is not an admin.

***

## Plan requirements

| Data | Needs |
| - | - |
| Users, schedules, escalation policies, on-calls, services, extensions, webhook subscriptions | Any current plan |
| Teams and team members | A plan with Teams |
| Licenses | A plan with license management |
| Workflow Connections | A plan with Incident Workflows |
| Audit Trail | A plan with Audit Trail |

The **Account Features** table lists what your plan turns on.

***

## Data Tables

Once the scripts run, these tables are created in your database. Each includes a `run_at` column. Every table keeps only the newest run, except `pagerduty_audit_records`, which keeps every record ever collected.

| Table | Source | Key Columns |
| - | - | - |
| `pagerduty_abilities` | `GET /abilities` | ability |
| `pagerduty_users` | `GET /users` | user\_id, name, email, role, job\_title, time\_zone, invitation\_sent, created\_via\_sso, team\_count, team\_names, contact\_method\_count, email\_methods, phone\_methods, sms\_methods, push\_methods, whatsapp\_methods, notification\_rule\_count |
| `pagerduty_licenses` | `GET /licenses` | license\_id, name, role\_group, valid\_roles, current\_value, allocations\_available |
| `pagerduty_license_allocations` | `GET /license_allocations` | user\_id, user\_name, license\_id, license\_name, role\_group, allocated\_at |
| `pagerduty_teams` | `GET /teams` | team\_id, name, description, default\_role, parent\_team\_id, parent\_team\_name, member\_count |
| `pagerduty_team_members` | `GET /teams/{id}/members` | team\_id, team\_name, user\_id, user\_name, team\_role |
| `pagerduty_schedules` | `GET /schedules` | schedule\_id, name, time\_zone, user\_count, escalation\_policy\_count, escalation\_policy\_names, team\_names |
| `pagerduty_schedule_users` | `GET /schedules` | schedule\_id, schedule\_name, user\_id, user\_name |
| `pagerduty_escalation_policies` | `GET /escalation_policies` | policy\_id, name, num\_loops, rule\_count, target\_count, service\_count, service\_names, team\_names |
| `pagerduty_escalation_targets` | `GET /escalation_policies` | policy\_id, policy\_name, rule\_level, escalation\_delay\_minutes, target\_type (user or schedule), target\_id, target\_name |
| `pagerduty_oncalls` | `GET /oncalls` | policy\_id, policy\_name, escalation\_level, user\_id, user\_name, schedule\_id, schedule\_name, start\_at, end\_at |
| `pagerduty_services` | `GET /services` | service\_id, name, status, created\_at, last\_incident\_at, escalation\_policy\_id, escalation\_policy\_name, team\_names, alert\_creation, urgency, integration\_count |
| `pagerduty_service_integrations` | `GET /services?include[]=integrations` | service\_id, service\_name, integration\_id, name, integration\_type, vendor\_name, created\_at |
| `pagerduty_extensions` | `GET /extensions` | extension\_id, name, schema\_name, target\_host, temporarily\_disabled, service\_count, service\_names |
| `pagerduty_webhook_subscriptions` | `GET /webhook_subscriptions` | subscription\_id, description, active, target\_host, temporarily\_disabled, filter\_type, filter\_id, filter\_name, event\_count, events, custom\_header\_count |
| `pagerduty_workflow_connections` | `GET /workflows/integrations/connections` | connection\_id, integration\_name, name, target\_host, external\_id\_label, scopes, is\_healthy, created\_at, created\_by\_name |
| `pagerduty_oauth_delegations` | `GET /users/{id}/oauth_delegations` | user\_id, user\_name, user\_email, client\_id, delegation\_type, status, scope, created\_at, expires\_at |
| `pagerduty_audit_records` | `GET /audit/records` | record\_id, execution\_time, action, root\_resource\_type, root\_resource\_name, resource\_type, actor\_type, actor\_name, method\_type, token\_last4, remote\_address, changed\_fields, references\_changed |

***

## Things worth knowing

**People are joined by PagerDuty user id.** Schedules, escalation policies, team members and on-call entries name people by PagerDuty's user id and name, not email. Join on `pagerduty_users.user_id` to get the email.

**Escalation targets are a person or a schedule.** `target_type = 'user'` pages that person directly; `target_type = 'schedule'` pages whoever the schedule says is on call. The people in each rotation are in `pagerduty_schedule_users`.

**"Reachable" means a phone, SMS or push method and at least one notification rule.** A user with only an email address still gets assigned incidents, but nobody's phone rings.

**Outbound endpoints are stored as hosts.** Extensions, webhook subscriptions and workflow connections keep only the host they send to, never the full URL, which can contain a token.

**Audit Trail is incremental.** The first run reads up to 12 months back (PagerDuty keeps audit records for 12 months). Each later run reads from the newest stored record, in windows of 30 days. Records are never deleted from the table. Only the names of changed fields are kept, not their old and new values.

**Large accounts.** PagerDuty's list endpoints stop after 10,000 rows. If a list is cut there, the run summary says TRUNCATED and names it.

**Rate limits.** An account API key may make 960 requests a minute. ConfigView uses at most a quarter of that, and waits for the reset whenever PagerDuty says the limit is nearly used up.

## What isn't collected

* Phone numbers, email addresses and device names of contact methods. Only how many of each kind
* Calendar feed URLs (they contain a token)
* Integration keys and inbound integration email addresses, which let anyone open incidents
* Extension configuration, webhook signing secrets and custom header values
* Full outbound URLs. Only the host
* Old and new values of changes in the Audit Trail
* Incidents, alerts, notes, status updates and postmortems


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.