Migrate from Uptime Kuma to SolidPing

You do not have to recreate your monitors by hand. SolidPing reads your Uptime Kuma data, turns every monitor into a check, and turns Kuma's monitor groups into check groups. It previews first, so nothing is written until you say so.

Not sure you want to move? Read SolidPing vs Uptime Kuma first. It says where Kuma is the better choice too.

Uptime Kuma 2.x

Kuma 2.0 removed the JSON backup export, so the sp CLI reads your SQLite database (kuma.db) directly, on your own machine. The file never leaves it. sp opens it read-only and reads three small tables (monitor, tag, monitor_tag). It does not touch the heartbeat history, the notification table or the user table, which is where Kuma keeps integration tokens and password hashes.

1. Find kuma.db

Install	Location
Bare metal	`data/kuma.db` under Kuma's working directory
Docker	In the volume mounted at `/app/data`: `docker cp <container>:/app/data/kuma.db .`

Kuma runs in WAL mode, so you may also see kuma.db-wal and kuma.db-shm next to it. Copy all three together, or stop Kuma first. Without the -wal file, recent monitors are silently missing.

Kuma on MariaDB has no kuma.db, so this path does not apply to it.

2. Preview

sp checks import --from uptime-kuma-db ./kuma.db

Preview is the default. You get the list of checks that would be created and every item that did not map cleanly.

3. Apply

sp checks import --from uptime-kuma-db ./kuma.db --apply

Checks are matched by slug, so running it again updates in place instead of duplicating. You can keep Kuma running next to SolidPing until you are ready to cut over.

Uptime Kuma 1.x

Export from Profile > Settings > Backup > Export, then in the SolidPing dashboard open Checks > Import, pick Uptime Kuma (backup JSON), paste or upload the file and click Import preview. Or use the API:

curl -s -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  --data-binary @uptime-kuma-backup.json \
  'https://your-instance/api/v1/orgs/myorg/checks/import/convert?source=uptime-kuma&dryRun=true'

Drop dryRun=true to apply. The token must belong to an organization admin.

What maps

Uptime Kuma	SolidPing
`http`	`http`
`keyword`	`http`, body must contain the keyword (inverted: must not contain)
`json-query`	`http` with a JSONPath assertion
`port`	`tcp`
`ping`	`icmp`
`dns`	`dns`
`docker`	`docker`
`push`	`heartbeat`
`grpc-keyword`	`grpc`
`mqtt`	`mqtt`
`postgres`	`postgresql`
`mysql`	`mysql`
`redis`	`redis`
`sqlserver`	`mssql`
`mongodb`	`mongodb`
`steam`	`a2s`
`real-browser`	`browser`
`group`	a check group, its children are assigned to it

Interval, timeout, expected status codes, headers, DNS server and record type carry over. Retries multiplied by retry interval become the incident confirmation period.

What you do by hand

The preview lists all of this as warnings.

Passwords. Database, MQTT and basic-auth credentials are never imported. Re-enter them on the check.
Push monitors get new URLs. A push monitor becomes a heartbeat check with a new ping URL. Copy it and repoint the job that pushes to it.
Notifications. Kuma's bindings do not carry over. Set up SolidPing integrations and on-call.
Tags. Add SolidPing labels yourself.
ignoreTls and upsideDown. No equivalent. SolidPing verifies certificates and the check reports normally.
gamedig, radius, tailscale-ping. No counterpart yet, these are skipped.
Status history. Results are not portable between tools.

Imported checks carry the label solidping-managed=uptime-kuma, so you can filter on exactly what the import created.

Full reference

The complete guide, kept next to the code, is at solidping.io/docs/features/migrate/from-uptime-kuma. If something does not import the way you expect, open an issue with a sample. That sample is most of the work.

Uptime Kuma 2.x​

1. Find kuma.db​

2. Preview​

3. Apply​

Uptime Kuma 1.x​

What maps​

What you do by hand​

Full reference​