Custom HTTP Delivery
Custom HTTP Alert Delivery Methods (i.e. Webhooks) allow you to send alert notification data to an external system via HTTP GET or POST requests. Similar to Custom Email Alert Delivery, this can be advantageous if you're sending alert notifications to a ticketing system. Custom HTTP alert delivery enables you to define the precise format of the alert notification data using tokens (variables), so that it can be easily parsed by the recipient system.
Typically custom HTTP delivery methods make an HTTP POST and deliver alert notification data in a request payload. However, in some cases an HTTP GET request is sufficient because the request itself has form data appended to the URL (i.e. https://www.example.com/api?param1=abc&m2=def), and no payload needs to be posted.
Simply defining a custom alert delivery method will not result in notifications being routed via the custom delivery method. The custom delivery method must be included as the contact method for a recipient in an escalation chain, and that escalation chain must be referenced by an alert rule. When configuring these, there a few guidelines to follow to ensure alert data is posted and updated as expected in the target integration. These guidelines are discussed in Alert Integrations Overview.
Keep in mind that you can use our REST API resources to post an ack/SDT back to LogicMonitor.
Custom HTTP Alert Delivery
You can add and/or configure existing custom HTTP alert delivery from Settings | Integrations. Select Add and then Custom HTTP Delivery:
The name of the custom HTTP alert delivery template.
The description for the custom HTTP alert delivery template.
Use the Same URL and data to notify on various alert activity
This option will send HTTP requests for alert acknowledgments, clears, and/or escalations/de-escalations to the same URL that the initial HTTP requests for new alerts were sent.
Use different URL or data format to notify on various alert activity
This option will send HTTP requests to different URLs based on the alert status.
Which alert statuses should trigger an HTTP request?
Select which alert statuses should trigger an HTTP request. Requests will be sent for new alerts, and can additionally be sent for alert acknowledgements, clears and escalations/de-escalations.
- New Alerts - This state is for new, active alerts and is required.
- Acknowledged - This state is intended to process previously generated alerts that are acknowledged.
- Cleared - Once an active alert satisfies the alert threshold that triggered it, this state will control the HTTP request made.
- Escalated/De-escalated - Reserved to handle an active alert increasing or decreasing in alert severity. For example, an alert updating from warning to error, or critical to error will use this definition.
Note: Alert rules and escalation chains are used to deliver alert data to your custom HTTP integrations. When configuring these, there a few guidelines to follow to ensure notifications are posted and updated as expected in the target integration. These guidelines are discussed in Alert Integrations Overview.
The HTTP method to be used for the HTTP request. Options are POST and GET
Use Custom Headers
Selecting this box will display new configuration fields for adding the header key and header value.
Custom headers are used to define your authentication credentials.
The URL to which the HTTP request should be made.
The username required to make an HTTP request to the specified URL, if required.
The password associated with the specified username.
An HTTP request will deliver a custom alert notification message using a raw data format. Choose for the message to be formatted in: Form Data, JSON, Plain Text, URL-Encoded Form Data or XML.
An HTTP request will deliver a custom alert notification message formatted using Key/Value pairs. With this option, the message's format will be restricted to JSON. You can add one or more JSON key/value pairs to be included in the alert notification message.
You can use tokens in this field.
Include an ID provided in HTTP response when updating alert status
Check this option if you would like LogicMonitor to find the ID (e.g. ticket ID) returned in response to the HTTP request that is associated with a new alert.
LogicMonitor will use this ID in any subsequent requests for alert acknowledgements, clears, and escalations/de-escalations.
HTTP Response Format
If LogicMonitor is to use the ID provided in the response, select the format the response will be in. Choose from JSON, Regular Expression, No Interpretation and XML.
Test Alert Delivery
This option sends a test alert and provides the response, enabling you to test whether you've configured the integration correctly.
The following tokens are available:
- LogicModule-specific alert message tokens, as listed in Tokens Available in LogicModule Alert Messages.
- ##ADMIN##. The user the alert was escalated to.
- ##MESSAGE##. The rendered text of the alert message. This token will also pass all relevant acked information (e.g. the user that acknowledged the alert, ack comments, etc.).
- ##ALERTTYPE##. The type of alert (i.e. alert, eventAlert, batchJobAlert, hostClusterAlert, websiteAlert, agentDownAlert, agentFailoverAlert, agentFailBackAlert, alertThrottledAlert).
- ##EXTERNALTICKETID##. This captures the external system's identifier for the ticket that is being created by the integration so that LogicMonitor can refer to it in future actions on that ticket.
In the above example, a custom HTTP delivery method is used to integrate LogicMonitor with the LogicMonitor Certification Platform, where a custom datasource monitors user scores. When a user fails the exam, their course data is reset. When the alert clears, the user will be un-enrolled from the exam and must purchase another attempt.