Outbound Webhooks

Outbound webhooks enable synchronize your alerts and incidents with ticketing, paging, and automation tools such as Zendesk, Slack, ServiceNow, and Ansible. It exchanges  JSON objects over HTTP or HTTPS.

Outbound webhook features

Outbound webhooks have the following features:

  • A UI that guides you through the process of creating the webhook and mapping Moogsoft fields to external fields.

  • Filters you can define to select the alerts or incidents that trigger notifications.

  • You can send notifications for CREATE or UPDATE events:

    • CREATE notifications — Immediately notifies the external system when an alert or incident is created.

      When Moogsoft creates a new alert or incident, it sends a CREATE notification and then monitors the alert or incident.

    • UPDATE notifications (optional) — Notifies the system when an alert or incident gets updated. This ensures that the external system is always synchronized with Moogsoft.

      You can also select the Moogsoft updates that trigger a notification: Assignee changed, Severity changed, Status changed, and so on.  There is a hold time of 60 seconds where changes are batched up over this period then sent in one notification

  • Support for basic and bearer token authentication.

  • No limit on the number of webhooks you can create per workspace.

  • Multiple webhooks can send the same or different notifications to different endpoints. This supports the following use cases:

    • Tracking the same incident or alert in multiple systems. This can be useful when you are migrating from one system to another.

    • Automation workflows. You can send one notification to create a ticket (webhook 1) and the same notification to initiate an automation process (webhook 2).

  • Support for incremental development, testing and validation of individual Webhooks. This enables you to identify configuration or connection problems immediately. It also simplifies troubleshooting.

  • The setup of Outbound Webook integration notifications that include bi-directional integration with external ticketing, notification, and automation systems

Important notes

Note the following:

  • When you first create a webhook, its initial status is Provisioned. When it sends its first notification successfully, its status changes to Running. If there is an authentication issue, its status changes to BAD_AUTH.

  • A webhook caches all UPDATE triggers over 60 seconds and then sends all updates in one notification to the endpoint. This prevents a flood of notifications, especially in highly dynamic environments.

  • A webhook does not send an UPDATE if an alert or incident severity decreases. This avoids network flapping when a severity constantly changes.

  • The following situation can occur: the webhook sends a notification. The endpoint receives the notification but the communication path breaks before it returns a response to the webhook. The webhook observes this as a timeout and resends the notification. In this case, the endpoint receives two copies of the same notification.

    For this reason, it is good practice to configure the endpoint to detect and ignore duplicate notifications.

Using multiple outbound webhooks

In some cases you might want to set up multiple webhooks for the same set of alerts or incidents. Here are some example use cases:

  • When an incident is tracked by multiple external systems, and when each system has one or more endpoints. In this case, be sure that each external endpoint has a separate external webhook defined.

  • When a user is migrating from one ticketing system to another. In this case, there can be, sometimes, two or more tickets for each alert/incident. 

  • When a user needs to execute automation as part of a ticket. In this case, two external webhook calls may be made to the same incident.

Note

Business logic for changes to an external system typically reside in that external system, and not in Moogsoft’s assignment or values mapping.  For example, when modification is made to specific logic such as “If a severity setting is updated, then change the urgency and impact of the ticket,” this type of change occurs in the external system.