Outbound alert webhooks
Outbound webhooks enable you to synchronize your alerts and incidents with ticketing, paging, and automation tools such as Zendesk, Jira Service Management, PagerDuty, Slack, ServiceNow, and Ansible. Outbound webhooks exchange JSON objects over HTTP or HTTPS.
Note
Outbound alert webhook features
Outbound webhooks have the following features:
A UI that guides you through the process of creating the webhook and mapping Moogsoft Cloud 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 — Notifies the external system when an alert or incident matches the CREATE filter for the first time. If the filter is not configured, then the external system is immediately notified when an alert or incident is created.
When Moogsoft creates a new alert or incident, it continuously monitors the alert or incident to check if it matches the CREATE filter. Whenever the alert or incident matches the filter, then Moogsoft sends the CREATE payload to the external system and begins to process updates to the alert or incident. If the alert or incident does not match the filter, then the CREATE payload will not be sent, and updates to the alert or incident will not be processed.
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 and 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.
Activating automation. 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 webhook integration notifications that include bidirectional integration with external ticketing, notification, and automation systems
Ability to view the entire request history for the webhook and filter the requests for errors. You can also view the details for individual errors, which can greatly assist with troubleshooting.
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 alert 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 or 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 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.