[GH-ISSUE #1524] Alert options for Unified Push Messages to reduce battery usage of UP-Client App #1076

New issue

Open

opened 2026-05-07 00:30:05 +02:00 by BreizhHardware · 3 comments

BreizhHardware commented

2026-05-07 00:30:05 +02:00

Owner

Originally created by @krei-del on GitHub (Dec 26, 2025).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1524

💡 Alert options for Unified Push Messages
On my (older) Android phone I need to exclude the ntfy-app as well as the "Element X" (that is the UP-Client App) from battery optimizations to have really instant message notifications.
I would imagine (not proofed) that the battery consumption of "Element X" running constantly in the background is high in comparison to ntfy-app, that should be small.

So why not let ntfy-app notify me about new messages?

Workflow:

ntfy-app shows an alert (mainly on the lock-screen, maybe with a custom icon, that looks like the Element X icon) on new messages that have been published on UnifiedPush-Topic.
As soon as the device is unlocked the alert from ntfy-app has to be removed, because in that case, the ElementX will show its "own" alert (inclusive text etc.) and we don't need be to informed twice (from ntfy and ElementX). Thought: Maybe it is possible for the ntfy-App to find out when Element-X app has consumed the message and can then hide its own alert after this has happend, instead of relying on the screen-unlook event of the android itself. In that case, the user would be informed even when ElmentX has not been started yet ..

Positive:

Keep battery usage really low (because Element X is not excluded from battery optimizations)

Downside:

No message text within the alert-text of ntfy-app on lock-screen
Elment-Calls would probably also be missed

With both downside I personally can live easily.

💻 Target components
Android app

Originally created by @krei-del on GitHub (Dec 26, 2025). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1524 :bulb: **Alert options for Unified Push Messages** On my (older) Android phone I need to exclude the ntfy-app as well as the "Element X" (that is the UP-Client App) from battery optimizations to have really instant message notifications. I would imagine (not proofed) that the battery consumption of "Element X" running constantly in the background is high in comparison to ntfy-app, that should be small. So why not let ntfy-app notify me about new messages? Workflow: - ntfy-app shows an alert (mainly on the lock-screen, maybe with a custom icon, that looks like the Element X icon) on new messages that have been published on UnifiedPush-Topic. - As soon as the device is unlocked the alert from ntfy-app has to be removed, because in that case, the ElementX will show its "own" alert (inclusive text etc.) and we don't need be to informed twice (from ntfy and ElementX). Thought: Maybe it is possible for the ntfy-App to find out when Element-X app has consumed the message and can then hide its own alert after this has happend, instead of relying on the screen-unlook event of the android itself. In that case, the user would be informed even when ElmentX has not been started yet .. Positive: - Keep battery usage really low (because Element X is not excluded from battery optimizations) Downside: - No message text within the alert-text of ntfy-app on lock-screen - Elment-Calls would probably also be missed With both downside I personally can live easily. :computer: **Target components** Android app

BreizhHardware added the

enhancement

unified-push

labels

2026-05-07 00:30:05 +02:00

BreizhHardware commented

2026-05-07 00:30:05 +02:00

Author

Owner

@luneth commented on GitHub (Feb 6, 2026):

Now that RAISE_TO_FOREGROUND has been added, is this still relevant?
None of my UnifiedPush dependent apps need unrestricted battery usage, only ntfy does.

@luneth commented on GitHub (Feb 6, 2026): Now that RAISE_TO_FOREGROUND has been added, is this still relevant? None of my UnifiedPush dependent apps need unrestricted battery usage, only ntfy does.

BreizhHardware commented

2026-05-07 00:30:05 +02:00

Author

Owner

@michaelschefczyk commented on GitHub (Feb 20, 2026):

Using Molly and Signal in parallel on Pixel 9a with GrapheneOS. Signal is the website version with very low usage. Molly is with own Docker instances of Mollysocket and ntfy. I registered it with a landline, and I am not using it at all. Battery usage is <1% for Signal, 12% for ntfy, and 4% for Molly. Molly with unified push including ntfy seems to use 16x as much power as Signal with FCM. In terms of battery, that is not very attractive, unfortunately. Did not try with my matrix homeserver, yet.

@michaelschefczyk commented on GitHub (Feb 20, 2026): Using Molly and Signal in parallel on Pixel 9a with GrapheneOS. Signal is the website version with very low usage. Molly is with own Docker instances of Mollysocket and ntfy. I registered it with a landline, and I am not using it at all. Battery usage is <1% for Signal, 12% for ntfy, and 4% for Molly. Molly with unified push including ntfy seems to use 16x as much power as Signal with FCM. In terms of battery, that is not very attractive, unfortunately. Did not try with my matrix homeserver, yet.

BreizhHardware commented

2026-05-07 00:30:06 +02:00

Author

Owner

@luneth commented on GitHub (Feb 20, 2026):

This issue primarily about reducing battery consumption of UP-compatible application, I would invite you to join the matrix room or discord server to find the root of your battery consumption.

That said, slight off topic, if properly setup, I fail to see how ntfy can use more battery than signal. The way they both maintain their websocket is pretty similar, except signal pings 30 seconds to maintain the WS alive and ntfy does it every 60 seconds.

@luneth commented on GitHub (Feb 20, 2026): This issue primarily about reducing battery consumption of UP-compatible application, I would invite you to join the [matrix room](https://matrix.to/#/#ntfy:matrix.org) or [discord server](https://discord.gg/cT7ECsZj9w) to find the root of your battery consumption. That said, slight off topic, if properly setup, I fail to see how ntfy can use more battery than signal. The way they both maintain their websocket is pretty similar, except signal pings [30 seconds](https://github.com/signalapp/Signal-Android/blob/b5c666a1f4f6802984b0c9096b4563c39a758d26/lib/libsignal-service/src/main/java/org/whispersystems/signalservice/internal/websocket/OkHttpWebSocketConnection.java#L60) to maintain the WS alive and ntfy does it every [60 seconds](https://github.com/binwiederhier/ntfy-android/blob/714b7fcbffe062dfad12ed9f35b809403486138c/app/src/main/java/io/heckel/ntfy/util/HttpUtil.kt#L54).