On this page
Uptime Kuma is a great piece of software, and plenty of people outgrow it anyway. Not because it stops working, but because it runs on the same box, network or power circuit as the things it watches, so the outage that matters most is the one it can't tell you about. If you've decided to move your checks somewhere that lives outside your network, here is how to do it without retyping a single URL.
The short version
- Kuma 1.x: use Settings → Backup → Export. Kuma 2.x removed that export, so upload the kuma.db file instead.
- kuma.db carries your check history and often exceeds the 10 MB upload limit. Trim a copy before uploading.
- Imported monitors arrive paused, so nothing alerts until you've reviewed them.
- HTTP, keyword, TCP, DNS and ping checks map directly. Push monitors become heartbeats with a new ping URL.
- Alert channels, status pages and history stay behind. Connect your channels before you resume anything.
Should you move at all?
If Kuma is running happily and you're mostly watching things from inside the same network, keep it. It's free and it's excellent. The reasons people move are specific:
- The monitor shares a failure domain with what it monitors. When the host, the uplink or the power goes, Kuma goes with it, and nobody gets the alert.
- One probe location means a network blip between Kuma and the target looks like an outage.
- You want server metrics, backups, certificates, domains and status pages in the same place as your uptime checks, without running and patching the monitor yourself.
We wrote an honest comparison of the trade-offs in Ensju vs Uptime Kuma. The rest of this guide assumes you've decided to move.
Step 1: Get your monitors out of Kuma
Which route you take depends on your Kuma version.
Kuma 1.x: the JSON export
In Kuma 1.x, open Settings → Backup and choose Export. You get a JSON file containing your monitor list. The feature has been marked deprecated since 1.18, but it still works on 1.x and it's the easiest route.
Kuma 2.x: the kuma.db file
Kuma 2.0 removed the JSON backup entirely; backing up the data directory is now the only supported method (see the official v1 to v2 migration notes). With the default SQLite storage, your monitors live in kuma.db inside that directory, which Docker installs mount at /app/data. Stop Kuma first, so the file is consistent, then copy it out:
docker stop uptime-kuma
docker cp uptime-kuma:/app/data/kuma.db ./kuma-export.db
docker start uptime-kumaThe 10 MB limit, and how to get under it
The import accepts a database up to 10 MB, and an active kuma.db is usually much bigger because it also stores every check result. The importer only reads your monitor definitions, so you can delete the history from your copy (never the live file) and shrink it:
sqlite3 kuma-export.db "DELETE FROM heartbeat; VACUUM;"
ls -lh kuma-export.dbOn 2.x, if the file is still large, clear the aggregate tables too: stat_minutely, stat_hourly and stat_daily. Then run VACUUM again.
If your Kuma 2.x install stores its data in MariaDB rather than SQLite, there's no kuma.db to upload. In that case the checks have to be recreated by hand, or imported from an older 1.x JSON backup if you still have one.
Step 2: Import into Ensju
- Create a free account (no card needed).
- Go to Monitors and click Import.
- Pick the Uptime Kuma JSON export or database file option, upload your file, and run the import.
The result screen tells you exactly what happened:
- How many monitors were imported, all of them paused.
- Any check interval that was raised to your plan's minimum. On Free that's every 5 minutes; Homelab and up go down to 60 seconds or less.
- Anything skipped because your plan's monitor limit was reached.
- Every Kuma monitor that couldn't be imported, with the reason.
Free covers 10 monitors and 5 heartbeats. Homelab ($10/mo) covers 25 monitors and 25 heartbeats, so most homelab Kuma installs fit there. If you import more than your plan allows, the import creates what fits and lists the rest; it doesn't fail.
What maps to what
| Kuma monitor type | In Ensju |
|---|---|
| HTTP(s) | HTTP monitor (URL and method) |
| HTTP(s) - Keyword | HTTP monitor with a keyword match |
| TCP Port | TCP monitor |
| DNS | DNS monitor |
| Ping | ICMP monitor |
| Push | Heartbeat, with a new ping URL (step 3) |
| Group | Not imported: recreate the grouping with tags |
| Docker container | Not imported: install the server agent with Docker reporting |
| HTTP(s) - Json Query | Not imported: recreate as an HTTP monitor with JSON assertions |
| Databases, MQTT, gRPC, game servers, others | Not imported, listed with the reason |
What to check before resuming
The importer moves the target and the schedule. A few Kuma settings have no direct equivalent, so give each imported monitor a quick look before you un-pause it:
- Expected status. Kuma accepts a range like
200-299; Ensju checks one status code, and the import uses the low end of the first range (so 200). A check that normally returns 204 or a redirect needs its expected status changed. - Inverted keywords. Kuma can alert when a keyword is present. That inversion doesn't carry over: the keyword imports as a normal "must contain" match. Remove it or rework the check, or it will read as down.
- Auth, headers and bodies. Request headers, bodies and basic auth aren't imported. Add them back on any check that needs them.
Tip
Step 3: Rewire push monitors to heartbeats
A Kuma push monitor waits for your job to call it. In Ensju that's a heartbeat, and the import creates one for each push monitor with the same expected interval. The ping URL is new, so each job needs a one-line change:
# Kuma
curl -fsS "https://kuma.example.com/api/push/AbC123?status=up&msg=OK"
# Ensju
curl -fsS https://ensju.com/api/public/heartbeats/<your-token>A heartbeat stays pending until its first ping arrives, so you can't get a false alarm while you work through your crontabs. If a job knows it failed, it can POST to the same URL with /fail on the end to alert immediately instead of waiting for the ping to go overdue.
Step 4: Alerts, then go live
- Connect at least one alert channel, such as email, Slack, Discord, Telegram or a webhook. Kuma's notification settings don't come across.
- Check each imported monitor's alert routing, then resume the monitors.
- Run Kuma and Ensju side by side for a week. When they agree, retire Kuma, or keep it on the LAN for internal-only checks.
That last option is worth a thought: Kuma is very good at watching things only reachable from inside your network. Pairing it with an outside monitor that watches Kuma's host gives you both views. For everything else in the rack, the homelab monitoring guide covers what else is worth watching.
Frequently asked questions
- Can I import Uptime Kuma 2.x monitors?
- Yes, by uploading the kuma.db SQLite database. Kuma 2.0 removed the old JSON backup export, so the database file is the way out. If your Kuma 2.x install stores its data in MariaDB instead of SQLite, there is no kuma.db to upload and the checks have to be recreated.
- Will importing start sending alerts straight away?
- No. Imported monitors arrive paused, so nothing is checked or alerted until you resume them. Push monitors become heartbeats, and a heartbeat stays pending until its first ping, so it can't alert before you point your job at the new URL either.
- What happens if I import more monitors than my plan allows?
- The import creates monitors up to your plan's limit and lists the rest as skipped, rather than failing. You can upgrade and import again, or pick which checks to recreate.
- Do my Kuma notification settings come across?
- No. Notification channels, status pages, maintenance windows and check history stay in Kuma. Connect your alert channels in Ensju before you resume the imported monitors.
- Should I shut Kuma down after importing?
- Not right away. Run both side by side for a week, compare what each one reports, then retire Kuma once you trust the new setup.