Outgoing Webhooks

Outgoing Webhooks are requests made by PagerTree to a user-defined URL, the payload provided represents an alert. Webhooks allow you to extend PagerTree by performing any logic you wish.

Create An Outgoing Webhook

From the action button, click the “Create Integration” button.
Supply the following information
- Name - A descriptive name
- Type - The integration type Outgoing Webhook
Click Create button.
On the left hand side in the options section configure the following:
- URL - The endpoint URL PagerTree will make requests to
- Username (optional) - Used for Basic Authentication
- Password (optional) - Used for Basic Authentication
- Enable/Disable desired event types

Data Structure

Outgoing webhooks will send data in a POST request in JSON format to your configured URL. Each request has the following format:

Where event_type is an applicable event and data is an alert

Example Payload

Custom Format

Outgoing webhooks can also send data in a custom format. The request is still a POST request and must be in JSON format.

You can edit the format in the Template (JSON) section of the integration settings. Enable Linked Data

Templates support Handlebars substitution with the event and alert objects. You can use any handlebars-helpers to support any logic. Use JSON dot notation selection to access deeply nested data (ex: alert.d_user.name).

The data you have access to are the following properties:

hint	Use the triple-stash {{{ }}} operator to bypass URL encoding.

Popular Templates

Plain JSON (using triple-stash operator)
Slack (Incoming Webhook)
Referenced objects

Troubleshooting Templates

If for any reason you do not receive the webhook with a custom template, it is likely you have a formatting error. On the integration page, look at the integration’s logs.

If you do not see a log, ensure the integration is enabled
If you do see a log, view the log by clicking the log link. An error should be provided in the status field in the content section on the right hand side.

Linked Data

Linked data is a convenience option that embeds referenced objects. Linked data will send the following extra attributes.

Extra Attribute	Referenced By
d_team	d_team_id
d_user	d_user_id
source	source_id
s_log	s_log_id

If you are using a custom template you can access the linked data like so: {{alert.d_user.name}}.

To enable sending of linked data:

Enable the Linked Data switch

Applicable Events

Currently PagerTree support 7 events:

alert.created - fired exactly once, when the alert is created in the database
alert.acknowledged - fired 0-1 times, when the alert is acknowledged
alert.rejected - can be fired 0-N times, when the alert is rejected by a user.
alert.timeout - can be fired 0-M times, when an alert layer times out and moves to the next escalation layer
alert.resolved - fired 0-1 times, when the alert is resolved
alert.dropped - fired 0-1 times, when the alert is dropped
alert.handoff - fired 0-N times, when the alert is handed off

Rules

You can suppress outgoing webhooks or modify the payload using rules. This feature uses the same engine as the routers and is also expressed in YAML. You can use all the same operators as routers for matching conditions, but you can only use the setval and ignore actions. The root element should always be rules (an array), with each rule having a match (hash) and actions (array).

Rules Data

When routers are matching rules they are given access to data. Namely you are given access to the alert, integration, and event in context, and a special field always which is always true (especially useful for catch all rules).

Rules Examples

In our most basic example, we suppress any event that is not “critical”.

In the next example, we are working with the Slack (Post to Channel) integration and we switch the channel PagerTree sends the notification to.

Special Values

There is a special value webhook_url that if set using the setval operator will change the URL that the webhook is sent to. You can use this to dynamically change where wehooks are sent to.

Successful Responses And Limitations

PagerTree considers any response in the 2xx family a successful response. If your endpoint sends any other response PagerTree will consider it a failure. If your endpoint consistently fails for more that 3 consecutive days, PagerTree will automatically disable your outgoing webhook integration.

Your endpoint is expected to respond within 5 seconds. If you endpoint does not respond within the timeout period it will be considered a failure.

The outgoing webhook integration will not follow redirects.