Back to source list
Official
Premium
PagerDuty
The CloudQuery PagerDuty plugin extracts PagerDuty data and loads it into any supported CloudQuery destination
Loading plugin documentation
The CloudQuery PagerDuty plugin extracts PagerDuty data and loads it into any supported CloudQuery destination
Loading plugin documentation
We use tracking cookies to understand how you use the product and help us improve it. Please accept cookies to help us improve. You can always opt out later via the link in the footer.
auth_token spec field~/.pd.yml file, such as:authtoken: <YOUR_AUTH_TOKEN>
PAGERDUTY_AUTH_TOKEN.pagerduty_incident_notes, pagerduty_incident_alerts) require the most API calls, because
they require an API call per resource (e.g. incident). You may be able to speed up the sync by skipping these relational
tables:skip_tables: [
"pagerduty_incident_alerts",
"pagerduty_incident_notes",
"pagerduty_incident_log_entries",
"pagerduty_ruleset_rules",
"pagerduty_user_contact_methods",
"pagerduty_user_notification_rules"
]
team_ids: ["<team_id>"]
backend_options field from your spec.backend_options must be set in the spec (as shown below). This is documented in the Managing Incremental Tables section. SELECT pagerduty_services.id AS service_id,
pagerduty_services.name AS service_name,
COUNT(pagerduty_incidents.id) AS incident_count
FROM pagerduty_services
INNER JOIN pagerduty_incidents
ON pagerduty_services.id = pagerduty_incidents.service->>'id'
WHERE pagerduty_incidents.created_at > NOW() - INTERVAL '3 months'
GROUP BY service_id, service_name
ORDER BY incident_count DESC
LIMIT 10
service_id | service_name | incident_count
------------+-----------------+----------------
PYS6MP5 | UnstableService | 25
PAZ9U1C | StableService | 3
WITH incident_ack_logs AS (
SELECT pagerduty_incidents.id AS incident_id,
pagerduty_incidents.priority->>'name' AS priority,
pagerduty_incident_log_entries.created_at - pagerduty_incidents.created_at AS time_to_log
FROM pagerduty_incidents
INNER JOIN pagerduty_incident_log_entries
ON pagerduty_incidents.id = pagerduty_incident_log_entries.incident->>'id'
WHERE pagerduty_incident_log_entries.type = 'acknowledge_log_entry'
AND pagerduty_incidents.created_at > NOW() - INTERVAL '3 months'
),
incident_ack_time AS ( -- Make sure only the first acknowledgement is used (incidents may be acknowledged twice)
SELECT incident_id,
priority,
MIN(time_to_log) AS time_to_ack
FROM incident_ack_logs
GROUP BY incident_id, priority
)
SELECT priority, AVG(time_to_ack) AS average_time_to_ack
FROM incident_ack_time
GROUP BY priority
priority | average_time_to_ack
----------+---------------------
P1 | 00:05:10
P2 | 00:30:00
P3 | 06:20:00
WITH incident_ack_logs AS (
SELECT pagerduty_incidents.id AS incident_id,
pagerduty_incident_log_entries.agent->>'id' AS agent_id
FROM pagerduty_incidents
INNER JOIN pagerduty_incident_log_entries
ON pagerduty_incidents.id = pagerduty_incident_log_entries.incident->>'id'
WHERE pagerduty_incident_log_entries.type = 'acknowledge_log_entry'
AND pagerduty_incidents.created_at > NOW() - INTERVAL '3 months'
)
SELECT pagerduty_users.id AS user_id,
pagerduty_users.name AS user_name,
COUNT(DISTINCT incident_id) AS acknowledge_count FROM
pagerduty_users INNER JOIN incident_ack_logs
ON pagerduty_users.id = incident_ack_logs.agent_id
GROUP BY user_id, user_name
ORDER BY acknowledge_count DESC
user_id | user_name | acknowledge_count
---------+-------------+-------------------
PDYR2Y8 | John | 15
PDYR2Y9 | Dave | 12
PDYR2Z5 | Jane | 8
pagerduty.yml).kind: source
spec:
# Source spec section
name: "pagerduty"
path: "cloudquery/pagerduty"
registry: "cloudquery"
version: "v6.8.0"
tables: ["*"]
destinations: ["postgresql"]
backend_options:
table_name: "cq_state_pagerduty"
connection: "@@plugins.postgresql.connection"
# Learn more about the configuration options at https://cql.ink/pagerduty_source
spec:
# optional
auth_token: "<auth_token>"
# optional
team_ids: ["<team_id>"]
auth_token (string) (optional)auth_method (string) (optional, default: api_token)api_token and oauth_token.team_ids ([]string) (default: empty. will sync data from all available teams)max_requests_per_second (integer) (default: 10)
PagerDuty API is heavily rate-limited (900 requests/min = 15 requests/sec, across the entire organization).
This option allows you to control the rate at which the plugin will make requests to the API.
You can reduce this parameter in case you are still seeing rate limit errors (status code 429), or increase
it if your PagerDuty API quota is higher. See https://developer.pagerduty.com/docs/ZG9jOjExMDI5NTUz-rate-limiting#what-are-our-limits for more info.
Set to a negative number (e.g. -1) to disable rate limiting, but be aware that this may cause rate limit errors.retry_max (integer) (optional) (default: 10)
Maximum number of retries to make for each request when a transient error occurs (e.g. rate limit error).
Set to a value equal to or less than 0 to disable retries.retry_wait_min_seconds (integer) (optional) (default: 1)
Minimum number of seconds to wait before retrying a request when a transient error occurs (e.g. rate limit error).retry_wait_max_seconds (integer) (optional) (default: 30)
Maximum number of seconds to wait before retrying a request when a transient error occurs (e.g. rate limit error).concurrency (integer) (optional) (default: 1000)
A best effort maximum number of Go routines to use. Lower this number to reduce memory usage.scheduler (string) (optional) (default: dfs)
The scheduler to use when determining the priority of resources to sync.
Supported values are dfs (depth-first search), round-robin, shuffle and shuffle-queue.table_options (Table Options spec) (optional)pagerduty_incidentssince and until defaults to empty strings, which results in syncing all incidents by default.since (configtype.Time) (optional)
See the configtype.Time section below for more details.
Defaults to an empty string which is interpreted as beginning of time.until (configtype.Time) (optional)
See the configtype.Time section below for more details.
Defaults to an empty string which is interpreted as current time.pagerduty_schedulesfinal_schedule or override_subschedule schedule data either since or until must be provided.Specifyingsinceoruntilwill incur an addition API call to get each schedule is required. This can slow down the sync process.
since (configtype.Time) (optional)
See the configtype.Time section below for more details.
Defaults to 2 weeks before until if an until is given.until (configtype.Time) (optional)
See the configtype.Time section below for more details.
Defaults to 2 weeks after since if a since is given.pagerduty_oncallssince and until defaults to empty strings, which are interpreted as current time by the PagerDuty API.
As a result this table syncs ongoing on-calls by default. Use since and until to expand the range of on-calls to sync.since (configtype.Time) (optional)
See the configtype.Time section below for more details.
Defaults to an empty string which is interpreted as current time.until (configtype.Time) (optional)
See the configtype.Time section below for more details.
Defaults to an empty string which is interpreted as current time.configtype.Time type allows for defining timestamps in both absolute and relative formats.2024-01-01T12:00:00+00:00.nowx seconds [ago|from now]x minutes [ago|from now]x hours [ago|from now]x days [ago|from now]until field:until: nowuntil: 2 days agountil: 10 months 3 days 4h20m from nowuntil: 2024-01-01T12:00:00+00:00