Compared on 1 September 2026
Pingtower vs Uptime Kuma
Uptime Kuma is a self-hosted prober with a status page. Pingtower is a self-hosted alerting pipeline with a pager. They answer different questions, and plenty of teams run both.
The short version
Pick the one built for your problem.
Pick Uptime Kuma if
- You want a public status page your customers can look at.
- “Is it up” is the whole question, and a Slack or Telegram message is the whole answer.
- You want an MIT-licensed project you can read and patch.
Pick Pingtower if
- Your application’s own errors should page someone, not just an unreachable URL.
- You need escalation: renotify until acked, then the next person, then the schedule.
- A phone has to ring through Silent mode, and one swipe has to stop the ladder.
- You want outside-in checks and inside-the-box sensors from one signed agent.
Side by side
A prober with a status page, next to an alerting pipeline with a pager.
| Pingtower | Uptime Kuma | |
|---|---|---|
| Outside-in checks (HTTP, TCP, DNS, ping, TLS expiry) | Through the addons agent, from any box you choose, plus SSH, port-baseline, traceroute, log and patch checks | Built in, from the Kuma host: HTTP(s), keyword, JSON query, TCP, ping, DNS, push, Docker, Steam, WebSocket |
| Alerts from your application's log lines | POST /v1/ingest from anything that can make a request; repeats collapse by message shape into one alert with a count | Push monitors accept a heartbeat, not an event stream |
| Rules with conditions and thresholds | Match on level, source, tag, shape; compare keys; fire after N in M minutes from distinct sources | Retries and intervals per monitor; keyword and JSON assertions on the response |
| Renotify until acknowledged, escalation ladders | Per rule: renotify cadence, up to ten rungs naming schedules or people, auto-resolve on quiet | One notification on down, one on up |
| On-call schedules | Layered rotations, timezone restrictions, overrides. API today; app screens are coming | Not a feature; teams add a paging product on top |
| Phone app | Native iOS app in open TestFlight beta; critical alerts sound through Silent mode; swipe to ack. Android in development | No first-party app; notifications reach a phone through the channel you connect |
| Public status page | Not a status-page product | Multiple, customisable, live |
| Notification channels | Push, signed webhooks, Slack, Telegram. Runbook actions call any HTTP endpoint | Ninety-plus channels, including Slack, Telegram, Discord, PagerDuty and Opsgenie |
| Inside-the-box sensors | Firewall changes, auth activity, file integrity, listeners, service state, ingress, stall pressure — continuous, from the same agent | |
| Self-hosting | One static Go binary, SQLite inside, signed releases. Paging the App Store app from your box goes through pingtower.com’s relay | Node.js 20.4+ or Docker; SQLite, or MariaDB in 2.0 |
| License | Signed binaries, free to self-host. Source is not published | MIT |
| Price | Hosted: free during preview, no card. Self-hosted: free | Free |
Compared on 1 September 2026 against Uptime Kuma's public documentation. If something here is out of date, tell us and it gets fixed in the same day.
What Uptime Kuma is for
Uptime Kuma asks “is it up” on a schedule and shows you the answer, to you on a dashboard and to your customers on a status page. It does that well, it is MIT-licensed, and it runs on a Raspberry Pi. If a service going unreachable is the only failure you need to know about, and a message in a channel is how you want to know, it is the right tool and this page should not talk you out of it.
What Pingtower is for
Pingtower starts from the other end: the failures your services already know about. Your application POSTs a line when a payment gateway times out; the tower recovers the message’s shape, folds the next forty identical lines into the same alert with a count, evaluates your rules, and pages whoever is on call until a human acks. A phone rings through Silent mode. One swipe stops the ladder.
Outside-in checks are part of that, through the addons agent: the same HTTP, TCP, DNS, ping and certificate checks, run from a box you choose, reported as events your rules threshold. And since 0.2.0 the same agent watches from inside the box: firewall changes, failed logins, a listener that appeared, a service that restarted into a different binary.
Where the line actually is
Kuma tells you a URL stopped answering. Pingtower tells you the checkout started failing for Stripe customers seven minutes before the URL stopped answering, told the on-call engineer, and told their backup when they did not ack. Those are different products with an overlap in the middle, and the overlap is smaller than the feature lists suggest.
Three honest gaps on this side. Pingtower has no status page, and is not going to grow one. Its notification list is four entries long, not ninety; if you need Gotify or Matrix today, a signed webhook to a relay is the path. And the source is not published, which for some self-hosters is the whole decision.
Running both
The common setup is not either-or. Keep Kuma for the status page and the dashboard; add a webhook notification pointing at a Pingtower ingest token. A Kuma down becomes a Pingtower event, which becomes an alert with a rule behind it: renotify every ten minutes, escalate at thirty, page the phone. Your customers keep their status page. You get a pager.
# A Kuma webhook notification, as a Pingtower source
curl -s https://api.pingtower.com/v1/projects/probes/sources \
-H "Authorization: Bearer ptk_…" -d '{"name":"uptime-kuma"}'
# → {"name":"uptime-kuma","token":"pti_…"} # paste into Kuma's webhook, Authorization: Bearer
The docs cover the rest: rules, escalation, and the agent’s checks.
Keep Kuma. Point it at Pingtower.
A Kuma webhook notification is an event Pingtower can ingest. Its downs become alerts with counts, ladders and a phone that rings, and its status page keeps doing what it does.