--- title: "Uptime Kuma alternative, hosted | Logdash" description: "Hosted HTTP checks, push heartbeats, a status page and Telegram alerts, with no container to update. Honest about where Uptime Kuma is the better pick." url: https://logdash.io/alternatives/uptime-kuma --- # Uptime Kuma alternative for people who do not want to run a server Logdash is the hosted version of what Kuma does for most people - HTTP checks, heartbeats, a status page and alerts - with no VPS, no container and no SQLite file to back up. Uptime Kuma is genuinely good software. The dashboard looks better than most paid products, it covers more monitor types than anything else in its price bracket, the notification provider list is enormous, and it costs nothing but a container. If you already have a box with spare capacity and you enjoy owning your data, running Kuma is the right call and this page is not going to argue you out of it. The reason people leave is not the software. It is that a monitor running on your own infrastructure shares a fate with your infrastructure. The night the host has a problem is the night Kuma has the same problem, quietly, and you find out from a customer instead of from a notification. Underneath that sits the maintenance nobody plans for: container updates, the database volume, a reverse proxy certificate, and a notification config you set up once in 2024 and have never tested since. Logdash is the hosted answer to that, not a self-hosted replacement. It is AGPL-3.0 licensed with a public repository, but production self-hosting is not a one-command install today. It runs locally for development and the rest is tracked on GitHub. If self-hosting is the point, stay on Kuma. If the point was a monitor that outlives your server, that is the trade here. ## The endpoint the hosted check hits main.py ```python @app.get("/health") async def health(): try: await db.execute("select 1") except Exception: # 503 so a live process with a dead database still reads as down raise HTTPException(status_code=503, detail="db") return {"ok": True} ``` 1. **Create the monitor** Add a monitor and paste the health URL. The first check runs straight away, so you find out the URL is wrong now rather than during an incident. 2. **Move the heartbeats** Kuma push URLs become a POST to https://api.logdash.io/ping/, no auth, no body. Pro expects one every 15 seconds, so anything that pinged less often needs a heartbeat loop, plus a stamp file for scheduled jobs. 3. **Turn the app off** Stop the container and let one check fail. The status page flips to down and the Telegram alert arrives with the status code, this time sent from somewhere that is not the machine you just turned off. ## Uptime Kuma status page API and badges Kuma has both, with caveats. Its badges cover status, uptime, ping and certificate expiry, and the Badge Maker builds the URL for you. Its status page JSON lives under /api/status-page, but the wiki says that API is for Kuma itself and not officially supported. Logdash publishes a versioned public endpoint, a typed client, a shadcn component and a Next.js starter, so a custom status page in your own design is a template away. Badges come per monitor: classic shows uptime over 24h, 7d, 30d or 90d, and status and card come in light or dark. terminal ```bash # The whole status page as JSON, no key curl https://api.logdash.io/v1/status_pages/your-status-page-id # One monitor's badge: classic style, 30-day uptime by default. # your-badge-key is that monitor's id in the JSON above. curl -o uptime.svg \ https://logdash.io/d/your-status-page-id/badges/your-badge-key.svg ``` ### Logdash vs Uptime Kuma | Feature | Logdash | Uptime Kuma | | ------------------------------------ | ---------------------------------------------- | ---------------------------------------------------------- | | Where it runs | Hosted, nothing to update | Your server, your updates, your backups | | Monitor types | HTTP checks and push heartbeats | HTTP, TCP, ping, DNS, keyword, certificate expiry and more | | Survives your infrastructure failing | Runs outside your stack | Goes down with the host it sits on | | Notification channels | Telegram and webhook | Dozens of providers built in | | App logs and custom metrics | Eight SDKs into the same dashboard | Not what Kuma is for | | Cost at five services | Covered by the free plan | Free, plus whatever the box costs | | Production self-hosting | Not ready, tracked on GitHub | The entire point, one container | | Status page API | Versioned public JSON, typed client, component | Internal endpoints, not officially supported | ### When Uptime Kuma is the better pick - You already run a homelab or a VPS with headroom. Kuma costs one container and you keep every byte of the history. - You need TCP, DNS, ping or certificate expiry checks. Logdash has none of those and is not near having them. - Monitoring has to stay inside your network, on hosts with no public egress. - Self-hosting in production is the requirement. Kuma does that today and Logdash does not, which is the honest end of the comparison. ## What migrating involves No importer, and for a dozen URLs that is fine. Copy them across, rewire the push jobs as above, and run both for a week. The history does not come with you, so if you quote an uptime figure to customers, screenshot the Kuma dashboard first. ### Is there a self hosted alternative to Uptime Kuma? Not from Logdash, not for production. The code is AGPL-3.0 and runs locally for development, but a one-command production install is not ready and is tracked on GitHub. Gatus and Healthchecks are the closer self-hosted comparisons. ### Can I just run Uptime Kuma in Docker instead? Yes, and for a lot of people that is the right answer. One container, one volume for the database, done in ten minutes. The trade is that the monitor now lives on infrastructure you also have to keep alive. ### Is there a free alternative to Uptime Kuma? Logdash has a free plan with five monitors checked every 5 minutes, a public status page and Telegram alerts. Kuma is free too, so the real comparison is a hosted free tier against your time plus a server bill. ### Is Logdash open source like Uptime Kuma? Yes, AGPL-3.0 licensed, repository on GitHub. The difference is intent: Kuma is built to be run by you, Logdash is built to be run for you, and only one of those two ships a production install today. ### What do people on Reddit use instead of Uptime Kuma? Gatus when they want checks defined in YAML next to the app, Healthchecks for cron, and a hosted monitor once they have had an outage where Kuma was on the same host as the thing that broke. ## Keep reading [All alternatives](https://logdash.io/alternatives): One page per tool, each with the setup, the comparison and the case for staying where you are. [Pingdom alternative for a solo founder with four services](https://logdash.io/alternatives/pingdom): Logdash monitors four services on the free plan with 5-minute HTTP checks, a public status page and Telegram alerts, instead of an annual contract shaped for a company with a procurement process. [Better Stack alternative for teams who only wanted uptime checks](https://logdash.io/alternatives/better-stack): Logdash gives you the HTTP monitors, status page and alerts without the on-call schedules, escalation policies and incident timelines you are being billed for and never configured. [Cronitor alternative for cron jobs and uptime in one tool](https://logdash.io/alternatives/cronitor): Logdash watches background jobs with push heartbeats and HTTP endpoints with scheduled checks in the same dashboard, alerting to the same Telegram channel when either one goes quiet. [Uptime monitoring](https://logdash.io/features/monitoring): HTTP checks as often as every 15 seconds. When one fails, Telegram tells you before your users do.