Skip to content


The PagerDuty modules enable you to monitor, retrieve, or update incidents, and create events in your PagerDuty account.


If you are coming from looking for assistance with this integration, please submit a support ticket at www.Ibexa

Getting Started with PagerDuty


  • A PagerDuty account

In order to use PagerDuty with Ibexa Connect, it is necessary to have a PagerDuty account. If you do not have one, you can create a PagerDuty account at


The module dialog fields that are displayed in bold (in the Ibexa Connect scenario, not in this documentation article) are mandatory.

Connecting PagerDuty to Ibexa Connect

To connect your PagerDuty account to Ibexa Connect, follow the general instructions for Connecting to services.

After you click the Continue button, Ibexa Connect will redirect you to the PagerDuty website. After logging in, you will be prompted to grant Ibexa Connect access to your account.


Confirm the dialog by clicking the Authorize button.


Get an Incident

Retrieves incident details.

Incident Enter (map) or select the incident you want to retrieve details about.

Create an Event

Sends an event. Sent events are routed to a PagerDuty service and processed. Sent events may result in a new alert and/or incident being created, or an existing alert or incident being updated or resolved.

Routing key

Enter the 32-character Integration Key for integration on a service or a global ruleset.

Event Action

Select the type of event.


When PagerDuty receives a Trigger event, it will either open a new alert or add a new trigger log entry to an existing alert, depending on the provided Dedup key(below).Your monitoring tools should send PagerDuty a trigger when a new problem has been detected. You may send additional triggers when a previously detected problem reoccurs.


Acknowledge events cause the referenced incident to enter the acknowledged state.While an incident is acknowledged, it won't generate any additional notifications, even if it receives new trigger events.Your monitoring tools should send PagerDuty an Acknowledge event when they know someone is presently working on the problem.


Resolve events cause the referenced incident to enter the resolved state.Once an incident is resolved, it won't generate any additional notifications. New trigger events with the same Incident key as a resolved incident won't re-open the incident. Instead, a new incident will be created.Your monitoring tools should send PagerDuty a Resolve event when the problem that caused the initial trigger event has been fixed.


Enter a brief text summary of the event. This is used to generate the summaries/titles of any associated alerts.The maximum permitted length of this property is 1024 characters.


Select the perceived severity of the status the event is describing with respect to the affected system.

Source action

Enter the unique location of the affected system, preferably a hostname or FQDN.


Enter the time and date when the emitting tool detected or generated the event. Please see the list of supported date and time formats.


Specify the component of the source machine that is responsible for the event, for example mysql, postgre, or eth0.


Enter the logical grouping of components of a service, for example app-stack, prod-datapipe, etc.


The class/type of the event, for example ping failure,latency , or cpu load.

Dedup Key

Enter a deduplication key for correlating triggers and resolves. The maximum permitted length of this property is 255 characters.

Every event has a Dedup key: A string that identifies the alert triggered for the given event. The Dedup key can be specified when submitting the first trigger event that creates an alert. If omitted, it will be generated automatically by PagerDuty and returned in the Events API v2 response.

Submitting subsequent events for the same Dedup key will result in those events being applied to an open alert matching that Dedup key. Once the alert is resolved, any further events with the same Dedup key will create a new alert (for trigger events) or they will be dropped (for acknowledge and resolve events).

Subsequent events for the same Dedup key will only apply to the open alert if the events are sent via the same routing_key as the original trigger event. Subsequent acknowledge or resolve events sent via a different routing_key from the original will be dropped.

If a trigger event is sent without Dedup key, it will always generate a new alert because the key is a UUID.

Alerts can be further grouped into Incidents, for centralizing incident response and context. For more information on the way events, alerts, and incidents interact, please see this knowledge base article.


Enter the name of the monitoring client that is triggering this event, e.g., Sample Monitoring Service.

Client URL

Enter the URL of the monitoring client that is triggering this event, e.g.,

List of images to include

Add images that will be attached to the incident.

Image source

Enter the URL of the image being attached to the incident. This image must be served via HTTPS.

Optional URL

Enter the URL that makes the image a clickable link.

Image name

Enter the alternative text for the image.

List of links to include

Add text links that will be attached to the incident.

Link URL

Enter the URL of the link to be attached to an incident or alert.

Link text

Enter the text that describes the purpose of the link, and which can be used as the link's text.

Update an Incident

Allows you to acknowledge, resolve, or escalate an incident.

Incident to update Select the incident or map the ID of the incident you want to update.
Event action name Select the type of incident.
Status Select the new status of the incident.
Incident title Enter the new title of the incident.
Escalation level Enter the number of the escalation level to escalate the incident to this level in the escalation policy.
Urgency Enter the urgency of the incident, e.g., High.

Watch Incidents

Triggers when a new incident is created or when an existing incident's status is updated.

The webhook URL needs to be generated in Ibexa Connect and then added to PagerDuty service's integration as an extension.

  1. Add Watch Incidents module to your Ibexa Connect scenario.

  2. Generate and copy the webhook URL.


  3. Log in to your PagerDuty account.

  4. Navigate to Configuration > Services, then click the name of the service you want to add a webhook to.


  5. Open the Integrations tab, in the Extensions and Add-Ons section, click Add or manage extensions for this service, and then click the New Extension button.

  6. For the Extension Type, select the Generic V2 Webhook option.

  7. Enter the name of your webhook, and enter the URL you have copied in step 2.

  8. Click Save.

Now, every time the incident is created or its status is updated, the Watch Incidents module in your scenario is triggered.


List On-call Users

Retrieves the on-call entries during a given time range for the specified user.


Set the maximum number of on-calls Ibexa Connect will return during one execution cycle.


Enable this option to filter on-calls so that only the earliest on-call for each combination of escalation policy, escalation level, and user is returned. This is useful for determining when the "next" on-calls are for a given set of filters.

Escalation policy IDs

Add escalation policies to filter returned on-calls by.


Specify additional details you want to include in the result.

Schedule IDs

Add schedule IDs to filter returned on-calls by.


Enter the start of the time range over which you want to search. If an on-call period overlaps with the range, it will be included in the result. The start of the time range defaults to the current time. The search range cannot exceed 3 months. Please see the list of supported date and time formats.

Time zone

Specify the time zone in which the dates in the result will be rendered.


By default, the total field in pagination responses is set to null to provide the fastest possible response times. Set total to true for this field to be populated.

See PagerDuty Pagination Docs for more information.


Enter the end of the time range over which you want to search. If an on-call period overlaps with the range, it will be included in the result. Please see the list of supported date and time formats.

User IDs

Add users you want to filter returned on-calls by.

Make an API Call

Allows you to perform a custom API call.


Enter a path relative to For example: /users

For the list of available endpoints, refer to the PagerDuty API Documentation.


Select the HTTP method you want to use:


to retrieve information for an entry.


to create a new entry.


to update/replace an existing entry.


to make a partial entry update.


to delete an entry.


Enter the desired request headers. You don't have to add authorization headers; we've already done this for you.

Query String

Enter the request query string.


Enter the body content for your API call.

Example of Use - List Incidents

The following API call returns all incidents in your PagerDuty account:






The result can be found in the module's Output under Bundle > Body > dashboards.

In our example, 3 incidents were returned: