Are you in the loop? Keep up with the latest by making sure you're subscribed to Community Announcements. Just click Watch and select Articles.

Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Configuring the Opsgenie Alias Field

In the Opsgenie ecosystem, the Alias field plays a pivotal role. It is instrumental in deduplicating alerts and managing actions like acknowledging, closing, and adding notes to existing alerts. However, its significance is often overlooked, leading to common misconfigurations. This article aims to shed light on the importance of the Alias field and guide users on its proper configuration.

The Importance of the Alias Field

  1. Deduplication: The Alias field is central to Opsgenie's deduplication feature, which is designed to combat alert fatigue. Instead of creating a new alert every time an issue arises, if the alias of an incoming alert matches that of an existing one, Opsgenie increases the count of the existing alert. This ensures that repeated alarms for the same issue don't flood your dashboard. However, once an alert is closed, its Alias can be reused for a new alert. More on deduplication can be found here.

  2. Managing Alert Actions: The Alias is also vital for matching incoming payloads to existing alerts. This matching enables actions like acknowledging, closing, and adding notes to specific alerts.

  3. Specificity Matters: The Alias must strike a balance in its specificity. An overly specific alias might not deduplicate effectively, leading to multiple alerts for a single issue. Conversely, a too-general alias might lump different issues under one alert, potentially causing critical issues to go unnoticed.

Common Pitfalls and Best Practices

  • Misconfiguration: A frequent error among Opsgenie users is misconfiguring the Alias field. This often results in users searching for alerts they believe were never created. In reality, these alerts might have matched the Alias of an open alert, thus increasing its count instead of spawning a new alert.

  • Blank Alias: If the Alias is left unset in the integration settings, Opsgenie defaults to using the alert ID as the alias. In such cases, additional actions on the alert will only work if the external system retrieves the alert ID from Opsgenie and dynamically inserts it into subsequent payloads.

  • Consistency Across Actions: If you're managing alerts from an external system, ensure the Alias field is consistent across 'create', 'acknowledge', 'close', and 'add note' actions. Inconsistencies can lead to discarded payloads, with "no matching actions" appearing in the debug logs.

  • Dynamic Values: To ensure Alias consistency, use the same dynamic value or combination of dynamic values across all actions. Once parsed, these values should match if the alert is meant to deduplicate, and differ if a new alert is intended.

  • Advanced Matching: Opsgenie offers advanced tools like string processing and regex to extract specific parts of a field or match patterns. These can be employed to craft a customized alias that encapsulates the desired data.


The Alias field in Opsgenie is more than just a label; it's a powerful tool that, when configured correctly, can streamline your alert management process. By understanding its nuances and employing best practices, you can optimize your Opsgenie experience, ensuring that critical issues are always highlighted and addressed promptly.

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).


Thanks @John M ,

We're trying to set up Opsgenie to absorb all the vendor notifications for patch management (CISA, Microsoft applications, operating system, third party tools/software) and then filter based on Services and/or Assets in our org; if the vendor or security notification actually involves a Service or Asset we have, then we want to create a change ticket in our JSM project. I can see how using the Opsgenie alias field to avoid creating multiple tickets for the same patch notification could come in handy here.

Any thoughts or guidance on our specific use case? Thanks!


John M
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Nov 01, 2023

Hi @J Conners ,

It's hard to say without seeing your exact setup. Based on what you've described, you can probably just use filters on the 'create' action to filter for only  Services and/or Assets in our org, so that only those ones end up creating alerts and then sending those alerts to JSM to create tickets. You can always open a support ticket (or a chat if you're using Opsgenie standalone) so we can take a look at your configuration and a sample payload to get a better idea though. 


Log in or Sign up to comment
AUG Leaders

Atlassian Community Events