OpenKuma

app.openkuma
by Zapstore _@zapstore.dev

Republished from GitHub / F-Droid by the Zapstore main account.

First release: Aug 2, 2026, 4 total releases.

Most recent release: Sep 21, 2026.

Repo

Appears in 0 app stacks.

0 sats / 0 zaps received in the past year.

Sats Received

Underlying data available via MCP: app_zaps, app_releases.

Zap Count

Underlying data available via MCP: app_zaps, app_releases.

Releases

  • Sep 21, 2026 0.4.0
    ### Added - **Tap the Up, Down or Pending tile to show only the monitors in that status.** Tap it again to see the whole list, or tap another tile to switch. The selected tile gets a border in its own color. The status filter works together with search and *Favorites only* rather than replacing them, and behaves the same with several servers aggregated. It resets when the app restarts. ### Changed - **Dashboard figures no longer count group monitors.** A group is a heading over its monitors, not a row of its own, but it was counted like one: a group with a monitor down is itself down, so one outage showed as two on the Down tile. Up, Down, Pending, active incidents and expiring certificates now leave groups out, and the home-screen widget counts the same way. Some numbers may be lower after updating. - When a status filter hides every monitor, the list now says that nothing matches the current filters, instead of saying there are no monitors.
  • Sep 18, 2026 0.3.0
    ### Added - **Several Uptime Kuma servers at once**, under *Settings → Servers → Aggregate servers*. Off by default. With it on, every server carries a checkbox, and the monitors, events and certificates of the ticked ones are shown in a single list, each row tagged with the server it came from. - **Real-time mode then holds one live connection per ticked server**, not one connection covering them all: aggregating duplicates the connection path rather than sharing it, so the battery and the data that mode costs are counted per ticked server. The permanent notification follows the selection instead of staying on the one the service started with. - The periodic background check covers the ticked servers too, rather than only the one server you last had open. A run that cannot get through all of them in time resumes at the next one it had not reached, so no server sits at the back of the list and is never checked.
  • Sep 12, 2026 0.2.0
    **Instant alerts through UnifiedPush.** With a UnifiedPush app installed (ntfy, NextPush, Sunup and others), OpenKuma is woken the moment a monitor changes state, with no connection held open and no permanent notification. There is no Google and no FCM involved, and the wake-up itself is never read: the app asks your own server, over your own session, what changed. Someone who learns the address can at most make the app refresh, never fabricate an alert. Uptime Kuma has no per-device subscription API and OpenKuma is read-only, so the address cannot be registered for you. Settings hands you one address per server, to paste into an Uptime Kuma *Webhook* notification. Set the webhook's **Request Body** to **Custom Body** with `{"wake":1}`. Left on the default `application/json`, every alert publishes fields of the monitor it concerns, its URL, hostname, description and database query among them, to an address anyone who knows can read. The card in Settings names the stage of the chain that is broken when one is, including two failures that were invisible before: an address that changed, leaving the one pasted into Uptime Kuma dead, and wake-ups arriving while the app can no longer sign in. **Real-time mode now runs a background check every 30 minutes** behind its live connection. It scheduled none at all before, so a connection killed by a battery manager, a network change or an OEM's idea of housekeeping meant nothing arrived again, ever, while the permanent notification said otherwise. **Fixed.** Notifications from two servers could overwrite each other when both had a monitor with the same id. A background sync that could not sign in was indistinguishable from one that found nothing to report, so an expired session failed silently every 30 minutes, for ever. A sync for one server could overwrite the version and uptime block shown for another. Two syncs running at once could announce the same change twice. A failed sync leaked its event collector. And a status change could be persisted and never announced, if the process died between the cache write and the diff that produces the notification.
    More…
    This release adds no Android permission. The UnifiedPush connector is Apache-2.0, and every library it pulls in is free software.
  • Aug 2, 2026 0.1.4
    ### Fixed - **OpenKuma closed itself instantly when the server URL had no `https://` in front**, with no error and nothing kept: Socket.IO throws on a scheme-less URL and the connection was built where nothing caught it, so the app died back to the launcher and the whole form had to be retyped. The scheme is now filled in for you (`https://` unless you write `http://` yourself), an address that still can't be read says so, and a failed sign-in can no longer take the app down. - **A server that accepted the connection and then went silent left the Connect button spinning forever.** Signing in now gives up after 30 seconds and explains what to check (reachability, WebSocket support on the reverse proxy). - **The dashboard claimed "No monitors yet" with 0/0/0 counters while it was still loading.** Uptime Kuma sends the whole monitor list and its history right after login, which takes minutes on a large instance — indistinguishable from a broken connection. It now shows a loading state until the first monitor list arrives. Thanks to the reporter on Reddit for a precise bug report.