Migrate from Gatus to SolidPing

SolidPing reads a Gatus config.yaml directly. Every entry of the endpoints: list becomes a check, conditions included. It previews first, so nothing is written until you say so.

Not sure you want to move? Read SolidPing vs Gatus first. It says where Gatus is the better choice too, and for people who want their monitoring to live in a Git repo it often is.

1. Find your config

Gatus has no export API, the YAML file is the source of truth.

Docker or Compose: the file you mount at /config/config.yaml.
Kubernetes: the ConfigMap the pod mounts, for example kubectl get configmap gatus-config -o jsonpath='{.data.config\.yaml}'.
Binary: config/config.yaml next to the binary, or whatever GATUS_CONFIG_PATH points at.

If you split your config across a directory, concatenate the files that contain endpoints: into one document first.

2. Preview

In the SolidPing dashboard open Checks > Import, pick Gatus (config.yaml), paste or upload the file and click Import preview. You get the list of checks that would be created and every item that did not map cleanly.

Or use the API with an organization admin token:

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

3. Apply

Confirm in the dashboard, or drop dryRun=true from the API call. Checks are matched by slug, so running it again updates in place instead of duplicating. You can keep Gatus running next to SolidPing until you are ready to cut over.

What maps

Gatus	SolidPing
`http://`, `https://`	`http`
`tcp://`, `tls://`, `starttls://`	`tcp` (TLS on for `tls` and `starttls`)
`udp://`	`udp`
`icmp://`, `ping://`	`icmp`
`ssh://`	`ssh`
`ws://`, `wss://`	`websocket`
a `dns:` block	`dns` (the `url` becomes the resolver)
`group`	a check group, created on apply

Name, enabled, interval, method, body, headers and client timeout carry over.

Conditions are translated too:

Gatus condition	SolidPing
`[STATUS] == 200`	expected status
`[STATUS] == any(200, 301)`, `== 2XX`	expected status codes
`[BODY] == value`, `!= value`	body must contain, must not contain
`[BODY] == pat(glob)`	body regex
`[BODY].path == value` (and `!=`, `>`, `>=`, `<`, `<=`)	a JSONPath assertion
`has([BODY].path) == true`	an `exists` assertion
`[CERTIFICATE_EXPIRATION] > 48h`	a separate `ssl` check with that threshold
`[DOMAIN_EXPIRATION] > 720h`	a separate `domain` check with that threshold

What you do by hand

The preview lists all of this as warnings. The check is still imported.

[RESPONSE_TIME] and [IP] conditions. SolidPing records response time as a metric, not as a pass or fail condition.
len([BODY].path) conditions. No direct equivalent.
Alerts. Notification bindings do not carry over. Set up SolidPing integrations and on-call.
external-endpoints. Recreate them as heartbeat checks.
SSH credentials. Never imported, on purpose. Re-enter them on the check.
sctp://. No counterpart, skipped with a warning.

Imported checks carry the label solidping-managed=gatus, 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-gatus. If something does not import the way you expect, open an issue with a sample. That sample is most of the work.

1. Find your config​

2. Preview​

3. Apply​

What maps​

What you do by hand​

Full reference​