PagerDuty

PagerDuty is an incident management platform that routes alerts to the right on-call responders, tracks every incident from trigger to resolution, and manages the services, schedules and escalation policies behind your operations. With Weld you can sync your PagerDuty data into your data warehouse and report on incident volume, response and resolution times, on-call load per team and user, and the services that generate the most alerts.

Features

Feature nameSupported
Column HashingTrueColumn level
BlockingTrueColumn level
IncrementalTrue
Custom dataFalse
HistoryTrue
ReSyncTrueTable level
TemplatesFalse

Data Schema

Setup Guide - ELT

Prerequisites

You need a PagerDuty REST API key. We recommend a read-only account-level API key created by a PagerDuty admin or account owner — the incident and service analytics tables are only returned to an account-level key, and audit records require either an account-level key or the user key of an admin or account owner. Weld only reads from PagerDuty — it never writes back.

Step 1 - Create your PagerDuty API key

  1. Sign in to PagerDuty as an admin or account owner.
  2. Go to Integrations → API Access Keys.
  3. Click Create New API Key, give it a description such as "Weld", and tick Read-only.
  4. Copy the key — PagerDuty only shows it once.

A personal user API token (created under My Profile → User Settings) also works, but it only sees what that user can see. The slack_dedicated_channel table is the one exception: PagerDuty only returns it to a user token of an Owner or Global Admin, not to an account-level key.

Step 2 - Create the connection

  1. In the Weld app, navigate to Connections and click + New Connection.
  2. Search for PagerDuty and select it.
  3. Enter the destination schema name of your choice. This name is used to identify the connection in future syncs.
  4. Paste your API Key.
  5. Click Connect to validate the key and establish the connection.

Step 3 - Data To Sync

Select the tables you wish to include in the sync. You can view the schema, remove columns or hash sensitive information.

The connector exposes 34 tables, grouped by area. Where a table has child tables, they are synced along with it and listed in parentheses.

  • Incidents — incident (with incident_assignment, incident_acknowledgement, incident_team, incident_pending_action, incident_responder, incident_responder_escalation_policy_request, incident_responder_request, incident_responder_request_target), incident_note, incident_custom_field_value (with incident_custom_field_value_item), log_entry (with log_entry_team, log_entry_assignee), notification, change_event (with change_event_service, change_event_link, change_event_custom_detail), slack_dedicated_channel, paused_incident_reporting_alert (with paused_incident_triggered_after_pause_alert, paused_incident_resolved_after_pause_alert)
  • Analytics — raw_incident (with raw_incident_assigned_user_id, raw_incident_assigned_user_name, raw_incident_acknowledged_user_id, raw_incident_acknowledged_user_name, raw_incident_joined_user_id, raw_incident_joined_user_name), analytics_metric_service_daily
  • Services and automation — service (with service_team, service_integration, service_days_of_week, service_scheduled_action), business_service, business_service_subscriber, event_orchestration, ruleset, incident_workflow (with incident_workflow_team, incident_workflow_step, incident_workflow_action, action_input, action_output), maintenance_window (with maintenance_window_service, maintenance_window_team), template
  • On-call — escalation_policy (with escalation_policy_rule, escalation_policy_target, escalation_policy_service, escalation_policy_team), schedule (with schedule_users, schedule_escalation_policy, schedule_team), on_call
  • Users and teams — user (with user_contact_method, user_notification_rule, user_team), team, user_handoff_notification_rule, user_notification_subscription, user_delegation, license (with license_valid_role)
  • Integrations and extensions — addon, extension (with extension_object), extension_schema (with extension_schema_send_type), vendor
  • Tags and audit — tags, tag_entity, audit_log (with audit_log_actor, audit_log_field, audit_log_reference, audit_log_reference_added, audit_log_reference_removed)

Some tables depend on your PagerDuty plan

PagerDuty only returns certain data on specific plans or add-ons. If your account does not have the feature, leave the table out of the sync, otherwise the sync fails with a permissions error:

  • raw_incident and analytics_metric_service_daily need Analytics, and are only returned to an account-level API key.
  • audit_log needs the Audit Trail feature, and an account-level key or the key of an admin or account owner.
  • paused_incident_reporting_alert needs Event Intelligence or the Digital Operations plan.
  • template needs templates to be included in your plan.

Step 4 - Configure sync

  1. Select how often you would like the data to sync.
  2. Choose a start date for the incident, log entry, notification, change event, audit and analytics tables. If you leave it empty, Weld syncs the last year of data. Reference data such as users, teams, services and schedules is always synced in full.
  3. Provide a unique destination table name.

Weld will take over from here and commence syncing data from your PagerDuty account.

Was this page helpful?