Our July update brings new features to the email and webhook API’s. You can now close alerts in SIGNL4 when the issue was resolved in your backend system.

Use Case

A typical use case is IT monitoring and auto-recovery. Imagine you get an alert in the middle of the night about an IT issue. A service failed. However, you have configured an automatic recovery mechanism and the server re-starts automatically. After a while the monitoring tool will recognize that the issue is resolved. You can now easily and automatically forward this resolve information to SIGNL4 by email or webhook in order to close the alert in the app. So, when looking at the SIGNL4 app you see the issue has been resolved already by the backend system and you can continue your night sleep.

How does it work?

The new X-S4-Status parameter

Custom parameters

Sometimes the backend systems are limited and to not allow to modify the alert text. In this case you can define where you find the “External ID” and the “Status” as part of your webhook URL.

In this case there is not need to change any code in your backend system. You just need to adapt the webhook URL.

For the webhook URL this looks like this:

https://connect.signl4.com/webhook/<team-secret>?ExtIDParam=Trigger_Id&ExtStatusParam=Trigger_Status&ResolvedStatus=RESOLVED

As you can see there are some additional parameters:

ExtIDParam: The name of an unique identifier of your alert.

ExtStatusParam: The name of the status parameter.

ResolvedStatus: The value that indicates that an alert was closed.

NewStatus: Optional value for which to open a new alert. If this is set and the value of ExtStatusParam is neither the one specified in NewStatus nor the one in ResolvedStatus, the event is discarded. This is useful if there are update events you would like to ignore.