Nightbell

Releases

• Nov 3, 2026 3.20.0
  A host can now be watched as well as a service. Two new monitor kinds, **Ping** and **TCP port**, take an IPv4 or IPv6 address or a name and need no root. Asked for in #21. **Ping** sends 1 to 10 echo requests per check and shows the fastest, average and slowest reply and the packet loss. Every reply back is up, some lost is degraded, none back is down. **TCP port** connects to one port and hangs up. Refused, timed out and no route each get their own message. **This host:** put both on the same host and the monitor's screen reads them together, so you can tell the network from the service. Both kinds also list their recent outages and how long each lasted. **Passes before all-clear** works on every kind. Above one, an outage stands until that many checks pass in a row, so a flapping host no longer pages, clears and pages again. The default is 1, as before.

  More…

  Driven on the emulator against loopback, 1.1.1.1 and a server of mine. Packet loss was shown with faked replies. Ping on a real phone is the least proven part: if a phone refuses the socket, the monitor says so instead of calling the host down.
• Oct 23, 2026 3.19.0
  A failing part of a **Health endpoint** report can now be marked as expected. A staging API that is down for a reason used to page on every check, and the only ways to stop it, mute or switching alerts off, also hid the next real change. Now the marked part is left out of the verdict while it keeps the status it had when you marked it, and nothing pages. The first report that shows it any other way, up included, drops the mark, so the next outage pages like any other. **Where it is:** Mark expected on the part's row on the monitor's screen, or in the sheet that opens when you tap the part. It comes with an undo, and Page me again takes it back later. **What still pages:** any other part that fails. A stale report, a status word Nightbell does not know, or a report that says down while no part says worse than degraded also stays down, whatever you have marked, because no part explains it. Only the status is compared, never the message, so a staging report whose message carries a latency or a count stays quiet. **The monitor's screen:** the verdict is one word with the reason under it and the parts counted in a strip. Below it the parts sit in three groups: Needs you, Expected, not paging, and Healthy, as names. A part's rules and log open in a sheet instead of expanding in the list. The last 24 checks replace the response time chart, because for a report the question is whether it passed, not how long it took. **Sign-in:** a monitor whose single sign-on session had once ended kept saying "Not checking" after you signed in again, even while its checks passed. 3.18.0 never cleared that state. The next check that gets through now clears it and takes the reminder notification down.

  More…

  **Webhooks** are not told when you mark a part. One that saw the outage gets its recovery on the next check. Driven on the emulator against a local server: marking, a still-failing part staying quiet, another part and the next outage paging, undo, and an old sign-in problem clearing. The sign-in fix through a real provider is covered by unit tests, not yet by a device test against one.
• Oct 11, 2026 3.18.0
  A new monitor kind, **Health endpoint**, reads a report your service writes about itself. A status code only says the server answered. This says which part is in trouble, the rule that decided it with the value it measured, and what the service saw along the way. The overall verdict pages you; the rest is what you read when it does. **The format** is one JSON document, described in [docs/health-format.md](https://github.com/riveerxd/nightbell/blob/master/docs/health-format.md) with a JSON Schema beside it and a drop-in writer for ASP.NET Core. The body decides, not the status code, so a `503` carrying a report is read as that report. An existing ASP.NET health check that answers plain `Healthy`, `Degraded` or `Unhealthy` works before you write any JSON. **Signing in:** the endpoint stays behind whatever protects the rest of your API. Nightbell signs in the way your own clients do: a fixed header, basic auth, or single sign-on through your web app, a username and password, a service account or a pasted refresh token. Tokens and secrets are encrypted on the phone and never go into a backup. When you type the address, Nightbell tries it once without signing in, so setup can tell you whether it needs a sign-in at all. **What it claims, and what it does not:** | Situation | Card | Pages | | --- | --- | --- |

  More…

  | Nightbell's own sign-in ended, or its password was refused | Not checking · Sign in needed | No, a reminder once a day | | The sign-in server cannot be reached | Down, "Sign-in server unreachable" | Yes | | A fresh token and the API still refuses it | Down | Yes | **On the detail screen** the Components card is a bar of down, degraded and up parts, then one row per part. Only the worst part opens on its own, with its rules and its log; the rest are one tap away. **Also in this release:** a store this version cannot read, such as one written by a newer version, is kept instead of having an empty one written over it, so the monitors in it are still there for a version that can read them. The README now lists every monitor kind, Prometheus included.
• Oct 10, 2026 3.17.0
  Failures before an alert are now confirmed 30 seconds apart, inside the same background run that saw the first one, instead of one scheduled check apart. A threshold of three used to mean half an hour of a site being down before the phone said anything. Now it is about a minute. | Failures before alerting | Before, at best | Now | | --- | --- | --- | | 2 | 15 min | 30 s | | 3 | 30 min | 1 min | | 5 | 1 h | 2 min | | 10 | 2 h 15 min | 4 min 30 s | **Where it is:** Retry right away, under Escalation next to Failures before alerting, both in Settings, Alerts and in a monitor's own alert settings. It only shows when the threshold is above one, because a single failure already alerts. It is on by default, including for monitors set up before this version.

  More…

  **What a failing card says:** "1 of 3 failures before it alerts", so a red card that has not paged you yet tells you why. **When it does not retry:** the phone is offline, monitoring is paused, the monitor is muted or alerts are switched off, since nothing would be posted at the end of it. A check that failed because the phone lost signal is not counted as a failure. GitHub repository monitors stay on their schedule, because they share a rate limit with everything else on the token. **When the phone is asleep:** Android decides, not Nightbell. Measured on Android 14 with the phone forced into deep Doze: with battery optimisation on, Android stops the background run the moment the phone goes idle and cuts its network, so the remaining retries wait for the next scheduled check, which is what happened before this release. With Nightbell exempt, the same run kept retrying 30 seconds apart through deep idle and paged on time. The exemption is one button under Settings, Checks, Checker health. In strict mode the service loop runs the retries itself. Reported in #20.
• Oct 5, 2026 3.15.0
  Page element monitors now use a small fraction of the mobile data they did. They load from cache, skip fonts, video and trackers, and stop as soon as the element is found, while still asking the server for the page on every check. Settings shows what your monitors cost a month with the **data saver** on and off, measured from their own checks. It started with ten page monitors on a fifteen minute interval costing one phone 7.14 GB of mobile data in a month. The WebView ran with its cache off, so every check downloaded the whole site again. Measured per check on five of those sites, with the selectors they really watch: | Site | Before | Data saver | | --- | --- | --- | | nightbell.app | 162 KB | 1.7 KB | | riveer.cz | 219 KB | 4.8 KB | | videre.cz | 344 KB | 2.6 KB | | clinicm.cz | 144 KB | 7.9 KB |

  More…

  | flirtycall.me | 1.87 MB | 182 KB | **What still happens on every check:** the page itself is requested from the server, with a header that tells the browser to confirm it rather than trust a stored copy. A server that is down still fails the check exactly as before. **What changed:** scripts and stylesheets that have not changed come from the phone's cache. Fonts, video, analytics and ad tags are not fetched, because none of them can change whether an element is there or visible. The page is read while it is still loading, and once every element is found and passing, the rest of the load is cancelled. An element that is missing or failing gets the full wait it always had, so no check became easier to pass. **The trade:** a script or stylesheet that breaks without changing its filename keeps working from the cache until that monitor's next cold load, which happens once a day. Load times on page monitors also read lower, because they now measure a returning visitor rather than a first one. If either matters for a monitor, turn the saver off under Settings, Checks. The switch shows what that costs. Also in this release: a repository monitor that counts downloads reads the counts at most once an hour while the saver is on. That call cannot be answered from cache, because the counts change on their own.
• Sep 27, 2026 3.14.0
  A GitHub repository monitor can now count how many times the release files have been downloaded, on the newest release and as a running total across every release. Turn it on under **Downloads** when you add or edit one. It costs no extra request. The counts live inside the release list the monitor was already reading, so the call is the same one asked for in full. That does make it a bigger response, roughly a quarter of a megabyte against five kilobytes, which is what the refresh setting is for: every check by default, or hourly or daily on a metered connection. **Which files count is up to you.** A project that publishes an APK beside a signature and a checksum can count the APKs alone. Because the filename carries the version, every release of the same file adds up under one line rather than thirty separate ones: `Nightbell-3.13.0-release.apk` and all its predecessors read as `nightbell-*-release.apk`. When a repository only ships one kind of file the app says so instead of offering a filter that could not change the answer. You can be told when the count moves, on any increase or only at round numbers, or hold it back to one line an hour or a day. Nothing about a download wakes the phone. **What the number is**, stated on the card rather than left to be assumed: GitHub counts requests for the file, not people. Mirrors, build servers and crawlers that fetch a whole release are all in it, and it is not updated the moment somebody downloads. Past three hundred releases the total is shown as a floor with the number of releases it covers, rather than quietly undercounting.

  More…

  Also in this release: releases, open issues and forks wear GitHub's own marks. A release used to wear the arrow that means a file arrives on this device, which is the mark a download count needs, and an open issue wore the warning triangle, which claims a fault where there is none. Requested as issue #18.
• Sep 20, 2026 3.13.0
  Monitors are rearranged by holding a card and dragging it. No handle to find and no mode to turn on first: hold, move, let go, and the dashboard keeps that order from then on instead of re-ranking it by severity on the next check. A hold you release without moving still starts a selection, exactly as before. Adding a monitor no longer asks for a scheme. Type `status.example.com` and the URL field finishes it as https when you leave the field, saying that it did; type `http://` yourself and it is left alone. A `.onion` or `.i2p` address completes to http, because no CA issues certificates for those. Nothing turns red while you are still typing the host. The SOCKS5 switch and the certificate rule now appear once, on the Target step, rather than on every screen of the wizard. The later steps show what the route and the trust setting are, and tap through to change them. Also fixed: - a dragged card that appeared to swap twice before settling, and a drop that put the card down in a single cut rather than travelling the last few pixels - the "Monitor not found" warning that flashed when you deleted a monitor from its own screen

  More…

  - an imported backup whose monitor order was restored and then immediately sorted away, which made a backup look like it had lost the arrangement - entrance animations that played as each row was scrolled into view, so every screenful after the first arrived animating Reported as issue #16.
• Sep 19, 2026 3.12.0
• Sep 18, 2026 3.11.0
• Sep 14, 2026 3.10.0
• Sep 2, 2026 3.7.0
• Aug 31, 2026 3.6.0
• Aug 29, 2026 3.5.0
• Aug 27, 2026 3.1.1
• Aug 13, 2026 3.0.5