SolidPing vs Gatus
Gatus is the tool to beat if you want your monitoring in Git. Apache-2.0, 100% Go, a sub-20 MB binary, and a configuration model that is YAML and only YAML. For teams who treat every piece of infrastructure as code, that is not a limitation — it is the whole point, and it is why Gatus has 10,000+ stars.
Both sides here are self-hosted. Gatus has no hosted service, so this compares it against SolidPing self-hosted — free, AGPL-3.0, no plan and no caps. Our hosted version exists and is described below, but the table does not depend on it.
SolidPing makes a different trade: a UI and a config-as-code surface, multi-tenancy, and a much wider set of things it can check. This page is about which trade suits you.
Your YAML can come with you. SolidPing ships a first-party Gatus importer with a dry-run mode.
If we've gotten a detail about Gatus wrong, please open an issue — we want this accurate.
At a glance
| SolidPing (self-hosted) | Gatus | |
|---|---|---|
| License | AGPL-3.0 | Apache 2.0 |
| Stars / version | zEr0 (help us grow) | 10,100+ · v5.34.0 |
| Cost | Free — unlimited monitors, check rate, workers and status-page domains; 30 members by default | Free — unlimited |
| Written in | Go | Go |
| Check types | 40 | 9 (HTTP/HTTPS, TCP, ICMP, DNS, WebSocket, SSH, TLS, STARTTLS, External) |
| Configuration | UI and YAML export / import / apply | YAML only — no UI configuration |
| Database | SQLite or PostgreSQL | In-memory (default), SQLite, PostgreSQL |
| Persistence | Always persisted | In-memory by default — data lost on restart unless configured |
| Minimum interval | 10 seconds (browser checks 60 s, JS 30 s) | Configurable |
| Multi-region checks | Distributed workers you run anywhere | Run several instances; no built-in aggregation |
| Multi-user / RBAC | Multi-tenant, roles, read-only accounts | None |
| Auth | OAuth, OIDC, SAML, LDAP, passkeys, TOTP | Basic auth, OIDC, API keys |
| On-call & escalation | Rotation schedules, overrides, iCal, multi-step escalation | Not available |
| Heartbeat / cron checks | Yes | Not available |
| Alert providers | 16, including SMS, voice and WhatsApp through your own Twilio account | 20+ |
| Status pages | Multiple, sections, custom domains, subscribers | One status page |
| Condition syntax | Assertions per check type | Powerful — JSONPath, len(), has(), pat() |
| Git-ops extras | — | Auto-create and auto-close GitHub / GitLab issues |
| Prometheus metrics | Yes | Yes |
| API | Full REST, read and write, sp CLI | Read-only |
| Import from Gatus | Built in | — |
Where SolidPing is the stronger choice
You want a UI as well as a file. Gatus is configured entirely through YAML; there is no way to add a check from the browser. That is deliberate and many teams love it, but it means every change is a commit and every non-engineer is blocked. SolidPing gives you both — click it in the dashboard, or export the whole org to YAML and apply it from CI.
More than one person, with different permissions. Gatus has no multi-user model and no RBAC; the API is read-only. SolidPing is multi-tenant with roles and read-only accounts, behind your existing identity provider.
You need more than nine endpoint types. Gatus covers the network-facing basics well. SolidPing adds databases, mail protocols (SMTP, IMAP, POP3 and a passive email-reception check), message queues, SNMP, Docker and Kubernetes, headless-browser and JavaScript checks, and heartbeat/cron monitoring — which Gatus does not do at all.
More than one status page. Gatus serves a single status page. If you need one per customer or per product, on their own domains, that is a structural difference.
Someone has to be paged. Gatus alerts to 20+ providers but has no on-call model — no rotations, no escalation, no acknowledgement.
Data that survives a restart by default. Gatus is in-memory unless you configure storage. That is a fine default for a stateless status page and a surprising one the first time a pod restarts.
Where Gatus is the stronger choice
Configuration-as-code, done properly. If your standard is "it does not exist unless it is in Git", Gatus is built exactly that way from the ground up, and our YAML surface is a second path rather than the only one.
The condition syntax is genuinely better. JSONPath with len(), has() and
pat() gives you assertions that are more expressive than ours, and it is the feature
we most respect in Gatus.
GitHub and GitLab issue automation. Gatus can open an issue when a check fails and close it when it recovers. Nothing in SolidPing does that today.
It is smaller and simpler to run. A sub-20 MB binary with no database at all if you do not want one. For a stateless status page in Kubernetes, that is hard to beat.
More alert providers, 20+ against our 16.
Apache 2.0 rather than AGPL. If your legal team is uncomfortable with AGPL, that difference decides it regardless of features.
The other model, on both sides
Gatus has no hosted service. Running it is the deal; there is no vendor to hand it to.
SolidPing has one, running the same binary. SolidPing Cloud is free for 100 monitors
and 10 checks a minute, then €5 / €15 / €45, with six shared probe regions you do not have
to deploy. It is the same product with plan caps re-attached and without SMS, voice or
WhatsApp, which stay a self-hosted feature because the carriers bill per message. You can
also keep the GitOps workflow on either one: export the org to YAML and sp apply it from
CI against hosted or self-hosted alike.
Migrating from Gatus
POST /api/v1/orgs/{org}/checks/import/convert?source=gatus&dryRun=true
Run it with dryRun=true and read the result before creating anything. Gatus
conditions do not all have a SolidPing equivalent; the converter reports what it could
not translate instead of dropping it quietly.
Which should you pick?
Stay on Gatus if configuration-as-code is a principle rather than a preference, one status page is enough, and the nine endpoint types cover what you run. It is a well-built tool with a clear philosophy.
Look at SolidPing when you need people in the product who do not write YAML, more than one status page, protocols beyond the network basics, or an on-call rotation. You can keep the GitOps workflow — export to YAML and apply from CI — without making it the only way in.