Why does opsgenie skip rule if user saw alert?
Asked by Daniel Hardaker:

Hi i want it so opsgenie doesn't skip log says: RULE\[NEW ALERT\]\[CREATE\]\[IMMEDIATE STEP\] -\> Skipped notifying. User has seen this alert.  

We cant have this the user should be reminded they need to acknowledge the alert before it gets escalated!


Answers:
author: Skyler Ataide
body: Hi Daniel!

This functionality exists with the aim of reducing alert fatigue and there is not currently a way to turn this functionality off and revert alerts to an un-seen status once the user has opened/viewed the alerts. However, there are a few ways currently to have 'seen' alerts still notify users until they are ACK'D or Closed. One such way is through the Escalation Policy for a team. Through an Escalation Policy, you can configure the rules so that if the Alert has not been acknowledged in X minutes, notify someone, then if it's still not acknowledged in Y minutes then notify someone else (or the same person again). This is our design for alerting team members to alerts after a period of time while an alert is 'seen' but not acknowledged.

Additionally, we have a public feature request here which you can vote for and add yourself as a watcher on for future updates on the ability to disable "stopping notification when user views the alert": <https://jira.atlassian.com/browse/OPSGENIE-36>

Hopefully this helps!

comments: author: Daniel Hardaker
body: thanks Skyler, yes ive joined the protest. this is such stupid logic that i have already on my escalation policy "IF NOT ACKNOLEDGED THEN DO THIS" but i look at my phone and not acknowledged it and then it skips me! how is that **"IF NOT ACK THEN DO THIS"** thats actually **"IF not ack or not seen do this"** . putting silent criteria in defeats the whole object of us setting our own conditions!!  

<br />


author: Skyler Ataide
body: Hi Daniel,

I can certainly understand the value of this use case. Thank you for leaving a comment on the feature request as this does help our product team triage these feature requests for future development. Although I'm unable to provide an exact estimate for when/if this feature will be implemented, there does appear to be a significant number of votes/comments for the ability to disable "stopping notification when user views the alert" which should help the feature request gain priority above lower ranked requests.


author: Josh Rossman
body: [@Skyler Ataide](/t5/user/viewprofilepage/user-id/4456296)can you elaborate on the workaround for this? I discovered this while testing out Escalation policies in our sandbox (new JSM UI). Your workaround is what I had setup within the policy, I'm not seeing how what you recommended would circumvent the "has been seen" issue.

Thanks!


author: Skyler Ataide
body: Hi [@Josh Rossman](/t5/user/viewprofilepage/user-id/5519525), the workaround suggested above would involve notifying separate users of an alert until they are ACK'D or Closed. This wouldn't resolve notifying the same user of an alert if they have already seen the alert. One suggestion here is to enable the**Repeat** and ***if alert is not closed, revert acknowledge and seen states back on each repeat turn*** options. With these two options enabled, the same user can be notified twice on the same alert. However, if there are other users in the same escalation policy, this option would still notify those separate users in order before the repeat is enforced.

![Screenshot 2024-07-02 at 12.35.32?PM.png](https://community.atlassian.com/t5/image/serverpage/image-id/333114i61C9E2F9234C24C4/image-size/large?v=v2&px=999 "Screenshot 2024-07-02 at 12.35.32?PM.png")


author: Daniel Hardaker
body: just to be clear the work around i had to remove because we dont close the ticket until a lot time later so it just kept reverting it. we would have to change the way we process the tickets in order for this work around to work for us. Unfortunately we cannot close the ticket off until its resolved not just because its been seen/acknowledged. Im hoping that the feature will be added soon as its been a year since we had this bug. it should never have been coded like this in the first place. makes no sense.


author: Skyler Ataide
body: Hi [@Daniel Hardaker](/t5/user/viewprofilepage/user-id/1506427) thanks for your message here, I regret to hear that the workaround does not fit your use case. I still do not have a definite timeline for when the feature request linked above will be implemented; however, the latest comment on the feature request does confirm that the ticket is on our product teams backlog and updates will be provided as they become available on the public feature request.