LogicMonitor Integration Guide

LogicMonitor is a SaaS-based performance monitoring solution, enabling IT Ops teams to intelligently monitor the infrastructure, applications and services fueling their business.  Using LogicMonitor’s monitoring combined with PagerDuty’s advanced on-call scheduling and alerting capabilities, you can be assured that you’ll be notified as soon as there is a problem within your infrastructure.

In PagerDuty

  1. From the Configuration menu, select Services.
  2. On your Services page:If you are creating a new service for your integration, click +Add New Service.

    If you are adding your integration to an existing service, click the name of the service you want to add the integration to. Then click the Integrations tab and click the +New Integration button.


  1. Select your app from the Integration Type menu and enter an Integration Name.If you are creating a new service for your integration, in General Settings, enter a Name for your new service. Then, in Incident Settings, specify the Escalation Policy, Notification Urgency, and Incident Behavior for your new service.
  2. Click the Add Service or Add Integration button to save your new integration. You will be redirected to the Integrations page for your service.
  3. Copy the Integration Key for your new integration: RS_API_pd_3

In LogicMonitor

  1. Select Settings, then Integrations. Click Add and select PagerDuty.
  2. In the Service Key field, enter the Integration Key that you copied from PagerDuty. The HTTP Delivery section controls how LogicMonitor formats and sends the HTTP Post requests to create, update and/or close incidents. You shouldn’t need to edit anything in the HTTP Delivery section, but if you wish to customize something you can use the information in the following steps to guide you. If not, you can save the integration now and proceed to add it to an escalation chain. Once you’ve done this, you’ll need to add the escalation chain to an alert rule.

Customizing HTTP Delivery

By default, LogicMonitor will pre-populate four different HTTP requests, one for each of:

      new alerts (Active)


      acknowledged alerts (Acknowledged)


      cleared alerts (Cleared)


      escalated alerts (Escalated)

For each request you can select which alert statuses should trigger the HTTP request. Requests will be sent for new alerts (status: Active), and can additionally be sent for alert acknowledgements (status: Acknowledged), clears (status: Cleared) and escalations/de-escalations (status: Escalated). Note that each alert status can only be associated with one request. Since LogicMonitor auto-populates a different request for each alert status by default, you’ll have to delete a request in order to see the option to include that alert status in a different request. When editing the HTTP requests, you’ll see the following fields:

HTTP Method

The HTTP method for PagerDuty integrations is restricted to POST


The URL that the HTTP request should be made to. This field is auto-populated based on information you’ve provided, and for this integration, should use the PagerDuty integration API endpoint (https://events.pagerduty.com/generic/2010-04-15/create_event.json).

Alert Data

The custom formatted alert data to be send in the HTTP POST request (used to create, update and close PagerDuty incidents). This field will be auto-populated for you. If desired, you can customize the alert data field using tokens. The following tokens are available:

datasource alert message tokens
eventsource alert message tokens
batchjob alert message tokens

        : the user the alert was escalated to


        : the rendered text of the message, using any datapoint specific alert templates


        : the LogicMonitor ID associated with the alert, as used in email and other alert messages


        : the type of alert being triggered (i.e. datasource, cluster, event, batchjob, service)


        : reports whether this is an active alert, or an alert cleared message. Possible values are active or cleared. Note that you will always receive a notification when an alert clears, but there will not be an indication that it is an alert clear notification (as opposed to an active alert notification) unless the


        token is included in the subject or email body fields.


        : the PagerDuty incident ID

Include an ID provided in HTTP response when updating alert status

Check this option if you’d like LogicMonitor to find the PagerDuty incident ID returned in the response to the HTTP request associated with a new alert, and use the ID in any subsequent requests for alert acknowledgements, clears and escalations/de-escalations. By default, this option will be selected.

HTTP Response Format

If LogicMonitor is to use the ID provided in the response, select the format the response will be in.


Verify that LogicMonitor and PagerDuty are Communicating

Once you have configured your integration and triggered an alert, you will see that an incident is triggered within PagerDuty.  Once the alert clears, the incident in PagerDuty will be resolved.


Will LogicMonitor incidents automatically resolve?

With the default HTTP Requests, as soon as an alert clears in LogicMonitor it will also resolve the incident in PagerDuty.  If incidents are not automatically resolving within PagerDuty, ensure alert clear messages are not suppressed in your LogicMonitor implementation.

How can I setup LogicMonitor to be tied to multiple PagerDuty services?

Once you have a second LogicMonitor service set up within PagerDuty, create a new external alert within LogicMonitor. You will duplicate the “In LogicMonitor” section above, this time using the PagerDuty Service Integration Key from the additional PagerDuty service on which you’d like to trigger an incident.

If you are having trouble completing the installation, please contact our support team.