mirror of
https://github.com/binwiederhier/ntfy.git
synced 2026-05-09 08:26:00 +02:00
[GH-ISSUE #1195] Is more than 10% battery usage normal? #842
Labels
No labels
ai-generated
android-app
android-app
android-app
🪲 bug
build
build
dependencies
docs
enhancement
enhancement
🔥 HOT
in-progress 🏃
ios
prio:low
prio:low
pull-request
question
🔒 security
server
server
unified-push
web-app
website
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ntfy#842
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jayb-g on GitHub (Oct 9, 2024).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1195
❓ Question
Asked initially at https://github.com/binwiederhier/ntfy-android/issues/90
I tested this app on a degoogled android and it gives more than 10% battery usage. The least I have seen is 4-5%.
This is on Mobile data, no WiFi.
On (mostly)WiFi it seems to work fine with <1% battery usage.
All default settings. With only molly unifiedpush setup with it.
Battery optimization is disabled for both ntfy and molly-up
Is this normal battery usage for ntfy?
Android 14 latest on Pixel 7
@titulebolide commented on GitHub (Oct 9, 2024):
Do you have battery optimization enabled for this app?
@jayb-g commented on GitHub (Oct 9, 2024):
I have all the default and recommended settings. So battery usage is set to unrestricted. The issue seems to be mostly when on mobile data.
@Finn10111 commented on GitHub (Oct 22, 2024):
@jayb-g Maybe have a look here: https://github.com/binwiederhier/ntfy/issues/687
@jayb-g commented on GitHub (Oct 23, 2024):
@Finn10111 interesting and seems likely
@aelth commented on GitHub (Oct 26, 2024):
I'm experiencing the exact same issue on Pixel 8a, Android 14 and (recently) 15.
It is caused by the keep-alives (TCP + websocket ping-pongs) that are constantly waking the radio up. These intervals are hard-coded in go source - https://github.com/golang/go/blob/master/src/net/dial.go#L19-L23
Ntfy alternatives like gotify are also suffering from the same issue, see here: https://blog.wirelessmoves.com/2020/08/improving-the-keep-alive-behavior-of-gotify.html
Gotify has the option to increase/remove keepalives, but unfortunately even when using gotify and configuring the options, it didn't help me and I believe this is due to using another go-based "product" in the chain - Caddy as a reverse proxy.
I cannot easily remove Caddy to prove my hypothesis...
In any case, since ntfy doesn't have the configurable keepalive options, your only options is to use the "cloud"/paid version that is using FCM.
@jayb-g commented on GitHub (Oct 27, 2024):
@aelth you're probably right about pixel 8a having the problem. But keepalives shouldn't be a problem in general. Keepalives shouldn't cause a battery problem at all. That's what it's (kinda) designed for. I'm no expert but this has something to do with specific devices/radios having the issue. So probably vendor drivers related and maybe fixed only by OS update some time in future.
On the other hand I wouldn't rule out the possibility of buggy implementations of keepalives by certain apps. Can be deduced if we can confirm at least one or two apps which uses push/keepalives but doesn't use a lot of battery on mobile data.
Would help devs if ntfy logs(while only on mobile data) is shared.
@jayb-g commented on GitHub (Nov 8, 2024):
Recently observed more than 40% battery usage on mobile data in around 10 hours of wifi outage.
Logs: https://nopaste.net/60DFZahemR
@pyksy commented on GitHub (Nov 18, 2024):
Same here: ntfy (using WebSockets) drains battery when on 5G mobile data. The phone is a OnePlus 8T and the phone settings reports 33% battery usage for ntfy. No such problems with Signal (mentioned in #687 linked above) nor any other apps.
Pretty much nothing in the 2 hours worth of logs https://paste.debian.net/1335868/
@osousa commented on GitHub (Dec 11, 2024):
Any news on this? Ntfy was always somewhat greedy in terms of battery, but i don't think i ever noticed it being this much power hungry... it depleted 45% of battery in half a day on 5G....
@r7l commented on GitHub (Jan 16, 2025):
Reading other related issues, it seems there will never be any update on this. I also have like 45 - 50% of battery usage with Ntfy. This is a brand new Pixel 9 and i can only make it to stay alive over night when loading prior of going to sleep. There has to be a way to get better battery usage. I wouldn't even mind 10min delay on notifications or something when this would make the app use around 1%.
@hardwareadictos commented on GitHub (Feb 18, 2025):
Nothing? I have a pixel 7 and i observe the same behavior. Nearly imposible to use ntfy on mobile data due the battery drainage
@pyksy commented on GitHub (Feb 21, 2025):
Update: for whatever reason the ntfy Android app seems to no longer drain my battery. I haven't touched the phone app nor the ntfy server configs, it just seems to have resolved on its own for now and I have no idea why.
I can see how this issue might be a nightmare to debug.
@osousa commented on GitHub (Mar 13, 2025):
Following @pyksy 's boat, i have noticed that the unusual wild battery drainage is gone for now.
@hardwareadictos commented on GitHub (Apr 9, 2025):
Don't know what you did, but i am experiencing the same drain over LTE/5G
@tg-- commented on GitHub (Apr 29, 2025):
I have the same issue on a Pixel 8 (GrapheneOS).
Staying on WiFi I'm realiably at <1% for ntfy, no matter the other usage.
Without WiFi, on the road, which I'm most of the time, I'm always above 40% (with heavy other usage) to over 60% (with low other usage), so ntfy clearly uses most power.
Still somewhat more efficient than having Matrix push messages without ntfy, tough.
@skeller commented on GitHub (Jun 19, 2025):
These are not hardcoded values, as the name & code shows. These are just the defaults. You can set them with SetKeepAliveConfig() on the TCP connection.
It would be pretty easy to make that configurable & set it on the connection. I can have a look at it.
Also, the server should use high intervals for both WS pings and TCP keepalives as the for the server it is not that critical to get timely updates on the connection status. The client, however, should notice pretty quickly when a connection is down so that it can start a new one. I guess Android has sensible defaults for TCP keepalive and WS pings are at 1min for the client.
Edit:
https://github.com/skeller/ntfy/tree/tcp_ka_cfg has changes to make the TCP keepalive timer configurable. It is currently untested. Please note that TCP keepalive of the ntfy server is irrelevant as soon as you use any kind of reverse proxy. I use nginx which doesn't use TCP keepalives by default AFAIK.
@user-mb commented on GitHub (Feb 23, 2026):
i am still experiencing this. huge difference of battery use between WiFi and Mobile Data.
i set my server (caddy) to 5 min keepalive, i hoped that this would help, but it didnt change the drain.
i also noticed that the app seemingly doesnt react to androids data saver feature, but this is just a feeling.
does anyone have suggestion what to modify for improved battery life?
@tg-- commented on GitHub (Mar 3, 2026):
I have tried many different setups and configurations, but nothing really seems to help.
All indicators point to the behavior of the Exynos Modem and its Firmware/Software-Stack on Pixel devices as the culprit.
I'm not seeing the issue on a Xiaomi/Qualcomm device, though I've not tested much with it.
It also doesn't matter if the device doesn't move, the drain is still there when on Cellular, so it's no side-effect of cellular-handovers and mobility, but some issue on the Google-Exynos setup that doesn't allow the modem to properly sleep when the ntfy connection is active.
Since this is a fully proprietary setup of driver and firmware blobs, I don't see a practical way to debug it.
@bam80 commented on GitHub (Mar 3, 2026):
Does Sunup have the same issue?
Also, as the issue doesn't show up with FCM, we could investigate what's the pattern triggering it.
@jayb-g commented on GitHub (Mar 3, 2026):
Although the issue was present some time back, on P7, maybe even on P8; I have not observed the same since a long time on P9 so the issue might have been inadvertently fixed by firmware update ?
Edit: current usage is at 1%, mostly at <1%
@tg-- commented on GitHub (Mar 3, 2026):
This is quite possible, the Pixel 9 and 10 use the newer Exynos 5400, while Pixel 9a, 8 and 7 use a Exynos 5300 variant.
Since we now have at least 1 data point, that the Pixel 9 might not be affected and most reports with the issue appear to be from pixel users, it might be interesting to gather who actually has the issue.
There's no real point in looking for a fix when the issue is in the firmware, though a workaround might be found.
@OneWeekNotice commented on GitHub (Mar 3, 2026):
Apologies if this is causing noise as I don't fully understand the issue.
Would implementing a poll request for the Android app be a work around for this issue?
This is outlined in https://github.com/binwiederhier/ntfy/issues/358 where there is an attached PR
@user-mb commented on GitHub (Mar 3, 2026):
I unfortunately have to add that I am using the Pixel 9, however with GrapheneOS, experiencing the battery drain issue on mobile data. There might be some differences between Google's Android and AOSP though.
@johanngrobe commented on GitHub (Mar 13, 2026):
I am a Pixel 10 Pro user with Graphene OS. The battery drain makes ntfy pretty much unusable on Wifi and 5G. It does not matter.
@MirmiQ commented on GitHub (Apr 1, 2026):
Hello! I'm on a Pixel 8a with GrapheneOS, I experience a huge battery drain from ntfy, also with only one argument and very few notifications during the day. I ended up disabling it at the moment. I hope this problem could be investigated soon.
@dingodoppelt commented on GitHub (Apr 7, 2026):
Hi there, experiencing the same issue on Pixel 7a/GrapheneOS. I started noticing this just recently though. I used ntfy before with a different standard-server until a week ago when I switched to my self hosted instance of ntfy. The only other thing that I changed about my setup is that I now use Element-X instead of Element Legacy so there is one more app using unified push over ntfy.
@binwiederhier commented on GitHub (Apr 7, 2026):
Boy GrapheneOS really blows when it comes to constant connections apparently. For most users, ntfy battery usage is not noticable at all. It's < 1% on my phone. Some even report that it doesn't show up in the list of battery apps.
@OneWeekNotice commented on GitHub (Apr 7, 2026):
@binwiederhier
I believe this issue deals with when on mobile connection. (I tired to follow the conversation above but it was over my head)
I am using stock android (I believe others are the same in this thread) and I'm seeing high battery usage.
On wifi on my local network it is less than 1% (doesn't even show up)
On a VPN (wireguard instance) on mobile data, it sky rockets. Half way through my day Ntfy was at 60% battery usage.
On VPN on WiFi it is completely fine, less than 1%.
My temp solution was to split tunnel wireguard connection where Ntfy was excluded from the tunnel. That way ntfy didn't keep a constant connection and the battery usage was low. When I'm back on Wi-Fi on my local network, I would get all the messages (since it was cached on the Ntfy server)
But of course the best case situation would be to get messages when I'm on mobile network
Not sure if this helps but maybe https://github.com/binwiederhier/ntfy/issues/358 would solve this issue? Using polling instead of a constant connection. I believe iOS implements this?