Webhooks allow you to receive HTTP callbacks when incidents are triggered and updated. Details about the event are sent to a URL you specify, such as Slack, HipChat, or your own custom PagerDuty webhook processor.

Add a Webhook

1. Go to Configuration → Services, then click the name of the service you want to add a webhook to.
2. Go to the service's Integrations tab.
3. Click Add an extension.
4. For the Extension Type select your webhook type or Generic Webhook.
5. Enter an Extension Name.
6. Enter your endpoint's URL.
7. Click Save.

To test your webhook, click New Incident on the service and trigger a test incident. Then check your endpoint for updates. RequestBin is a good tool to review the webhook PagerDuty sends when an incident triggers.

HTTP Authentication and Web Server Access

Webhooks can be sent to any publicly accessible web server, on any port, with or without encryption. They can include a username and password for HTTP basic authentication.

Specify a username and password

If your web server uses HTTP basic authentication, you can add the username and password to the URL before the host address. Special characters such as @ in the password should be percent-encoded.

Example: http://username:password@app.acmemonitoring.com/pagerduty.php

Webhook Ports

If you specify http:// in your Endpoint URL, we will initiate a standard HTTP connection on port 80. Likewise, entering https:// means we will attempt to make a secure connection on port 443. To override the default port, add a colon (:) after the host address with the desired port number.

Example: https://app.acmemonitoring.com:8443/pagerduty.php

Restrict access to just PagerDuty IPs

You can view our list of IPs to whitelist here.

Can I use a self-signed certificate for webhooks?

Yes. Web servers presenting self-signed or expired certificates will receive webhooks.

Temporary Blocks and Blacklisting

When a site goes down, it is expected that events can't be received to your webhook, or that it will become completely disabled.

When events are sent to your webhook endpoints, PagerDuty expects a 200 response within 5 seconds. If there is no response, or if there is any response other than a 200, PagerDuty will periodically retry sending the webhook.

If we receive a 500 response, it is considered a transient issue and retry logic is applied. First the event is rescheduled for delivery 50 seconds in the future. If it continues to 500, PagerDuty will back off by a multiple of 1.25^N for 7 more tries (8 retries total). This takes about 20 minutes.

After these retries are exhausted, the endpoint will be disabled for 30 minutes. PagerDuty will continue to accumulate events for the endpoint while it is disabled. Events will be scheduled for after the disable has expired. If the retries continue to fail, the endpoint will be disabled for exponentially longer periods of time (again, 1.25^N), up to 6 retries total (about 7.5 hours).

If PagerDuty still can't deliver a webhook event at that point, it will blacklist the endpoint and show that the webhook is disabled in the web app. Queued events will be discarded until a user manually unblocks it in the web UI.