[GH-ISSUE #1101] Android app should alert when connection is lost and it's attempting to reconnect to the server #772

Closed
opened 2026-05-07 00:27:21 +02:00 by BreizhHardware · 10 comments

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

Originally created by @milosivanovic on GitHub (Apr 29, 2024). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/1101 :bulb: **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. :computer: **Target components** Android/iOS app
BreizhHardware 2026-05-07 00:27:21 +02:00
Author
Owner

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

<!-- gh-comment-id:2101816693 --> @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.
Author
Owner

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

Screenshot_20240825-172508

<!-- gh-comment-id:2308879996 --> @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: ![Screenshot_20240825-172508](https://github.com/user-attachments/assets/d4f4db1e-0ee1-492f-b3bd-5831f67c212b)
Author
Owner

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

<!-- gh-comment-id:2572189354 --> @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.
Author
Owner

@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

<!-- gh-comment-id:3832213802 --> @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
Author
Owner

@binwiederhier commented on GitHub (Feb 2, 2026):

Done. Will be in 1.23.x

Image
<!-- gh-comment-id:3832488781 --> @binwiederhier commented on GitHub (Feb 2, 2026): Done. Will be in 1.23.x <img width="696" height="252" alt="Image" src="https://github.com/user-attachments/assets/6ac6fb49-5b24-4d06-a72e-5c7cf4ef91e9" />
Author
Owner

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

<!-- gh-comment-id:3966250030 --> @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.
Author
Owner

@binwiederhier commented on GitHub (Feb 26, 2026):

You can turn this off https://docs.ntfy.sh/subscribe/phone/#instant-delivery

<!-- gh-comment-id:3966274516 --> @binwiederhier commented on GitHub (Feb 26, 2026): You can turn this off https://docs.ntfy.sh/subscribe/phone/#instant-delivery
Author
Owner

@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

<!-- gh-comment-id:3966334447 --> @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 &rarr; Notifications &rarr; App notifications &rarr; ntfy &rarr; Notification categories &rarr; Subscription Service
Author
Owner

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

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.

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...

I don't think a blanket solution to alert every disconnection is the right one

...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.

<!-- gh-comment-id:3968574845 --> @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: > 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. 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... > I don't think a blanket solution to alert every disconnection is the right one ...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.
Author
Owner

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

<!-- gh-comment-id:3976524645 --> @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.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/ntfy#772
No description provided.