# CheckCle: self-hosted uptime and server monitoring in one Go binary

> CheckCle is an MIT-licensed monitoring platform that runs from a single Docker image and covers uptime checks, SSL expiry, server metrics and alerts. It is a reasonable fit for small teams that want one dashboard, and a poor fit for anyone who needs long-term historical analytics or a documented rollback path.

**operacle/checkcle** — CheckCle is a self-hosted, open-source monitoring platform for seamless, real-time full-stack systems, applications, and infrastructure. It provides real-time uptime monitoring, distributed checks, incident tracking, and alerts. All deployable anywhere.

- Repository: https://github.com/operacle/checkcle
- Website: https://checkcle.io
- Stars: 3,279 · Forks: 292
- Language: Go
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/operacle-checkcle

## What CheckCle actually replaces on a small team's dashboard

Most small teams end up running three things: an uptime checker pinging HTTP endpoints, a separate agent-based tool for CPU and disk graphs, and a spreadsheet or calendar reminder for SSL certificate expiry. CheckCle's README presents all three as one product. The feature list names HTTP, DNS, Ping and TCP-based checks, SSL and domain monitoring with issuer and days-left fields, and infrastructure server monitoring for Debian, Ubuntu, CentOS and Red Hat, with Windows marked Beta. The stated audience is developers, sysadmins and DevOps teams. That framing is honest about the scope: this is a general-purpose operations dashboard, not a specialised tool for any one of those jobs. The practical appeal is consolidation. A team of three running eight services does not want three logins and three alerting configurations, and CheckCle's notification list (email, Telegram, Discord, Slack, Matrix) is broad enough that most teams will find their existing channel already supported. Where the README is thin is on scale. It never states how many monitors a single instance handles comfortably, and the only sizing hint anywhere in the repository is the file-descriptor limit in the compose file, which is a hint about concurrent connections rather than a published benchmark.

## How the container, the storage volume and the agents fit together

The repository root shows the shape of the system: an application/ directory, a server/ directory, a docker/ directory and a docker-compose.yml. The primary language is Go, and the topics list includes pocketbase, which tells you the persistence layer is PocketBase rather than an external database you have to provision. That is the single most consequential architectural fact here. There is no Postgres or MySQL service in the compose file, so there is nothing to back up separately and nothing to migrate when you upgrade the application image. The data lives in the mounted volume. The compose file maps the host path /opt/pb_data to the container path /mnt/pb_data, and the README's docker run example uses the same pair. Everything you would want to keep, including monitor definitions, incident history and user accounts, is inside that directory. The second half of the architecture is the agent model. The README describes server monitoring as requiring a one-line installation agent script, and the v1.4 release notes mention server agents alongside distributed monitoring and health heatmaps. So the flow is: the central container holds the dashboard and the check scheduler, remote hosts run an agent that reports CPU, RAM, disk and network metrics back, and regional checks can originate from more than one location. The README does not document the agent protocol, the port it listens on, or how agents authenticate. If you plan to monitor hosts outside a trusted network, that gap matters more than any feature on the list.

## Installing CheckCle and getting the first monitor running

The README recommends Docker Compose and ships a compose file at the repository root. The image is operacle/checkcle:latest and the web application listens on port 8090. Note the comment in the repository's compose file: for a local-only deployment you can bind the port to 127.0.0.1 instead of exposing it on every interface, which is worth doing before you have changed the default credentials.

```yaml
services:
  checkcle:
    image: operacle/checkcle:latest
    container_name: checkcle
    restart: unless-stopped
    ports:
      - "127.0.0.1:8090:8090"
    volumes:
      - /opt/pb_data:/mnt/pb_data
    ulimits:
      nofile:
        soft: 4096
        hard: 8192
```

If you would rather not keep a compose file around, the README gives an equivalent single command. The volume flag and the ulimit flag are the two parts you should not drop, because they are what make the data survive a container replacement and what raise the open-file limit above the default.

```bash
docker run -d \
  --name checkcle \
  --restart unless-stopped \
  -p 127.0.0.1:8090:8090 \
  -v /opt/pb_data:/mnt/pb_data \
  --ulimit nofile=4096:8192 \
  operacle/checkcle:latest
```

Once the container is up, open http://0.0.0.0:8090 as the README instructs and log in with the documented defaults, admin@example.com and Admin123456. Both the README and the live demo at demo.checkcle.io publish the same credentials, so treat them as public knowledge and change them immediately. From the dashboard, add an HTTP monitor for one of your own endpoints and confirm that the incident history shows it going UP. The README points to https://docs.checkcle.io for the quick start guide, and that is where the per-feature walkthroughs live rather than in the repository README.

## The default credentials, the missing rollback notes and other sharp edges

The most obvious limitation is the one printed in the README twice: a fixed admin account with a published password. That is fine for a demo and unacceptable for anything reachable from a network you do not control. Bind to 127.0.0.1, log in, change the password, and only then decide whether to expose the port.

The second limitation is upgrade safety. The README documents installation and nothing else. There is no rollback procedure, no statement about whether a schema migration runs automatically on first start of a new image, and no guidance on pinning a version instead of pulling :latest. The compose file and the docker run example both use the latest tag. For a tool whose entire state sits in one mounted directory, that combination means an upgrade is a one-way door unless you snapshot /opt/pb_data yourself first. The release history shows three releases between July and September 2025, so the project moves, and moving projects change storage schemas.

Third, Windows server monitoring is labelled Beta in the README. If your fleet is mixed, plan for the Windows side to be the part that surprises you. Fourth, the README does not describe how the agent script is authenticated, how many check intervals are supported, or what happens when the agent host loses connectivity. Those are the questions to answer before you rely on it for on-call.

## CheckCle versus Uptime Kuma, and when a plain exporter is the better answer

The most common comparison people search for is CheckCle against Uptime Kuma, and the difference is scope rather than quality. Uptime Kuma is a status-page-first uptime checker: you define monitors, it pings them, it shows a page. CheckCle's README claims that plus SSL and domain monitoring with issuer and expiry fields, plus agent-based server metrics, plus distributed regional checks and health heatmaps from the v1.4 release. If you only need a public status page for a handful of URLs, the extra surface area in CheckCle is weight you will carry and not use, and the agent component in particular is something you have to deploy and maintain on every host.

The other honest alternative is not a monitoring platform at all. If you already run Prometheus, node_exporter and Alertmanager, adding CheckCle gives you a second alerting path and a second set of credentials for the same information. CheckCle's advantage in that situation is only the SSL expiry tracking and the status page, and you would be better off solving those two narrow problems than running two overlapping stacks. CheckCle makes sense when you have no monitoring stack yet.

## Licence, maintenance signal and what an upgrade costs you

CheckCle is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are preserved. The repository ships a LICENSE.md at the root, and that file is the authoritative text rather than this description. Nothing in the README suggests a separate enterprise edition or a feature held back behind a licence key, and the README states the project is free to use with no hidden costs. Sponsorship has been closed to cash and is now limited to infrastructure partnerships, which removes one common route to a paid tier.

The maintenance signal is straightforward. The repository is not archived, and the last push was on 2026-07-17. Releases v1.4, v1.5.0 and v1.6.0 landed between 2025-07-22 and 2025-09-13. The upgrade cost is the part to budget for. Because state lives in the mounted volume and the examples pull :latest, every upgrade is a container replacement plus whatever migration the new image performs on start. The README does not describe that migration or a downgrade path. A workable routine is to stop the container, copy /opt/pb_data somewhere else, pull the new image, and start it again, which costs disk space and a short maintenance window rather than engineering time.

## Conclusion

Adopt CheckCle if you run a handful of services and want uptime, SSL expiry and basic server metrics behind one login without paying per host. Do not adopt it if you need a documented rollback procedure, a published security audit, or long-horizon metric retention, because the README covers none of those. Before you commit, pull operacle/checkcle:latest, bind it to 127.0.0.1:8090, change the default admin@example.com / Admin123456 credentials, and confirm that /opt/pb_data receives a file you can restore from.

## FAQ

### What is the best free open source monitoring tool?

There is no single answer, and CheckCle's own README positions it as one option among many. CheckCle is free and MIT licensed, and it consolidates uptime, SSL and server monitoring into one self-hosted container, which is the trade-off to weigh against narrower tools.

### What are the best tools for monitoring websites?

CheckCle covers HTTP, DNS, Ping and TCP-based checks, tracks response times and keeps incident history with UP, DOWN, WARNING and PAUSE states. The README does not compare it against other tools, so the choice depends on whether you also need the server metrics and SSL tracking CheckCle bundles.

### What are the best monitoring tools for servers?

CheckCle monitors Linux servers including Debian, Ubuntu, CentOS and Red Hat through a one-line agent installation script, reporting CPU, RAM, disk usage and network activity. Windows support is marked Beta in the README.

### What are the different types of monitoring tools?

CheckCle's feature list splits them into uptime and service checks (HTTP, DNS, Ping, TCP), SSL and domain monitoring, and infrastructure server monitoring via agents. It also offers distributed regional monitoring, which is a fourth category in the README's own structure.

## Sources

- [License: MIT](https://github.com/operacle/checkcle/blob/develop/LICENSE)
- [operacle/checkcle on GitHub](https://github.com/operacle/checkcle)
- [Project website](https://checkcle.io)
- [README](https://github.com/operacle/checkcle/blob/develop/README.md)
- [Releases](https://github.com/operacle/checkcle/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/operacle-checkcle