You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Join now to unlock these features and more
Misconfigured integration actions are the most common reason for Opsgenie not behaving the way you are expecting, particularly with alerts not being closed, acknowledged, or created.
However, before diving into integration actions it’s essential to understand how the alias field works.
The alias field is how Opsgenie matches new, incoming payloads to existing alerts. If an incoming payload has an alias that matches the alias of an open alert (does not apply to closed alerts), it will do one of two things;
Each incoming payload can only trigger one event; it can either create one alert, increase the count of an open alert by one (deduplicate), or perform one action (acknowledge, add note, close) on an open alert.
Actions are processed from top to bottom and the action taken will be the first action whose filter matches the payload.
This is where mistakes are often made.
Now, with everything we know, if an incoming payload contains an alias that matches the alias of an open alert and it also matches the filter for the ‘close’ action, it should close the open alert, right?
If the payload also matches the ‘create’ action, rather than being closed, the alert will always be deduplicated and its count will be increased by one.
This is because the ‘create’ action comes before the ‘close’ action.
And remember, each payload can only trigger one action.
This is where many customers think that the ‘close’ action didn’t work, when in reality the ‘close’ action was never triggered, instead the ‘create’ action was.
You can check the alert’s activity logs to see if it was deduplicated.
The actions themselves can be seen on the integration's advanced settings page, which is only visible on the Standard and Enterprise plans. The actions, in order from top to bottom, are:
Each action is technically optional, though it is usually recommended to have at least one action for each type other than ‘ignore’ - which is only necessary if you need to prevent alerts from being created with specific criteria.
You can optionally set multiple actions for each type of action. For example, you can configure multiple ‘create’ actions, each with different filters, which will allow you to customize the payload of the alert with dynamic fields so that you can create unique, customized alerts, based on the incoming payload data.
The most common mistake, when configuring actions is making the ‘create’ action filter too broad or setting it to “match all alerts.”
When a ‘create’ action is set to match all alerts, it can never close, acknowledge or add a note to an open alert.
The ‘match all alerts’ filter setting should only be used if you are wanting the integration to create alerts only for all cases - or if you are using an API integration.
API integrations are different.
Every integration other than the API integration uses a single endpoint. Through the use of filters, we can send different payloads to a single endpoint and still trigger different actions.
With API integrations, however, each action has its own endpoint - so you could set a ‘catch all’ filter on the ‘create’ action to match all alerts and it would not prevent alerts from being closed like it would on any other integration.
This is because API integrations send ‘create’ actions to a /create endpoint and ‘close’ actions are sent to a /close endpoint.
In addition to incorrect action filters, having an incorrectly configured alias can also cause unwanted deduplication.
In the ‘create’ action the alias should use dynamic fields that will produce a unique value. If the value is something too general and is not unique per alert, this will cause unwanted deduplication.
Additionally, the alias in the other actions (close, ack, add note) will need to use the same dynamic values so that the incoming payload can successfully match the alert.
If you having issues with alerts not being closed, created, or acknowledged and you’ve checked your integrations and cannot spot the problem, the alert activity logs and the debug logs can usually point you to the culprit.
In order to ensure that we continue to provide useful content, please let us know if this Article is helpful (Thumbs Up/Down). Also, to help us improve, feel free to provide additional feedback (directly in the community).