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.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
What is the best practice on when to use Alert Rules vs Alert Policies? The documentation (Alert creation flow | Opsgenie | Atlassian Support) describes the process of alert creation. First we have "Integration create alert rules", then the "Global alert policies" followed by "Team alert policies". I understand the difference between global and team alert policies and why you'd want to use one over the other but don't know what's the best practice with using the rules within the integration configuration vs applying alert policies afterwards.
I'm currently applying most of my logic at the Integration level, and can see that there are plenty of filters available there to support future use cases, but don't quite understand why you'd also have alert policies that seem to be able to do similar things.
What are the pros and cons of each approach?
Hi @James Allen
Great question! While integration actions and policies can perform the same function of modifying alerts, with the policies being processed only after the initial 'create' action, they are able to perform an additional round of modifications.
While the initial 'create' action might add some custom field from the payload to a different field in the alert body, the policy can then filter for that field and perform additional modifications based on it's value.
Policies can also be paused and automatically disabled and enabled using schedules via maintenance policies, so if you have a very specific modification that you may need to change, delete or pause at some point, it may be better to use a policy, rather than having to modify the integration configuration. This allows for better separation of concerns.
The other difference is that policies have a time-based filter, while integration actions do not.