Knowledge Base
API DocsIntegrationsPagerDuty UniversityPagerDuty CommonsContact SupportMy Support Tickets

Event Orchestration Examples

Event Orchestration is a highly customizable suite of features and capabilities. The examples on this page are taken from real-world customer use cases, which you're welcome to replicate in your own PagerDuty account.

If Events Match Certain Conditions

In this example, we will create a routing rule that routes events to a service when matching conditions are met.

  1. Create a routing rule and, under When should events be routed here?, select If events match certain conditions.
  2. Indicate the event conditions that you would like the orchestration to match using one of the following methods:
MethodDescription
Base conditions on incoming JSONDepending on your account's activity, you may have recent events appear on the left side of the screen if events have been sent to the incoming event source. View these events to determine which values to use.
Events sent through the APIYou will use the JSON field names directly (e.g., summary). For nested fields, separate names with a dot (.) (e.g., payload.taskid). If you are sending data through additional fields, enter them exactly as they are sent to PagerDuty. For example, if your events have a tags field, enter that field name in your rule condition as tags.
Events sent through emailNote: The following functionality will only work when you send emails to a global email integration address. It will not work for emails sent directly to a service-level email integration.

Rules may be based on the content of an email by entering the appropriate email field as custom details in the event field.

The most common email fields are:
-event.custom_details.from[0](the from address). *

- event.custom_details.subject (the subject line) **
- event.custom_details.plain_body (the email body)* The [0] refers to the 1st position in a list of emails. If you would like to generally search through a list of emails (either in the to field or the from field), please enter event.custom_details.from or event.custom_details.to.** For email generated events, the field event.summary is populated with the same value as event.custom_details.subject (the email subject) by default. However, these are separate fields and their values may differ based on customer-specified configurations.
Configure routing rule

Configure routing rule

  1. In the middle dropdown, select how the event should be filtered.
Filter OptionsDescription
- matches part

- does not match part		The field contains/does not contain a value.
- matches

- does not match		The field equals/does not equal a value (this operation requires the field to be passed in as a string).
- exists

- does not exist		The field exists/does not exist.
- matches regex

- does not match regex		The field matches/does not match a regular expression. Regular expressions must use RE2 syntax.

📘

Negative Operations

Rules with negative operations, such as does not contain or does not equal, will match events that do not contain your specified value and events that do not contain the field at all. As an example:

  • severity field does not equal critical
    • This will match events where the severity field does not equal critical and events that do not contain a severity field at all.

If you'd like to avoid this, you must add an additional condition that matches only when the field exists. For example:

When all conditions are true:

  • severity field exists
  • severity field does not equal critical

Note: You must select all conditions must be true for the rule to match.

  1. In the second value field, input the value that should be met from the payload. This can be a string or regular expression.

📘

Case Sensitivity

Condition values in Event Orchestrations are case-insensitive.

For example, if a condition is set with Summary matches part DOWN, this will match if the Summary contains Down, down and other variations of the word.

  1. When additional conditions should be added, use the following options:
  • + And: Additional conditions should be met.
  • + New Condition: Create another set of conditions that should be met. A new condition block creates an OR operator of conditions that will also be evaluated alongside other blocks.
  1. Click Save to save your configuration.

📘

Condition Limits

You can create up to 25 condition blocks within a rule, and you can have up to 64 operators (i.e., AND, OR), or a maximum of 2048 bytes (e.g., if you're using PCL) in a single condition block.

On a Recurring Weekly Schedule

📘

Availability

Scheduled conditions are available with Advanced Event Orchestration.

In this example, we will create a routing rule that routes events to a service on a weekly recurring schedule.

  1. Create a routing rule and, under When should events be routed here?, select On a recurring weekly schedule.
  2. Enter appropriate times for Start and End, select your preferred Days of the week, and pick your Timezone.
  3. Click Save.

Advanced Configuration with the and Operator

📘

Availability

Scheduled and threshold conditions are available with Advanced Event Orchestration.

This example details how to edit PCL to create an advanced condition that the UI does not natively allow for.

If you select one of the following options for When should events be routed here?, the UI does not offer a way to set an and condition:

  • On a recurring weekly schedule
  • During a scheduled date range
  • Depends on event frequency

You can work around this, however, by directly editing the PagerDuty Condition Language (PCL).

Say you'd like to route events to a service when the following conditions are met:

  • The event's source matches mainframe.
  • It is Wednesday or Sunday between 11:00 a.m. and 12:00 p.m. Eastern.

The following PCL statement will meet these conditions: event.source matches 'mainframe' and now in Wed,Sun 11:00:00 to 12:00:00 America/New_York.

Updated 3 months ago

Learn more