Top Ten User Mistakes in Opsgenie and How to Overcome Them

[#1]

Here are ten common mistakes users make and how to sidestep them: 

1. Routing Directly to a Schedule

Users sometimes wonder why their escalations aren't triggered. If a routing rule points straight to a schedule, it bypasses any set escalations. Remember, escalations only activate if they're the direct target of a routing rule. An informational icon appears when you route directly to a schedule, hovering over it provides more details.

2. Setting a Static Alias

Frequent confusion arises when new alerts aren't generated, but they're merely being deduplicated. The alias field isn't arbitrary; it matches incoming data to open alerts for actions like acknowledgment or deduplication. Using a static alias in an integration means all incoming data will have the same alias, leading to constant deduplication. Always use a dynamic value for the alias.

3. Misconfiguring Integration Filters

Some users find that alerts aren't acknowledged or closed as anticipated. If an integration filter for 'create alert' is set to 'match all alerts', every processed payload by the integration will match, preventing other actions like 'close' or 'acknowledge'. Ensure your filters are set correctly to allow multiple actions.

4. Overlooking Team Assignments for Integrations

If an integration isn't linked to a team, the resulting alert won't have an owner team. For team-based policies to apply, the alert must belong to the appropriate team.

5. Prematurely Viewing Alerts

Missed notifications often result from users opening alerts. Once viewed, Opsgenie assumes you're aware of the alert and skips sending notifications. The activity log will reflect this action.

6. Using Incorrect API Keys

Errors can arise from using the wrong API key type. Opsgenie offers two types: one from API integrations and another from the API Key Management tab. The latter is primarily for configuration-based requests, with certain alert actions restricted.

7. Misunderstanding Incident Auto-matched Alert Behavior

Users employing incident rules sometimes wonder why new alerts aren't notifying. Alerts matching an incident rule automatically become associated alerts of that incident, and Opsgenie won't send notifications for these to reduce alert fatigue. It's crucial to close incidents promptly as alerts matching an open incident won't notify.

8. License Limitations

If you're trying to add new users without available licenses, you'll encounter an error. Licenses must be increased before adding more users. Owners can adjust this under Settings >> Subscription.

9. Combining Primary and Secondary On-call Rotations

If both primary and secondary on-call users receive notifications simultaneously, it's likely because both rotations share the same schedule. To ensure only the primary on-call user is notified, place primary and secondary on-call rotations on separate schedules.

10. Using Routing Rules for Incoming Calls

For those using an incoming call integration, be aware that the call itself doesn't process against routing rules, only its associated alert does. To route to an escalation, adjust the settings in the incoming call integration directly. Note that time gaps in an escalation are ignored for live calls.

By understanding and addressing these common pitfalls, you can optimize your Opsgenie experience and ensure smooth alert and incident management.

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

[Dave Mathijs]

Thanks for sharing your tips and best practices @John M 

Opsgenie is still a blind spot for me, but with this article, I'm interested in exploring the features and configuration settings.

[Usha]

Hi @John M , I have integrated incoming call to opsgenie, now I understand the routing rules are only for alerts, I would like to know how can I set the on call schedule so that if the on call user doesn't pick the call , the call goes to next person in rotation (rather than random numbers), i have set the number of users to be tried as 2.

[John M]

Hi @Usha You can get the call to follow an escalation by setting that escalation in the 'forward to call' section of the incoming call integration:

Then you would need to use the 'next user in rotation...' option on the escalation:

Keep in mind there is no option on the escalation to continue to notify users on the rotation beyond the next user. But it sounds like you only need to notify 2 users, so this should work for you. 

[Usha]

Thank you @John M for the response that's helpful. I also want to confirm is the user picked based on availability in the mobile network? when I tested the calls with different users I saw that the call did come to both primary & secondary but wasn't in sequence, sometimes the primary user got the call first & sometimes the secondar user got the call first.

[John M]

@Usha If you use a time gap in the escalation, it should call users in the same order they are on the escalation. While the actual amount of time in the escalation ( example: "5 minutes after creation") will not be applied since it's a live call, any time gap greater than 0 should force the escalation to go in order.

[Usha]

Thank you @John M  worked perfectly! Appreciate your help :)