PagerDuty setup - Configview Support

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.

Sign in to PagerDuty as an Admin or the Account Owner (only they can create account keys)
Open Integrations → Developer Tools → API Access Keys
Click Create New API Key
Description: ConfigView
Tick Read-only API Key, so the key can only make read (GET) calls
Click Create Key and copy the key
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

Back on https://{companyname}.configview.com/admin/integrations/pagerduty, confirm the credentials show as saved
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.

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

​Step 1: Open the PagerDuty page in ConfigView

​Step 2: Check your service region

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

​Step 4: Connect and verify

​Plan requirements

​Data Tables

​Things worth knowing

​What isn’t collected