mirror of
https://github.com/binwiederhier/ntfy.git
synced 2026-05-09 16:35:53 +02:00
[GH-ISSUE #1101] Android app should alert when connection is lost and it's attempting to reconnect to the server #772
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#772
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 @milosivanovic on GitHub (Apr 29, 2024).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1101
💡 Idea
I have experienced some rare scenarios (e.g. on in-flight wifi or in places where mobile coverage is very spotty) that the ntfy mobile app client (specifically Android) may struggle to regain a websocket connection with the server. When this happens, there's no alert in the app that the connection to the server was dropped and that new notifications won't arrive. The only way to know is if you open the ntfy app perchance and notice the subscription subtext silently added a status to the notification count, showing "99 notifications, reconnecting..." instead of just "99 notifications".
The scenario doesn't actually have to be rare or unusual - other ways this could happen is if the ntfy server does gown (power outage, network issues) or the user's Internet connection goes down, or any combination of network reasons that might interrupt the websocket connection in the mobile app. Connections drop for normal reasons too (e.g. when the phone is switching from cellular to wifi and vice-versa) and in these cases the client is expected to reconnect without issue within a quick timeframe, but as I've experienced, it's possible that it may take an extended time to regain connectivity, or may get stuck. During this time, critical notifications would be missed until the connection is re-established. The user would have no idea.
Because some drops/reconnects are part of the normal lifecycle, I don't think a blanket solution to alert every disconnection is the right one. But if a connection attempt takes longer than some set interval, like 1 minute, the app should emit a notification and/or persistent notification that it's currently attempting to regain connectivity. This interval and whether it's a persistent notification or not could be a setting for the user to decide on.
Having this alert would give users peace of mind that they'll be made aware if the connection goes down and can monitor or take action to restore it.
💻 Target components
Android/iOS app
@windowsrefund commented on GitHub (May 9, 2024):
This would be useful for those of us running the server as well. I recently had an issue with nginx crashing which meant no traffic was able to get to ntfy. Having the client (already running on my phone) generate a notification when it can't connect to the server (after a reasonable number of retries) would be the low-hanging fruit solution here.
@OPerepadia commented on GitHub (Aug 25, 2024):
If this feature is implemented, I might give ntfy another try, because the lack of connection status reporting has been my main issue with it.
For now, I've switched to using Gotify, and while it doesn't alert when server not reachable, at least it updates the persistent notification, so I don't have to open the app to check connection status. Here is how it looks like:
@gitsomejorge commented on GitHub (Jan 6, 2025):
If the app is already aware the connection is loss and it is trying to reconnect, then maybe It could alert on just those two.
@binwiederhier commented on GitHub (Feb 1, 2026):
This has been partially implemented: There is now a connection error dialog: https://docs.ntfy.sh/subscribe/phone/#troubleshooting
I'll add it to the "Listening for incoming connections ..." notification as well
@binwiederhier commented on GitHub (Feb 2, 2026):
Done. Will be in 1.23.x
@JeftaDirksen commented on GitHub (Feb 26, 2026):
I'm sorry to say but this "enhancement" make the app unusable, the constant notifications of "Listening for incoming notifications" is just too annoying. There really should be an option to turn off these notifications. Or it shouldn't display them when I roam between Wifi / cellular connections.
@binwiederhier commented on GitHub (Feb 26, 2026):
You can turn this off https://docs.ntfy.sh/subscribe/phone/#instant-delivery
@JeftaDirksen commented on GitHub (Feb 26, 2026):
Oh wow thank you, I did look/search for the option to turn this off but wasn't able to find it, but now I got it, thanks.
And for others to find this (when not having the notification):
(Samsung:) Settings → Notifications → App notifications → ntfy → Notification categories → Subscription Service
@milosivanovic commented on GitHub (Feb 26, 2026):
@binwiederhier Thanks again for taking the time to make these changes. I just went through and tested this out. While the changes are an improvement, I was hoping this part in my original report would be considered more closely:
Maybe I should have been more clear with how I worded it.
As it stands now, the persistent notification that appears when a topic connects/reconnects does provide visibility of the status, but it doesn't help if the user is not watching/paying attention to their phone's notifications, which kind of defeats the purpose. (The user could make the persistent notification non-silent in the Android notification settings, but then this non-silent alert would be triggred every time the persistent notification comes on, which is every single time it reconnects. Because Android (and any other OS) will reset all TCP connections used by an app on an interface that no longer exists (e.g. when switching from wifi to cellular), reconnections are a normal and expected part of the ntfy.sh Android app's lifecycle, so these notifications would overwhelm the user.
I mentioned...
...for this exact reason.
I believe a much more useful and less intrusive implementation would be to alert the user if something is abnormal (or in other words, unhealthy). For an alerting system like ntfy.sh, it makes much more business sense to emit a non-silent Android alert if X amount of time passed since the topic's last WebSocket PONG (meaning the topic is unhealthy), or as a more simple implementation: if X seconds passed since it found out it became disconnected from that topic. I would suggest a separate notification category called Unhealthy Topics which non-silently emits a notification only if a given topic has been unreachable for X seconds, where X can ideally be configured in the settings.
For the exact reason @JMDirksen specified, alerting every topic connect/disconnect is not exactly what I was striving for with this feature request. If during normal use the connection is dropped (e.g. when switching from wifi to mobile) and it reconnects within a few seconds, then that's not something worth alerting. If the topic connection is consistently down / consistently retrying to connect but failing (e.g. for 30 seconds), it would be a business need for ntfy.sh to non-silently alert the user to the fact that it is unable to perform its duties.
@Quantum-Future commented on GitHub (Feb 28, 2026):
Sometimes I'm offline for a while, and I know I won't be receiving new messages. The default connection retry is fixed at 44 or 45 seconds. It would be good if I can set the amount of time between retries to any value, for example 1 min, 3, 10, 30, 60min, etc.