We have set up JSM Operations alerts recently with the whole shebang, DND override, quiet hours override, max alert volume setting, every alert is P1 - Critical, etc.
These alerts seemed to work as expected, alerting through DND and silent modes.
The issue is that many of us don't use the JIRA app much otherwise. The app seems to get fully stopped for inactivity and when this happens, the alerts no longer appear on our phones at all besides the SMS option. I've tested this as well by opening my app and alerts go off full blast as expected. Then I'll go and force close my JIRA app and again, nothing comes through.
Is there any way around this? It looks like Android doesn't have the ability to set these alerts to be critical to bypass this issue. I've tried setting my phone to prevent it from cleaning up the JIRA App for inactivity but this will waste a lot of time trying to ensure it works.
EDIT: Additionally after I re-open the app, it seems I get all the notifications that were missed, spread out over the next subsequent 10 minutes, even though the alerts themselves have been closed long beforehand.
Related: https://community.atlassian.com/forums/Jira-Service-Management/No-apparent-setting-to-enable-Critical-Alerts-in-Jira-Cloud-for/qaq-p/2692358
This seems to have fixed the issue for the iOS counterparts on the team with varying issues regarding apple watches and whatnot. As for Android, it appears there may be a similar fix suggested for Android that has gone ignored for a year and a half: https://jira.atlassian.com/browse/JSDCLOUD-15997
@Joshua Hong Two different Android mechanisms are colliding here, and JSDCLOUD-15997 only covers one of them.
Critical Alerts parity with iOS, which is what that ticket tracks, is about bypassing Do Not Disturb while the app is running. Your DND override already works, so that part is fine. What you are actually hitting is Android's own app hibernation: once the OS treats the Jira app as unused for a while, it force-stops it, revokes its background permissions, and blocks push delivery entirely. Google's Firebase Cloud Messaging documentation confirms a force-stopped or background-restricted app cannot receive push messages at all, and there is no reliable app-level fix for that, Atlassian included. So even if Android gets Critical Alerts one day, a fully stopped app still would not process anything, DND or not.
The backlog you get about 10 minutes after reopening the app is those queued alerts finally being delivered once the app is running again, not a separate bug.
What actually keeps the app reachable between alerts:
This is device side, outside Atlassian's control, which is why the SMS fallback you already see working is the intended safety net rather than a bug. If you still want Android's Critical Alerts for defense in depth, JSDCLOUD-15997 is open, voting there helps its priority.
Thank you, I did end up setting those but it's a bit harder to test over time. I will rely on those other methods and keep an eye on 15997.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.