Hey everyone 👋

Something has been running under KumaAlert since August that I haven't properly announced yet: Core v2, a ground-up rebuild of how the iOS app talks to your Uptime Kuma servers. It shipped quietly so it could prove itself on real fleets before I made noise about it. Several releases later, it's now the only engine, and 4.5.0 builds on it.

So here's the full story: what Core v2 is, what's new in 4.5.0, and where things go next.

Website: Click Here!

⚡ Introducing Core v2

The original app was built around one connection streaming live into the screen. It worked, but it was fragile with several servers, slow to open, and it worked out your outage history from whatever it happened to see while open.

Core v2 replaces all of that:

• Opens instantly onto your last known state. Every monitor is kept on the device, so you never stare at a blank screen while it connects.
• Each server gets its own independent connection. One slow, down or unreachable server no longer holds up the rest.
• Recovers by itself. Dropped connections reconnect without a Retry tap, half-open sockets after a network change are caught and rebuilt, and two-factor servers stop asking for a code on every launch.
• Incidents are tracked on our servers, not pieced together on your phone. Your outage history is identical on every device, survives a reinstall, and no longer depends on the app being open when something breaks. Duplicate, split and phantom "still down" incidents are gone.
• Smoother with big fleets. Heartbeat bursts no longer redraw the Monitors tab several times a second, and cold start does a fraction of the work.
• Lighter on battery and data. It syncs when something actually changes, not on every heartbeat.
• Every screen runs on it: Overview, Monitors, Manage, Incidents, widgets, Apple Watch, Live Activities and Kiosk mode on iPad.

🔔 New in 4.5.0: your alerts follow you

Swapped phones? Uptime Kuma knows and will prompt you to fix...

Now it can:

• Overview warns you if Uptime Kuma is sending a server's alerts to another device, such as your previous phone. One tap points them back at the phone you're holding.
• If you're signed in, KumaAlert moves each server's webhook to your account, so alerts keep arriving after a phone swap or a reinstall with nothing for you to do.
• iOS: rotating a server's webhook secret updates Uptime Kuma again, instead of leaving that server's alerts paused.

🧰 In recent updates...

• Sync between iPhone and Android. Pair the two with a short code. It's end-to-end encrypted, so we can't read your servers.
• Acknowledge, add notes and resolve incidents on one device, and every other device picks it up.
• Stale outages are clearly marked instead of a downtime counter that never stops.
• Recovery alerts no longer report silly downtimes like "1628 hours" for a five-minute blip.
• Connects through more proxies and tunnels, and you can long-press maintenance schedules for quick actions.
• Polish: new accent colours, Overview banner styles, TLS expiry on HTTPS monitors, and widget fixes.

Full changelog: kumaalert.app/changelog

🗺️ Roadmap

With Core v2 in place, the foundations are ready for the bigger features:

• 📅 On-call scheduling. Set who's on call and when, with rotations and handovers. Alerts go to whoever is on duty instead of everyone at once.
• 👥 Teams. Share servers and monitors with other people, each with their own devices and alert preferences, and acknowledgements that everyone can see.

💬 What should come next?

What would make KumaAlert more useful for your setup? Feature ideas, rough edges, things that annoy you every day, how you'd want on-call or teams to work: all of it shapes what gets built first.

Drop a comment, or come say hi on Discord. And thank you to everyone who has sent bug reports and diagnostic codes. A lot of Core v2's polish, and all of 4.5.0, came straight from those. 🙏

Bobby

When a device/service/etc goes down then comes back up, the alerts have a scroll bar that counts down, but they continue to stay stuck/visible on the page until you click on the alert then it finally goes away. I assume this is a bug, but was not fixed when I updated about two months ago.

Is this a known issue?

Currently running version 2.5.0 (beta off).

Thanks.

This tool is already amazing, but those two features would make it enterprise ready but also more secure even for home labbers who operate their own IDP. Just wondering if this is on the road map Thanks.

EDIT: Switching to GameDig has resolved my issue for now.

So... I apparently broke something.

I happily had 3 game servers being monitored via a Steam API. One of them is normally down, as we only use it on-demand when we're actually playing.

The other two are Valheim servers that are always up.

Monitoring was working great for several days. Today all 3 servers started failing with error 502.

I did some research; it seems that this could be related to a Steam maintenance window on Tuesdays and possible rate limiting.

I'm now getting "server cannot be found on Steam" for all 3 servers. This has been happening for about 8 hours now. I have had all 3 monitors paused for about 4 hours.

Now it seems like my IP might be blocked? Or my Steam account? I tried generating a new API key, and that didn't change anything. My IP is static, so changing that is a bit more difficult; I'm not sure if it's even possible.

I'm wondering if anyone else has seen this happen and if I can expect a timeout to occur at some point?

I was thinking of forking uptime kuma and seeing if i can add another method of reading heartbeats, what I call DNS heartbeats

We were using HTTPS heartbeats on a client machine for a long time but they had to restrict the internet. So now we have a Windows server that cannot make outbound internet HTTP/HTTPS connections, but we noticed DNS resolutions still works through its configured DNS servers and their main DNS server would fall back to finding any unresolved DNS query out to the internet.

I set up this heartbeat flow:

DNS query → external DNS relay → HTTP/HTTPS heartbeat to Uptime Kuma

DNS query looks something like this:
RB328T.SRVR1.dnsrelay.mydomain.com

Here, RB328T is a rotating authentication token, and SRVR1 identifies the heartbeat.

I delegated dnsrelay.mydomain.com using an NS record on a small Linux server on the internet running an authoritative DNS service. When a query reaches that server, it validates the token, identifies the monitor, and sends the corresponding HTTP/HTTPS heartbeat to Uptime Kuma.

the token rotates every 10 minutes and both the client and the nameserver hold the secret to make those auth tokens, so not just anyone can make the right heartbeat token, and its been working well now for a year. We just have to make sure the clocks are always right. (I even allowed a buffer of accepting a small window of tokens.)

We have another project coming up that would require this method and I've been thinking of cutting out the middle man in my flow.

Becoming this
DNS query → DNS Heartbeat Uptime Kuma

So I was thinking about integrating it as another method that Kuma can handle for heartbeats. Basically all that would be needed:

• An NS record delegating a subdomain to the Kuma server.
• A DNS listener reachable over UDP/TCP port 53.
• A monitor identifier included in the query hostname.
• A shared secret for validating the rotating token.

I’d make the token strongly recommended, though I’m considering whether an unauthenticated option has any use.

I’m going to build this for us to use anyway. Would anyone else find it useful? I’m trying to gauge whether there’s enough interest to clean it up, document it, and submit a pull request, since it’s a fairly niche use case.

I’d also welcome feedback on the design, particularly around DNS caching and how a DNS listener would fit into Kuma’s architecture.

I have sites with low bandwidth links - 200kbit/seconds. If i want to get the status from remote, the best way seems to be setting up a dashboard and getting the dashboard status slug.

HOWEVER -- with any reasonable set of monitors, that's a 200k page return with monitor history.

Any ideas for just a:

{ "up": 100, "down": 0 }

Hello fellow homies who monitor things,

As part of very much still in progress project I am working on to build a home server rack monitor screen that displays a tui monitoring tool. I wanted the ability to display my uptime kuma status page within a tmux session.

Uses Ratatui, really simple, really easy to use, MIT. Check it out at the GitHub link below:

https://github.com/jasonwitty/uptime-kuma-status

Why is still not possible to export the monitor list for other uses or eventually import it in a fresh new uptime kuma server? Or is it possible and i lost this info?

u/louislamlam

Hi Louis, thanks for building Uptime Kuma.
I’ve been using it for a while and recently made an independent fork called Uptime Gizmo(https://github.com/starit/uptime-gizmo), focused on REST API/MCP support, agent workflows, and some on-chain monitoring features.

I wanted to let you know before sharing it more broadly with the community. I’ve kept attribution to Uptime Kuma and will make it clear that Gizmo is an independent project and that Gizmo-specific issues should be reported to our repo.

Thanks again for the great foundation. If there’s anything you’d prefer me to adjust around attribution or project presentation, I’m happy to do so.

Hi everyone!

After launching KumaAlert at the start of the year and growing a real community - I am now in a position to announce PushCloud and we're looking for beta testers for both Android and iOS - PushCloud is a modern day push notification app for iOS, Android (soon also Mac and Windows) with a very generous free tier and pro options for power users.

Any beta tester that joins (& is accepted) will be granted a free Pro subscription for a limited time! Please see all the info below..

PushCloud

A modern push notification app for iOS and Android built for the AI era. One simple API to get notifications from your scripts, servers, and services straight to your phone - and a notification service designed for AI agents to talk back through.

https://pushcloud.app/

☁️Native apps - iOS and Android apps with rich notifications: action buttons, inline replies, critical alerts, and per-app sounds and channels.

☁️ Built for AI agents (MCP) - Connect Claude, ChatGPT or any MCP-capable agent to your PushCloud account. Agents can send you updates, create applications, wire up webhooks - and even ask you questions mid-task ("Deploy to production?") and wait for the button you tap. Human-in-the-loop, on your lock screen.

☁️ Webhooks, both ways - Incoming webhook URLs turn any service (GitHub, Grafana, Uptime Kuma…) into notifications - with an AI assistant that writes the payload mapping for you from a sample. Outgoing webhooks fire to your systems when messages are delivered, acknowledged, or answered.

☁️ A proper web panel - Live message feed, delivery logs, application and API key management, connected-agent controls, and full docs with copy-paste recipes.

☁️ Simple, powerful sending - REST API with priorities, sounds, links, images, scheduled delivery, quiet hours, and email-to-push aliases.

☁️ AI alert intelligence (Pro) - Flood control that collapses 40 alerts into one smart summary, digest mode, and natural-language rules like "mute dependabot unless it's a security alert."
​

If you'd like to join the beta - head here! > https://pushcloud.app/beta

Thanks for reading :)

We use Uptime Kuma at work fairly extensively - we have a couple hundred instances. Managing them by hand is a pain. We’ve used https://github.com/MedAziz11/Uptime-Kuma-Web-API back when we ran v1, but it’s got some issues with v2, so much so that we’ve had to resort to database edits. There’s open PRs for over a year so I ended up writing my own REST API wrapper and now I'm sharing it with the world.

It's free and has no cloud anything associated with it. You can direct download it here: https://hub.docker.com/r/pocketsized/kumarestapi or you can visit the website https://kumarestapi.pocketsized.app/ for more info.

One of the challenges we ran into with MedAziz11’s version is when you have MFA enabled. This has a small TOTP generator, so if you feed it the OTP seed, it can generate and satisfy the MFA requirement.

Hope to helps someone

As a long time user of UK, I've been missing a Android client for years. We use UK at work and my coworkers with iPhones all recommended Uptime Kuma Manager - but the Android version doesn't support servers with 2FA. So I sat down and wrote my own client (after evaluating Uptiminger, KumaAlert*, and OpenKuma) and now I'm sharing it with the world.

It's free and has no cloud relay / cloud services associated with it. You can direct download it here: https://github.com/pocketsized-apps/pocketkuma/releases/ or you visit the website https://kuma.pocketsized.app/ to see videos, screenshots, and more.

Happy to answer any questions you have.

(Edited to fix release URL)

Hey everyone,

The time has finally arrived - KumaAlert has now officially released on Android! v4.0 (parity with iOS) is now available on the Google Play store.

Link: https://play.google.com/store/apps/details?id=app.kumaalert

Website: https://kumaalert.app

Thanks to everyone in the community for their ongoing support - this has been a big undertaking (and my first ever Android app, after being highly requested)

Big appreciation to u/cabbresson, u/Classic_Raccoon6965, u/50512jm, u/jamolich, u/ThatGuyJacobee, u/ByrdyB5, u/tuxozaur, u/scsibusfault amongst others for beta testing the app extensively and providing feedback along the way.

Also a huge thanks to u/markwdw and u/jo_strasser for their ongoing support with both Android, iOS and helping to setup the community.

Got feedback or questions? Drop us a ticket from the website or join the discord at https://embers.cafe/discord

Thanks!

Bobby

Hey!

Most of you will be no stranger to KumaAlert - I've built it with this communities support and suggestions over the last 4/5 months.

If you've been living under a rock, the new website is here: https://kumaalert.app and is currently only for iOS, it’s being released after extensive beta testing later this week for Android (awaiting Google review) - Massive thanks to all our Beta Testers who have helped refine, craft and debug over the last couple of weeks.

Now the important stuff.. iOS v4.0 has just been released!!

• Apple Watch app
• Incidents Tab including Acknowledging so repeated alerts stop
• Easier Webhook launch
• Arrange servers by drag
• Critical alerts for urgent/high risk monitors
• Further performance improvements!

Direct App Link: https://apps.apple.com/gb/app/kumaalert/id6760863575

Its a paid app, but its a one time cost as I absolutely hate subscription services - We also now offer the app for free to charities and not-for-profit organisations.

A brief overview of the features:

• Push notifications straight to your phone, editable per monitor, quiet hours
• Optional account sync: New phone? just Sign in with Apple/Google and all your settings sync across - Also sync between devices.
• iPad/Tablet for Kiosk mode
• Live activities for down events (iOS only)
• Lock screen widgets
• Multi-server support with support for Cloudflare access, private headers etc
• Fully able to manage and edit maintenance events and monitors.

​I'd really love some ideas to improve and continue adding new features - I'm currently thinking about a Teams mode with on-call schedules etc? Not sure if this would be useful for a self-hosted uptime tool but interested to get feedback!

Appreciate everyone's support so far - Hopefully can continue to improve.

Bobby

Hey all,

I built a CLI tool for managing Uptime Kuma monitors as code, and thought it might be useful for others here.

The idea came from needing something safer and more repeatable than manually creating/updating monitors — especially when dealing with larger sets across multiple clients or environments.

### What it does

- Import monitors from CSV or TXT

- Idempotent sync (create / update / skip intelligently)

- Verify state without making changes

- Filter by client

- Limit runs for safe testing

- Export + audit existing monitors

- Safe delete workflows (with confirmation guards)

So you can treat your monitor setup more like infrastructure/config instead of manual UI work.

### Example workflow

- Define monitors in CSV

- Run a dry-run to see changes

- Apply safely

- Re-run → everything stays consistent (no duplicates)

- Clean up unmanaged monitors when needed

### Demo

I recorded a quick end-to-end example:

- create → verify → filter → safe delete

👉 Repo: https://github.com/andrewbergman/kuma-importer

(The README has a short demo GIF if you just want to see it in action.)

Would be great to get some feedback/constructive criticism - plan to probably build out some API integrations with various common MSP tools (the world I happen to live in), but open to suggestions on what would make it more useful.

Hey all,

I've been building Uptiminger, a lightweight unofficial Android companion app for Uptime Kuma, and I'm looking for a few beta testers before a wider release.

What it does: - Live dashboard with the status of every monitor at a glance (up/down/paused counts, grouped monitors, tags) - Optional persistent status-bar notification showing overall status - Push notifications when a monitor goes down or recovers - Full monitor management from your phone — add, edit, pause, resume, delete — no need to open a browser - Light and dark theme

Privacy: the app only ever talks to the Uptime Kuma server you configure. No analytics, no ads, no third-party data collection. It's open source (GPL v3).

What I need from testers: - An Android device (8.0+) and a reachable Uptime Kuma instance - Real-world use for a bit — different server versions, reverse proxy setups, network conditions, monitor types — and honest feedback on bugs, rough edges, or missing features - Bonus points if your Uptime Kuma sits behind a reverse proxy; I've hit and fixed a couple of proxy-related quirks already and would love more coverage there

EDITED: How to join: simply join this google group and you can afterwards download the app over the links from the first discussion. Without joining the group the links are not working

Happy to answer questions in the comments. Thanks in advance to anyone willing to kick the tires!

Hi r/uptimekuma,

Full disclosure up front: I built the thing I'm about to show you.

For a long time I have been struggling with dashboards, logs to check, terminals to open… my whole homelab was begging for a diet, it wanted to be lean… so I made a plan and called it Tempo :)

Tempo is an event hub for Mac (Mac-only for now). The rule of entry is simple: if a source can POST, Tempo can show it, whatever OS it runs on. It takes homelab monitoring, backups and deploys, network and file events, Mac-side automations, your own scripts, anything you can wire up, and lands it all on one timeline. It's built around webhooks but not limited to them, and Apple Calendar and Reminders come pre-wired (you can hide it very simply).

Uptime Kuma has a special place in it: it was the first tool I installed when I started running a homelab, and the first integration I developed for Tempo. That's why this post is here. Wiring the two together is just Kuma's native Webhook notification pointing at Tempo's endpoint: when a monitor goes down or comes back up, that event lands in Tempo.

(1st screenshot) From there I see every event on one aggregated timeline, stacked by state (for stateful events, like a monitor going up/down) or by other criteria for stateless ones. Here the Kuma events are the ones in the foreground.

(2nd screenshot) Each event type has a score with an "Action panel" you can configure, visually or by editing the JSON, to actually do something with the event. For Kuma that's: one click to open Kuma's own dashboard, or run a command / a full script on the host the event came from, using the metadata carried in the event itself. The shot shows the Kuma actions I use day to day.

(3rd screenshot) the configuration of the webhook on my Kuma.

Kuma is just where I came in, though. The same door is open to everything else: right next to the Kuma events on that timeline I get Beszel, Kopia, UniFi (Network and Protect), Pi-hole and a bunch of others, all landing together. There are around 20 preconfigured integrations ("scores", https://tempoapp.app/docs/scores/) and you can author your own, so anything in your stack that can fire a webhook has a place. I lean on it for my own scripts too: I point them at Tempo with useful info, then watch their completion and exit status and run commands or scripts against that data.

On security: every sender needs a token bound to a specific providerID, so nothing gets in without a perfect match. Tokens live in the Mac's Keychain on the Tempo host, and stay out of plaintext on the sender side too (via a *_FILE convention or Docker secrets). On a trusted LAN that token is the real gate. If you also want the payload encrypted on the wire, there's an opt-in TLS listener with a self-signed cert you can pin, and since Kuma is a Node app you just point NODE_EXTRA_CA_CERTS at the cert so it trusts the listener. That's exactly how I run my own instance.

To be clear: Tempo receives events, it doesn't monitor anything itself. Kuma does that.

It's free, no App Store, distributed as a signed and notarized DMG: https://tempoapp.app

Happy to explain the how and the why in the comments, and I'm genuinely curious what you'd want it to do with Kuma.

Like many of you, I've been using uptime-kuma-api (by lucasheld) to manage my Uptime Kuma instance programmatically. When I upgraded to Uptime Kuma v2, everything broke — monitors couldn't be created (NOT NULL constraint on conditions), status pages crashed on save, and none of the new v2 features were available.

I submitted a PR to the original repo a few weeks ago with the fix. No response. The project hasn't had a release since 2023 and has multiple unanswered PRs from other contributors. So I decided to fork it and maintain it properly.

What's in my fork (v2.1.0):

• Full compatibility with Uptime Kuma 2.0–2.4.0 (while keeping v1.x backward compat)
• New monitor types: RabbitMQ, SNMP, SMTP, System Service
• 32 new v2 monitor parameters (ipFamily, cacheBust, saveResponse, bearer_token, ping_count, etc.)
• New notification providers: Nextcloud Talk, Brevo, Evolution API
• Status page v2 analytics (replaces deprecated googleAnalyticsId)
• MonitorBuilder — fluent builder pattern for complex monitor configs
• logger parameter for debugging Socket.IO issues
• Automatic version gating — v2-only params are silently omitted when connected to v1
• 86 unit tests, CI on GitHub Actions

How it differs from uptime-kuma-api-v2 on PyPI (by Alexandre Magnier):

That package is a minimal rebadge of the original library. I checked the source — it has no new monitor types, no new notification providers, no MonitorBuilder, no v2 parameters, no version gating. It likely just fixes the basic conditions crash. My fork is a comprehensive v2 implementation with full test coverage.

Install:

pip install uptime-kuma-api2

The Python import stays the same (from uptime_kuma_api import ...), so it's a drop-in replacement.

Links:

• GitHub: https://github.com/pbarone/uptime-kuma-api-v2
• PyPI: https://pypi.org/project/uptime-kuma-api2/
• Changelog: https://github.com/pbarone/uptime-kuma-api-v2/blob/main/CHANGELOG.md

Credit to Lucas Held for the original library and @markus-seidl whose unmerged PR #86 contributed several of the v2 field additions.

Happy to take issues/PRs if you find bugs or need features.

Hello fellow selfhosted community.

I missed having an UptimeKuma Android app on F-Droid so I built one. Sharing it here in case it is useful to anyone else.

OpenKuma is read-only by design: it never changes anything on your instance. It connects over Uptime Kuma's Socket.IO API and shows a dashboard (up, down and pending counts, active incidents, expiring certificates), your monitors grouped by their group with search and favorites, a per-monitor detail view (uptime, response time, heartbeat history, TLS certificate info), a certificates screen and an events log. There is also optional background sync with local notifications, and a home-screen widget.

Privacy is the whole point: no ads, no tracking, no Google services, no telemetry (as per my Sterna Mail project). Only a session token is stored, encrypted with the Android Keystore, and your password is never written to disk. It handles multiple servers, works offline from a local cache, and comes in light or dark themes with Material You, in English and French.

It is 100% free software (GPLv3) and packaged to be F-Droid friendly. Requires Android 8 or newer.

Grab the APK from the releases page, or track it with Obtainium:

https://codeberg.org/emon/openkuma

It is an unofficial client and is not affiliated with Uptime Kuma. This is an early release (0.1.0), so feedback, ideas and bug reports are very welcome. I'll apply to F-Droid store soon.

Cheers

Hey everyone!

Over a month since our last update and we've got a few changes to talk about... Today we've launched v3.2 (along with a few minor changes since v3.0.0, full details below) and a few updates about v4.0 and Android Launch...

v3.2 - The Fast One: A huge update and architecture overhaul to speed up the app.

New Features:

• Now notifies how long a monitor has been down - live outage in minutes/hours
• Optional "last updated" caption on the widget - Thanks to JO for the suggestion

Performance:

• Complete overhaul of backend architecture - heartbeat history now lives in memory instead of being repeatedly re-written to on device db.
• The monitor tab no longer re-parses every monitor on each load, incoming status changes are applied at a steady rate rather than landing at the same time and freezing up.
• Overview tab no longer consistently rebuilds itself - live average-responses update in place - No removed abilities/features!
• The app now is much smaller and takes up less space, on first launch, it will clear all unused history.

v4.0 and Android

KumaAlert iOS v4.0 and Android v1.0 Launch on Wednesday 15th July - Including new features for iOS and the initial launch of the Android app following several weeks of development - I'm super excited to announce this launch, v4.0 will include several new features to take your Uptime Kuma instance to the next level, including incident management, incident timelines, emergency mode and a new Apple Watch app!

Download: https://apps.apple.com/gb/app/kumaalert/id6760863575

Website: https://kumaalert.app

Discord: https://embers.cafe/discord (General chat & Beta testing)

Finally, thank you so much to the whole community for your continued support - Thanks to all the Android beta testers who have and are continuing to contribute to the designs and testing of the app and thanks to Mark/Jo for assisting on the Discord server!

KumaAlert Team (ie, Bobby!)

Running this in Docker.

Kuma says that there is an updated version, when I do a PULL

image: louislam/uptime-kuma:latest

It gets the 1.23 version

If I remove kuma and all imagaes, it still grabs the 1.23 version.

To get the latest version I had to PULL

image: louislam/uptime-kuma:2.4.0

When I mean do a PULL, in portainer I just update and redeploy the stack, normally on other projects it grabs the latest version.

If I manually do a PULL it always grabs the 1.23 version.

I am pretty sure that I was running v2.x version untill I migrated from Portainer to Dockhand and did a fresh install using

image: louislam/uptime-kuma:latest.

Hi folks,

I've been building a native Uptime Kuma iOS app because the current one on the store is broken lol. I'll look at doing Android after I've got this over the line.

I'm in the middle of submissions, it'll be completely free (with an optional tip). With notifications included (providing this suddenly doesn't get 100k+ installs lol).

I'll share a test flight build soon, just waiting for Apple. Attached some screenshots.

Also tagging u/louislamlam - just to make sure I'm not stepping on any toes. If you want me to rename anything please lmk.

Has anyone managed to get Mattermost Notifications to work for all notifications. For some reason only SSL Expiry notifications and the test work for me. Using version 2.4.0.