> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # PagerDuty on Vortex IQ > Monitor PagerDuty performance signals, run automated checks, and prepare approved work through Vortex IQ. Monitor PagerDuty performance signals, run automated checks, and prepare approved work through Vortex IQ. [Connect or manage this source](https://app.vortexiq.ai/workbench/settings/sources) · [How connecting works](/integrations/connector-catalogue) · [Create a workflow](https://app.vortexiq.ai/workbench/flows/create?connector=pagerduty) performance signals automated checks automated fixes workflows API operations ### What you can achieve Capabilities are grouped around merchant outcomes, not API terminology. Monitor orders, fulfilment, delivery and settlement. Keep tracking, access and change under governed control. Find failures, leaks and risks before they cost sales. Find storefront, speed, accessibility and journey problems. ### From connection to verified outcome The controlled sequence every capability follows. Nothing changes a connected system without the approval step. Authorise the source. Scopes are shown before access is granted. Watch the signals against your own baselines, not universal defaults. Run checks and gather evidence specific to your store. Explain what happened, why it matters and the proposed action. You review scope, risk and reversibility before anything changes. Apply through governed connector operations. Confirm the intended result and keep the receipt. No changes are made without the configured approval policy. Read-only operations do not modify the connected system; schedules, access scopes, API usage and data handling remain governed by Vortex IQ controls. ### Monitor performance 21 performance signals. Open an outcome to see its signals and how each one alerts. Read-only operations do not modify the connected system. | Signal | Alert behaviour | What it tracks | | ---------------------------------------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------- | | **Active Incidents** | Alert band 0 / 1 | Open triggered/acknowledged incidents right now. Sev1/sev2 = someone should be paged and moving. | | **Inactive Webhook Subscriptions** | Alert band 0 / 1 | Subscriptions toggled off - state changes stop flowing back with no error, the quietest failure mode. | | **Mean Time to Acknowledge** | Alert band 300 / 900 | Median alert-generation → acknowledgement. The headline on-call responsiveness number. | | **Median Submission Latency** | Alert band 1000 / 5000 | Time from alert generation to PagerDuty acceptance. Latency here delays the page. | | **On-Call Schedule Gaps (next 24h)** | Alert band 0 / 1 | Uncovered windows in the on-call schedule - a page during the gap escalates to nobody. | | **Retried Submissions (429/5xx)** | Merchant rule | Events that needed exponential-backoff retry. A spike means PagerDuty-side throttling or an outage. | | **Routing Key Health** | Alert band 100 / 95 | % of services with an active, mapped routing key. Any revoked/rotated/unmapped key = a page that goes nowhere. | | **Sev1 Policies Without Always-On Rota** | Merchant rule | Sev1-mapped escalation policies that lack a 24/7 rota or any escalation step - looks wired, isn't. | | **Severity Tiers Without a Service** | Merchant rule | A Vortex IQ severity tier (sev1/sev2/sev3) with no PagerDuty service mapped - those alerts have nowhere to route. | | **Submission Success by Service** | Merchant rule | Per-service acceptance rate - isolates which routing key / service is dropping events. | | **Webhook Back-Sync Lag** | Alert band 30 / 300 | Time between a PagerDuty state change (ack/escalate/resolve) and Vortex IQ ingest. Lag = a stale incident timeline. | | Signal | Alert behaviour | What it tracks | | ------------------------------ | ----------------------- | ----------------------------------------------------------------------------------------------------------- | | **Escalation Rate** | Alert band 10 / 30 | % of incidents that escalated past the first responder. Rising = first-line is overloaded or under-staffed. | | **Incident Volume by Service** | Merchant rule | Which services page most - the noisiest surfaces to tune or invest in. | | **MTTA by Severity** | Merchant rule | Acknowledgement speed split sev1/sev2/sev3 - sev1 must be fastest. | | **Mean Time to Resolve** | Alert band 3600 / 14400 | Trigger → resolved, the incident lifecycle length. Trending up means incidents are getting stickier. | | Signal | Alert behaviour | What it tracks | | ---------------------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------ | | **Event Submission Success Rate** | Alert band 99.9 / 99 | Events accepted by the Events API v2 / total submitted. Below 99% = pages are being dropped. | | **Fail-Open Audit-Logged Events** | Merchant rule | Events the API could not accept that fell back to the audit log - investigate each, none should be silently lost. | | **Revoked / Rotated Routing Keys** | Merchant rule | Services whose Events API v2 key is revoked or rotated - Vortex IQ pages here silently fail. Highest-leverage fix. | | Signal | Alert behaviour | What it tracks | | ----------------------------------------- | --------------- | ------------------------------------------------------------------------------------------------------------ | | **Revenue at Risk (open sev1 incidents)** | Merchant rule | Live $/min loss while a sev1 incident sits open. Turns 'an incident is on' into 'this is costing $X/min'. | | **Un-Acked Pages During Peak Sales** | Merchant rule | A sev1 page nobody acknowledged while orders were flowing - the worst-case missed-page during revenue hours. | | **Webhook Delivery Failures (24h)** | Merchant rule | Webhook subscriptions with a failed last delivery - back-sync is broken until they recover. | ### Audit risks and opportunities No automated checks are defined for PagerDuty yet. The performance signals cover the monitoring layer, and checks arrive with the connector's audit module. #### Build your own automated fixes Turn any finding into an automated fix with a Vortex IQ workflow: **over 13,000 read and write operations across more than 200 connectors** are available as building blocks, with approval, verification and rollback on every change. ### Automate approved work Vortex IQ is integrated with **7 read** and **2 write** operations across incidents, abilitys, analyticsmetricsincidentalls, enqueues, escalationpolicys, schedules on PagerDuty. Combine them with anything from the **over 13,000 operations across more than 200 connectors** to automate the work in your own words. Changes follow your configured approval policy: the target, proposed change, affected records, risk, reversibility and verification plan are shown before execution. [Create a workflow](https://app.vortexiq.ai/workbench/flows/create?connector=pagerduty) #### Ready to build your first PagerDuty workflow Pick a trigger, add the operations above as steps, and every step that changes data pauses for your approval. Monitoring and audits are live now and can start any workflow you build. | Resource | Read operations | Write operations | | ---------------------------- | --------------- | ---------------- | | incidents | 2 | 0 | | abilitys | 1 | 0 | | analyticsmetricsincidentalls | 0 | 1 | | enqueues | 0 | 1 | | escalationpolicys | 1 | 0 | | schedules | 1 | 0 | | services | 1 | 0 | | webhooksubscriptions | 1 | 0 | Signed-in users see the full catalogue in the workflow builder, filtered to the sources they have connected.