Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

JIRA Operations Alerts do not trigger if App is closed - Android

Joshua Hong
June 29, 2026

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

1 answer

0 votes
Germán Morales
Atlassian Partner
June 30, 2026

@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:

  • Set battery usage for Jira to unrestricted, not just optimized.
  • Turn off the setting that removes permissions and pauses app activity if unused, from the app's info page or from the Play Store app under Manage apps and device.
  • Never force close the app manually, that puts it in the exact same stopped state you are trying to avoid.
  • On Samsung, Xiaomi, OnePlus and similar, also allow list Jira in the manufacturer's own battery or sleep manager, stock Android settings alone will not override those.

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.

Joshua Hong
July 1, 2026

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.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
TAGS
AUG Leaders

Atlassian Community Events