Delay action
Available for alert and incident workflows |
This action delays the processing of an alert or incident through a workflow for a configurable amount of time.
This action takes the following inputs:
Delay For
The duration of the delay. You can specify the unit of time as seconds, minutes, or hours.
Update Action
Select how to proceed with the action when an incident or an alert is updated during a delay:
Do nothing: Continue counting down the time for the delay without interruption.
Restart the delay: Reset the delay timer from the beginning.
Behavior
When an incident reaches a Delay action in a workflow, it halts at that point in the workflow for the specified duration of the delay. The incident will not be processed by subsequent actions in the workflow until the delay has finished.
If the same incident is updated and triggers the workflow again while the delay is active, the workflow will ignore the incident instead of processing it.
Once the delay expires, the most recent, updated version of the incident is fetched and passed along to the remaining actions in the workflow.
Alert example
Suppose that you want to assign an alert to a certain team if the severity level is Critical. However, you do not want to assign the alert if the alert automatically resolves itself or lowers in severity after a short period of time. To accomplish this, you can create an alert workflow with a trigger, a Delay action, a Filter action, and an Assign action.
After setting up the trigger to initiate the workflow for alerts with a Critical severity, you can configure the Delay action as follows:
Delay For: 30 minutes
Then you can configure the Filter action to check the alert if its severity level is still Critical. If the filter passes, the alert will move on to the Assign action, which you can configure to assign the alert to the specified team.
After all actions are configured, you now have a workflow that meets your criteria. Only alerts that stay open and maintain a severity level of Critical for over 30 minutes are assigned to a designated team, while the rest are discarded.
Incident example
Suppose that you want an incident to send a payload to a webhook if its severity level is Critical. However, you do not want to trigger the webhook if the incident automatically resolves itself after a short period of time. To accomplish this, you can create an incident workflow with a trigger, a Delay action, a Filter action, and a Send to Endpoint action.
After setting up the trigger to initiate the workflow for incidents with a Critical severity, you can configure the Delay action as follows:
Delay For: 30 minutes
Then you can configure the Filter action to check the incident if its severity level is still Critical. If the filter passes, the incident will move on to the Send to Endpoint action, which you can configure to send the incident to the webhook endpoint.
After all actions are configured, you now have a workflow that meets your criteria. Only incidents that stay open and maintain a severity level of Critical for over 30 minutes are sent to an endpoint, while the rest are discarded.