Skip to main content

Hi,

As part of a service orchestration rule or another type of rule, is it possible to check for the existence of an active incident within another PagerDuty service as a pre-processing step to paging us out

Basically we have 2 PagerDuty services, App A and App B. When we get an incident in for App A, we’d like to check to see if there’s an active incident for App B that was created around the same time. If there is an active incident, then the escalation policy/notification policy gets enacted and people are paged out. Is something like that possible, assuming we have access to both of the PagerDuty services?

Hi ​@sheel331,

Event Orchestration can’t directly “look up” whether Service B has an active incident when Service A fires. You’ll need to bring that signal into the rule. Here are two scenarios: 

First Example:

  1. On Service A’s Orchestration, add a rule that calls a Webhook Action to your decisioning endpoint.
  2.  Your endpoint queries the PagerDuty Incidents API to see if Service B currently has any open incidents in a recent window (e.g., last 10 minutes).
  3. Your endpoint returns a decision (e.g., “page” vs “suppress” or a field your rule can branch on). Based on the webhook response, you set actions in the Orchestration (route, priority, suppress, etc.).

Second Example:

  1. Use Service Orchestration Cache Variables to store a “flag” that App B is currently in incident. When App B triggers an incident, an Incident Workflow (on App B) sets this flag (and optionally a TTL). When the incident resolves, the workflow clears it. Set a Cache Variable Value.
  2. Service A’s Orchestration reads the cache variable: if true, page; if false, suppress or route differently.

Come back here after testing to tell us if it worked! 

Terms & ConditionsCookie settingsAccessibility statement