Summary
Alert Webhooks operate via a subscription model. The API consumer, known as a subscriber, has to register a destination URI with the API Publisher. The API Publisher posts the data to the destination URI as the data becomes available.
In Catchpoint, you subscribe to the API by specifying a destination URL in the Catchpoint interface. The API subscription applies for the entire client or division. Catchpoint will push alert data to the subscriber via a HTTP Post request, the moment the alert triggers based on the settings.
Catchpoint Alerts are pushed from the Las Vegas datacenter: 64.147.163.0/24
The system used to push alerts only allows standard http ports such as 443, 80, and 8080.
Configuration
You configure the API subscriber information under Integrations in the nav menu. To enable the API you must specify the URL of the subscriber and the format you wish to receive the data in. To post any alerts that trigger to the subscriber URL provided, check on the setting Apply to All Alerts.
Format
The subscriber can receive the data in two formats: JSON and XML. The data provided in the post is the same as the data provided in the email notification.
Templates
For information regarding Alert Push API Templates, see the KB article here.
Assign API Endpoints
Alert Webhook Endpoints can be assigned to specific alerts at the Product, Folder, Test and RUM levels. In the Alerts settings, click on the API Endpoints drop down menu to choose the endpoints you want to post alerts to.
Monitor and Test Type Values
The monitor and test types values tells Catchpoint how to monitor a test. For a full list of values supported by the Catchpoint API, see the article here.
Alert Type and Subtype Values
Alert types are high-level groups of alerts, while alert subtypes are lower-level types, that belong to an Alert Type. For example, Insight alert type has two subtypes: Tracepoints and Indicators.
List of Alert Types and Subtypes with Respective IDs
| Type ID | Type Name | Subtype ID | Subtype ID |
| 0 | None | 0 | None |
| 0 | None | 40 | Unknown |
| 2 | Byte Length | 1 | Test URL |
| 2 | Byte Length | 2 | Page |
| 3 | Content Match | 10 | Regular Expression |
| 3 | Content Match | 11 | Compare to Previous |
| 3 | Content Match | 12 | Compare to File |
| 4 | Host Failure | ||
| 7 | Timing | 50 | DNS |
| 7 | Timing | 51 | Connect |
| 7 | Timing | 52 | Send |
| 7 | Timing | 53 | Wait |
| 7 | Timing | 54 | Load |
| 7 | Timing | 55 | TTFB |
| 7 | Timing | 57 | Content Load |
| 7 | Timing | 58 | Response |
| 7 | Timing | 59 | Page Response |
| 7 | Timing | 61 | DOM Load |
| 7 | Timing | 62 | Perceived Page Load |
| 7 | Timing | 63 | Page Response w/ Suspect |
| 7 | Timing | 64 | Server Response |
| 9 | Test Failure | ||
| 10 | Insight | 90 | Tracepoints |
| 10 | Insight | 91 | Indicators |
| 11 | JS Failure | ||
| 12 | Ping | 100 | Ping RTT |
| 12 | Ping | 101 | Ping Packet Loss |
| 13 | Requests | 110 | # Requests |
| 13 | Requests | 111 | # Hosts |
| 13 | Requests | 112 | # Connections |
| 13 | Requests | 113 | # Redirects |
| 13 | Requests | 114 | # Other |
| 13 | Requests | 115 | # Images |
| 13 | Requests | 116 | # Scripts |
| 13 | Requests | 117 | # HTML |
| 13 | Requests | 118 | # CSS |
| 13 | Requests | 119 | # XML |
| 13 | Requests | 120 | # Flash |
| 13 | Requests | 121 | # Media |
| 14 | Zone | 130 | Page Response |
| 14 | Zone | 131 | Bottleneck Time |
| 14 | Zone | 132 | % Bottleneck |
| 14 | Zone | 133 | # Requests |
| 14 | Zone | 134 | # Failures |
| 15 | Availability | 140 | Test |
| 15 | Availability | 141 | Content |
| 16 | Address | 150 | Test URL |
| 16 | Address | 151 | Child URLs |
| 16 | Address | 152 | Any URLs (Test or Child) |
Notification Level ID
Catchpoint supports three levels of notification which determine the importance of an alert.
| Level | ID |
| Warning | 0 |
| Critical | 1 |
| (System Internal) | 2 |
| Improved | 3 |
Note: By default we allow only three alert webhooks endpoints to be created per division/client. However, this limit may be increased per your organization's needs. If you wish to increase this limit, please reach out to your CSM with this request.
Notification Logic
Alerts can be sent to specific email addresses if our system is unable to send the Alert Webhook data. These can be configured under Integrations. Under each endpoint there is the ability to enter the email addresses the alerts need to be sent to, and also at which point it should be sent by choosing a Notification Trigger.
If a payload is unable to go through, all new notifications for that same alert on the same webhook will be blocked until a retry either succeeds or times out.
For example: If an alert goes through on a webhook, but the improvement notification fails to go through, further alerts will not be sent until the improvement notification retry either succeeds or times out.
A failed payload will continue to retry for up to one hour before timing out. An email will be sent after the third retry failure, which will generally be around 7-15 minutes after the initial failed attempt.
For more information on Alert Webhook failure notifications and how they work, see this article here.