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. For more information, see Alert Rules.

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:

Name

The name of the custom HTTP alert delivery template.

Description

The description for the custom HTTP alert delivery template.

Will requests be sent to different URLs?

Use the Same URL and data to notify on various alert activity

This option will send HTTP requests for alert acknowledgements, 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 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.

For each request, you can select which alert statuses trigger the HTTP request. Requests are sent for new alerts (status: Active), and can also be sent for alert acknowledgements (status: Acknowledged), clears status: Cleared) and escalations/de-escalations/adding note (status: Escalated).

HTTP Method

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.

For the Content-Type header key, you can add charset value as null or charset with a valid MIME type. If you provide an invalid charset or MIME type, a valid MIME type with UTF-8 is added by default.

URL

The URL to which the HTTP request to the specific URL, if required.

Password

The password associated with the specified username.

Alert Data

Raw

An HTTP request will deliver a custom alert notification message using a raw data format. Choose the message to be formatted in: Form Data, JSON, Plain Text, URL-Encoded Form Data or XML.

Key/Value Pairs

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.

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 XM

Tokens Available

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.

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.

Test Alert Delivery

This option sends a test alert and provides the response, enabling you to test whether you’ve configured the integration correctly.

Example

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 anther attempt.