When a Case is synced with PagerDuty, PagerDuty actions appear in the Case Activity timeline alongside Slack and ServiceNow events, so you can follow what happened on the PagerDuty side without leaving the Case.
When a Case was triggered or updated through PagerDuty, a PagerDuty Alert link also appears in the Case header. Select it to open the matching PagerDuty alert in a new tab.
PagerDuty Bi-directional keeps a Coralogix Case and its linked PagerDuty incident in sync in both directions. Acknowledge, resolve, comment on, or add a resolution note to an incident in PagerDuty and the linked Case updates automatically, and the same actions on the Case flow back to the incident. It builds on the existing PagerDuty connector and is opt-in: you turn it on with the Enable bi-directional sync setting on the integration, and the existing one-way service-key connector keeps working unchanged. The integration syncs Cases only and does not change how Coralogix routes alerts to PagerDuty.
Coralogix offers two ways to connect to PagerDuty. Pick the one that matches how your team works.
| PagerDuty Bi-directional | PagerDuty (service key) | |
|---|---|---|
| Credential | PagerDuty API key and user email, stored in a PagerDuty integration | Service integration key, entered directly on the connector |
| Sync direction | Two-way (Cases ↔ PagerDuty) | One-way (Coralogix to PagerDuty) |
| Sends | Cases only | Alerts and Cases |
| Services per connector | Multiple | One |
| Use it for | Keeping Cases and incidents in lockstep across acknowledge, resolve, comments, and resolution notes | Routing alerts or Cases to a single PagerDuty service without return updates |
The service-key connector does not change. Adopting bi-directional sync is a deliberate choice you make when you create a new connector, and existing connectors keep delivering exactly as before.
Setup has three parts: get a PagerDuty API key, create the account-level integration, then create a connector that uses it.
Bi-directional sync needs a PagerDuty REST API key with full (read and write) access, because Coralogix both reads incident updates and writes acknowledgements, resolutions, and notes back to PagerDuty.
Coralogix Cases) and leave read-only access cleared so the key has full access.You also need the email of a PagerDuty user on the account. Coralogix sends it as the actor for the actions it performs in PagerDuty (acknowledge, resolve, add note).
For details, see PagerDuty's API access keys documentation.
An account uses a single account-level PagerDuty integration, which the bi-directional connector reads.
For incident updates to reach Cases, Enable bi-directional sync must be on for the integration. The connector then appears in the connectors list with a Bi-directional badge, alongside any Service key connectors you already have. The connector path stays fixed after you create it. In the presets and connector type picker, the bi-directional connector type appears as PagerDuty Incidents.
To deliver Cases through the connector, add it as a destination in a Notification Center routing rule and select a preset. A default Cases - Basic PagerDuty Account Incidents Preset is available, or create a custom preset, as you do for other connectors.
After a Case opens a PagerDuty incident through a bi-directional connector, Coralogix keeps the two records aligned. Sync covers status, priority, comments, and resolution notes, and it flows in both directions.
After a Case closes, inbound PagerDuty events no longer change its state. Coralogix appends them to the timeline as comments only.
PagerDuty and Cases map as follows.
| PagerDuty incident | Coralogix Case |
|---|---|
| Triggered | Active |
| Acknowledged | Acknowledged |
| Resolved | Resolved |
PagerDuty has no closed state, so closing a Case maps the incident to Resolved.
Each synced Case and incident cross-reference each other. From the Case, select View in PagerDuty to open the incident, and the PagerDuty incident links back to the Case in its details.
Bi-directional sync applies only to Cases that opened a PagerDuty incident through the connector. Each Case links to exactly one incident, and each incident links to exactly one Case. Coralogix ignores updates to PagerDuty incidents that have no linked Case and does not act on incidents created directly in PagerDuty.
notification_deliveries dataset, which you can query in DataPrime to audit delivery and troubleshoot failures.| Symptom | Cause | Resolution |
|---|---|---|
| Connector shows a disconnected banner | Someone revoked the REST API key, or deactivated the token owner. | Open the PagerDuty integration and reconnect it with a valid account-level REST API key. |
| Incident actions do not reach the Case | The connector uses the service-key path, or no incident links to the Case yet. | Confirm the connector uses the Bi-directional path and that the Case opened the incident through it. |
| Case actions do not reach the incident | The integration lost its connection, or the Case already closed. | Reconnect the integration. Closed Cases do not push state changes to PagerDuty. |
| Sync lags during a major incident | PagerDuty is rate limiting the account. | No action needed. Coralogix retries with backoff. Review notification_deliveries for retry detail. |
To create and manage the PagerDuty integration, you need the following.
| Resource | Action | Description |
|---|---|---|
integrations | ReadConfig | View deployed integrations. |
integrations | Manage | Add, remove, or update integrations. |