Support Center

Robots Table

Introduction to Alert Integrations

LogicMonitor can be made to work with most chat tools, ticketing systems and other services you may utilize internally. These alert integrations allow LogicMonitor to interact with your third-party collaboration tools, supporting activities such as opening, updating and closing incidents in these tools, based on LogicMonitor alerts.

Out-of-the-Box Alert Integrations

Your LogicMonitor account comes pre-configured with the following out-of-the-box integrations:

Custom Alert Integrations

In addition to numerous out-of-the-box integrations, LogicMonitor also supports the creation of custom integrations. Typically, these integrations are achieved using custom HTTP delivery (webhooks) or custom email delivery. LogicMonitor’s custom HTTP delivery routes alerts to external systems and tools via HTTP requests, and can retrieve ticket IDs or other unique identifiers from the response. Custom email delivery emails custom formatted alert notifications to external systems and tools in response to alerts that are triggered in your account. In other cases, custom integrations may utilize the LogicMonitor API or external alerting capabilities.

Creating an Alert Integration

All new integration setups can be initiated via Settings | Integrations | Add, as shown next. For details on configuring an out-of-the-box alert integration (e.g. Autotask, Slack, etc.) or a common custom integration for which we provide documentation (e.g. Campfire, Zendesk, etc.), refer to that integration type’s individual support article. If no documentation exists for the alert integration you would like to create, review the instructions for creating custom alert integrations via either custom HTTP delivery (webhooks) or custom email delivery.

list of integrations

Alert Rule Configuration Guidelines for Alert Integrations

When associating alert rules with alert integrations, it’s important that a single alert rule maintains the entire lifecycle of the alert. Put another way, if an alert rule references delivery to an alert integration as part of its escalation chain, that rule should be configured to match all potential alert level severities. If it doesn’t, you risk:

  • The delivery of duplicate payloads to the integration target and/or
  • Orphaned tickets (i.e. tickets that never clear)

Why? When LogicMonitor prepares to deliver alert information to a third-party integration, it looks to see if an external reference such as a ServiceNow ticket ID or PagerDuty reference ID is in place for that alert. These references are returned by the integration target in its response to LogicMonitor’s HTTP/S post. LogicMonitor captures this reference, associates it with the alert using a key that consists of the alert rule ID and integration ID, and then uses it to tie all future activity for that alert back to the original target integration object (e.g. ticket).

If an external reference is not found for an alert, a “create” payload is sent to the integration target that results in the creation of a new object. If the external reference is found, an “update” payload is sent to the integration target that serves to change the status of the existing object in some way (e.g. updates the alert severity status or indicates the alert has been cleared or acknowledged).

Because LogicMonitor associates the external reference with a combination of keys that include the alert rule ID, duplicate and/or orphaned tickets can result if multiple alert rules are involved, effectively breaking the connection with the external reference. For example, consider the following scenario:

An alert rule matches a critical alert and delivers it to a ServiceNow integration, resulting in the creation of a ticket. The alert is later de-escalated to a warning within LogicMonitor, which matches a different alert rule that does not deliver to the ServiceNow integration. The ServiceNow ticket created by the critical alert would receive and reflect the severity level change, but would never clear because the clear would take place at the warning severity level which is governed by an alert rule that does not deliver to the ServiceNow integration.

(Even if the second alert rule did deliver to the integration, the original alert would be orphaned because the second alert rule has no connection with the external ticket ID. In addition, two tickets would exist in ServiceNow for the same issue (the first created as a result of the critical alert and the second as a result of the critical alert de-escalating to warning)).

Note: The external reference can be exposed via the ##EXTERNALTICKETID## token.