Android · Apache 2.0 · v3.10.0
An open-source Android app that runs every check from the phone in your pocket.
Android 8.0 and up On F-Droid, not on Play
Checkout API
https://api.example.com/health
Checkout API is down
Connection refused · down for 22m
Example readout, replayed 60 checks · 5 min cadence
The problem
An ordinary alert
Monitoring service · 03:04
api.example.com is not responding
Tap to open the dashboard
An urgent Nightbell monitor
Nightbell · ongoing
Checkout API is down
Connection refused · down for 22m
Checking a URL has been a solved problem for twenty years. The hard part is the last ten centimetres, between a server that knows and a person who is asleep.
I kept missing outages because ordinary monitoring notifications behaved like everything else in the shade. The services I tried either wanted a subscription before they would text me, or sent something that looked exactly like a marketing email and got swiped away with one. By the time I noticed, the interesting part of the incident was over.
The hard part is alerting without crying wolf. An outage on an urgent monitor is not a line in the shade. It behaves like an incoming call, and everything else in the app exists to earn the right to do that.
| Aspect | Hosted service like UptimeRobot | Self-hosted like Uptime Kuma | Nightbell on your own phone |
|---|---|---|---|
| Infrastructure | Theirs. Nothing to run. | A box, a container, a certificate, and monitoring for the monitor. | The phone you already carry. |
| Account | Required. | Usually required, at least locally. | None. There is nothing to sign up to. |
| Where tokens sit | On their servers. | On your server. | On the device, in one JSON document. |
| Paging you | Usually the paid tier. | Yours to build, on top of a push service. | A local alarm, so there is nothing to bill for. |
| At 3am you get | An email or a push notification. | Whatever you wired up. | A full-screen page and an alarm that loops until you acknowledge it. |
| It cannot | Fail quietly. You will get a bill. | Watch itself. | Check while the phone is off, or beat Android's 15 minute background floor without a foreground service. |
Scroll the table sideways for the Nightbell column
How a check runs
Not in the path, and not in the dependency list
What it does not buy you is anonymity from the thing you are watching. Your service sees the request and the IP it came from, exactly as it would for any other client on your network. That is what a check is. Routing a monitor through your own proxy is the one thing that changes it, and only for that monitor.
A status or request monitor is an OkHttp call from your phone to the host you typed in. A page-element monitor loads the page in an offscreen WebView on the same phone and reads the DOM nodes you picked by tapping them. There is no relay, no queue and no worker somewhere else, because there is nowhere else. The one exception is a hop you set up yourself: a monitor can be routed through a SOCKS5 proxy running on your own device, which is how a Tor or I2P hidden service gets checked. It goes where you point it and nowhere else, and it is off until you turn it on.
Everything the app knows lives in one JSON document in DataStore: your monitors, their headers and bodies, their sample history and your settings. Backup and transfer writes that document through the Storage Access Framework, which is why Nightbell asks for no storage permission and why you choose where the file goes. Nothing is uploaded, and there is no import path that could reach anything you did not hand it.
It buys you this: an API token in a monitor's headers is on your phone and on your server, and nowhere in between. No third party can leak it, subpoena it, or change its terms of service. There is no analytics library and no crash reporter in the dependency list, and site icons are fetched from the monitored origin itself rather than through an icon proxy.
Two hosts get contacted that you did not choose. The connectivity reference, which you can repoint or switch off. And nightbell.app, every six hours, for the current version number: that one is counted, and what the count is allowed to know is a date, a status and which version asked. Not an address, not an identifier, not a hash standing in for one. It is the difference between knowing that four hundred copies of this are running and knowing anything at all about the four hundred people running them, and only the first of those is any of my business.
It does not buy you anonymity from the thing you are watching. Your service sees the request and the IP it came from, exactly as it would for any other client on your network. That is what a check is.
Three kinds of check
The cheap one
Hit a URL, assert on the status code. Four modes, because "is it up" means different things to a health endpoint and to a page that is allowed to redirect.
exact code any 2xx a range any response at all Cheapest check in the app. A connection refused has no status code and no round trip, so it reports no response and no latency rather than inventing a zero.
The precise one
Choose the method, set headers, send a body with its content type, then assert on what comes back. Six body assertions, and JSON paths that understand nesting and array indices.
GET POST PUT PATCH DELETE HEAD contains does not contain exactly equals matches regex JSON field equals JSON field exists data.items[0].state This is the one that catches a deploy that returns 200 and an empty payload, which is the outage a status check is blind to.
The expensive one
Loads the real page in an embedded WebView and watches DOM nodes you picked by tapping them. Each node carries its own expectation and an optional nickname, and the alert names the one that broke.
element exists element is gone text equals text contains text unchanged attribute equals Every node resolves against one page load, so watching six costs about what watching one costs. The expensive part is booting the WebView, not the assertions. Selectors are re-resolved in a fixed order, id first, then a stable data attribute, then the shortest unique CSS path, then XPath, then a text fingerprint, so a cosmetic markup change degrades instead of paging you at 4am about a renamed class.
Adding a monitor
Step 1 of 4
Status check, request and response, or page element. This is the only choice that changes the rest of the wizard.
What step 1 sets: status checkrequest and responsepage element
Step 2 of 4
The URL, and for a request monitor the method, headers and body. For a page monitor this is where the live preview opens and you tap the nodes you care about.
What step 2 sets: nameurlmethodheadersbodytest now
Step 3 of 4
What healthy means. A status mode, a body assertion, or one expectation per watched element. Test now runs the whole thing once, there and then, before you commit to it.
What step 3 sets: status modeexpected codebody assertiontest now
Step 4 of 4
How often, how long to wait for an answer, and whether this monitor is urgent. Also the latency budget, above which a successful but slow answer counts as degraded rather than down.
What step 4 sets: intervaltimeoutfollow redirectslatency budgeturgent
Nothing here is locked in. Every field is editable from the monitor's detail screen afterwards, and Test now runs the whole check once before you commit to it.
Urgent alerts
Urgent is a per-monitor switch for the things you cannot afford to sleep through. It is the only part of the app that is allowed to be loud, and it is deliberately hard to ignore.
01 The check fails
The failure threshold is met, so this is an outage and not a blip. The card goes red, the banner at the top of the list counts it, and the sparkline keeps the wall of refused connections where you can see it.
02 The page arrives
One notification, on a dedicated alarm channel that bypasses Do Not Disturb. It is marked ongoing, so there is no swipe that dismisses it, and if full-screen alerts are granted it wakes the screen rather than waiting politely on the lockscreen. It comes back every five minutes until you deal with it.
03 You decide one thing
Ack silences this outage and nothing else. Re-check runs the check again right now. Mute buys an hour. The monitor stays red until it is not, and recovery re-arms the loop so the next outage shouts again.
Acknowledging stops the repeats for that outage and nothing else. The monitor stays red, the ordinary down notification stays where it was, and recovery re-arms the loop so the next outage shouts again. Urgent overrides cooldown and the repeat toggle, because that is the point, but it still honours the master switch, the per-monitor switch, mute and the failure threshold. It means "do not let me miss this", not "ignore everything I configured".
What Android allows
Android will happily let an app think it is alerting you while delivering nothing. This is the part most phone monitoring apps skip, so it is worth being specific about.
Getting it
Latest release
v3.10.0
F-Droid is the only store Nightbell is listed in. There is no Play listing and no other store anywhere. If you find one, it is not mine.
F-Droid rebuilds Nightbell from this source and publishes it only when their output matches the APK above byte for byte, so both downloads carry the same signature and either one updates the other.
# download the APK from the release above, then
adb install -r Nightbell-3.10.0-release.apkCheck what you downloaded
Signed with my key, not Google's, so Play Protect asks once. The certificate number is what says the next version came from the same person.
Android refuses an update signed by a different key, which is what makes the certificate number above worth checking before you trust an APK you did not get from the link on this page.
Anything from 2.0.0 onward updates in place and keeps your monitors. 1.x used a different application id, so the only route across is the JSON export in Settings. Building it yourself needs JDK 17 and an Android SDK with API 36; the commands are in the README.
Answers
No. The checks run on the phone, so a phone that is off, out of signal or in flight mode is a monitor that is not checking. That is the honest cost of having no server. If you need something watching while the phone is in a drawer, you need a machine that stays awake, and Nightbell is the wrong tool.
Only in strict mode. Android’s PeriodicWorkRequest has a hard 15 minute minimum and WorkManager silently clamps anything shorter, so Nightbell clamps it visibly instead and says so in Settings under Checker health. Turning on strict foreground monitoring runs a foreground service that keeps your interval exactly, down to about 15 seconds. It costs a permanent notification and real battery, which is Android’s price for a real cadence and not a design choice.
Yes, since 13 August 2026, and that is the install worth taking because it is the only one that updates itself. It is also a reproducible build: F-Droid compiles Nightbell from this source on their own machines, compares the result against the APK attached to the GitHub release, and publishes mine only because the two match byte for byte. So the F-Droid download and the direct download carry the same signature, which means either one updates the other and you can move between them without uninstalling and losing your monitors. IzzyOnDroid is a separate repository and Nightbell is not in it.
There is no Play listing, and F-Droid covers the reason most people want one: a store client that installs it and keeps it updated. What keeps it off Play is the foreground service, which declares specialUse rather than dataSync, because dataSync is capped at six hours a day from API 34 and that cap would quietly break the one guarantee strict mode exists to make. Shipping it through Play review would mean justifying the subtype. Neither F-Droid nor a direct APK is affected, and both are signed with my own key, so a direct install makes Play Protect ask you to confirm the first time.
Three things, and this answer used to say two, which was wrong for as long as the app has had an update check. First, the check itself, to the service you pointed it at. Second, a connectivity probe to a reference endpoint, so losing signal in a car park is not reported as every service going down at once: an empty 204 carrying nothing about you, pointed at GrapheneOS rather than an advertising company by default, repointable at your own always-up host, and switchable off in Settings under Checks. Third, once every six hours, the version check. It reads a small file from nightbell.app and says which version it is running, and I count those requests, because it is the only way to find out how many copies of this app exist. The log line holds a timestamp, a status and that version string. It holds no address, no identifier and no hash of either, so nothing in it can be tied to a phone or joined up across two days, and there is no per install id anywhere in the app to log even if I wanted one. Turn it off with "Tell me about new versions" in Settings, or leave it on and point it at GitHub if you would rather a stranger got the request. Beyond those three, nothing: no analytics library and no crash reporter in the dependency list, a permission list short enough to read in one go, and site icons fetched from the monitored origin rather than through an icon proxy. Your service sees the request and your IP, the same as any other client on your network would. What never happens is anybody seeing your tokens, your URLs or your uptime history.
Yes. Cleartext traffic is allowed on purpose, so a box on your LAN answering on http:// is a valid target. The catch is the same one everywhere else: the check comes from the phone, so the phone has to be able to reach the host. A monitor on a LAN address stops passing the moment you leave the house, which is a true fact about your network rather than a bug.
Anything from 3.0.1 onward installs over the top and keeps your monitors, history and settings. 3.0.0 is the exception: 3.0.1 is signed with a new key, because the old certificate’s subject still carried the previous name and a subject cannot be edited, so a 3.0.0 install has to be uninstalled rather than updated. Coming from Pulse 2.x is different again: 3.0.0 renamed the app and moved its application id, which Android treats as a different app entirely, so it installs beside the old one with an empty data directory rather than upgrading it. The route across is Settings, Backup and transfer in 2.4.3, then import on the new install. Export before uninstalling anything, because once the old app is gone so is its data. Placed widgets and your notification channel settings do not come across either.
Both are better than Nightbell at being a monitoring service: they keep watching when your phone is in a drawer, they hold years of history, they have status pages. Nightbell is not trying to win that. It is trying to be the thing that wakes you at 3am without a subscription, a server or an account, by running on hardware you already carry and paging you with a local alarm instead of a push notification. If you already run Uptime Kuma, Nightbell is a reasonable pager to put in front of it.
Once you grant Do Not Disturb access, yes: urgent alerts go to a dedicated DND bypassing alarm channel. One thing to know first, because it is the current known bug rather than a feature: quiet hours still suppress urgent pages unless you turn on the bypass. That default is wrong and is the next thing on my list, with a migration rather than a flipped constant.
With the default WorkManager scheduling, close to nothing. Strict foreground monitoring costs real battery, because it wakes for every due check instead of letting Android batch them, and it holds a permanent notification while it does. An unacknowledged urgent outage starts that same service on its own regardless of the setting, and stops it the moment you acknowledge or the monitor recovers.
Apache 2.0, the whole thing, source included. No paid tier, no account, no upsell, nothing to cancel. Same licence as everything it depends on, so forking it or lifting a piece of it is straightforward. Keep the notice and say what you changed.