CheckCle: self-hosted uptime and server monitoring built on Go and PocketBase
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.
At a glance
- What is it?
- CheckCle bundles HTTP, DNS, ping and TCP checks, server agents, SSL expiry tracking and multi-channel alerts into one Docker-deployed stack. It is a credible fit for small teams that want one binary to own, and a poor fit for anyone who needs a managed control plane or a long support horizon.
- Who is it for?
- Adopt CheckCle if you run a handful of servers and want uptime checks, SSL expiry warnings and CPU/RAM/disk metrics behind one admin login you control, and if you accept that both the web UI and the storage layer are PocketBase. Do not adopt it if you need a managed service with an SLA, if you are monitoring thousands of targets, or if you cannot take on the upgrade work that a project shipping three minor releases in two months implies.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 61 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap CheckCle is trying to fill
Most small engineering teams end up running two monitoring tools that do not talk to each other: an uptime checker for HTTP endpoints, and a metrics agent for CPU, memory and disk. CheckCle's pitch, as stated in its README, is to collapse both into one self-hosted platform. It monitors HTTP, DNS, ping and TCP-based services such as FTP, SMTP and HTTP, and separately tracks infrastructure servers on Linux (Debian, Ubuntu, CentOS, Red Hat and others) with a Windows agent marked Beta. The README also lists SSL and domain monitoring with issuer, expiration date and days-left fields, incident history with UP, DOWN, WARNING and PAUSE states, and public status pages.
The intended audience is named directly: developers, sysadmins and DevOps teams. That framing matters. This is not a tool for a platform team running tens of thousands of series through a time-series database. It is for the person who already has SSH access to every box and wants a dashboard that answers two questions in one place: is the service up, and is the machine healthy. The project is MIT licensed, so there is no open-core split to reason about, though the README notes that sponsorships are no longer accepted and support now comes only as infrastructure partnerships.
How the checks, agents and storage fit together
The repository is Go on the backend and TypeScript on the frontend, and the deployment image is a single container exposing port 8090. The storage layer is PocketBase, which the topics list confirms and which the volume mapping makes visible: the container writes to /mnt/pb_data, and the documented Compose file maps that to /opt/pb_data on the host. That single mount is where your check history, incident records, user accounts and settings live.
Server metrics arrive through an agent rather than through remote polling. The README describes a one-line installation agent script for Linux and Windows, which means the host pushes its own CPU, RAM, disk and network figures back to the CheckCle instance. Uptime checks work the other way: the CheckCle process originates HTTP, DNS, ping and TCP probes and records response times and status transitions. The v1.4 release notes mention distributed monitoring and health heatmaps, so checks can apparently run from more than one region, though the README does not document how a regional node is registered or what its own deployment footprint is. Treat that as an area to read the docs site for before you plan a multi-region setup.
Getting it running with Docker Compose
The README gives two deployment paths and recommends the Compose one. The service definition uses the image operacle/checkcle:latest, sets restart: unless-stopped, publishes 8090:8090, and mounts /opt/pb_data to /mnt/pb_data. It also raises the file descriptor limit with a nofile ulimit of 4096 soft and 8192 hard. The equivalent docker run command carries the same four settings: -p 8090:8090, -v /opt/pb_data:/mnt/pb_data, --ulimit nofile=4096:8192 and --restart unless-stopped.
After the container starts, the admin interface is at http://0.0.0.0:8090 with the default credentials admin@example.com and Admin123456. Those credentials are also published for the public demo at demo.checkcle.io, which is a reasonable convenience for evaluation and a bad default to leave in place on anything reachable from the internet. The README points to docs.checkcle.io for the quick start guide; the Compose file itself contains no environment variables for secrets, mail relays or alert channels, so notification configuration happens through the settings panel rather than through the deployment manifest. Supported architectures per the README are amd64 and arm64, which covers x86_64 servers, Raspberry Pi 3/4/5 on 64-bit OS, and Apple Silicon Macs. If you are on a 32-bit ARM board, this image is not for you.
Where the design choices cost you
Three things stand out as real constraints rather than nitpicks. The first is that PocketBase is doing double duty as both the application framework and the datastore. That is what makes a single-container deployment possible, and it is also what makes scaling awkward: there is no documented path in the README for pointing CheckCle at an external Postgres or ClickHouse instance, so check history grows inside the same volume as your user records. Data retention is exposed as a setting in the settings panel, which suggests the project expects you to bound that growth yourself rather than relying on automatic tiering.
The second is the Windows agent, which the README labels Beta. If your fleet is mixed, plan for the Linux side to be the tested path and the Windows side to be the one you validate first.
The third is release cadence. v1.4, v1.5.0 and v1.6.0 all landed between July and September 2025, with v1.5.0 described as a notification system overhaul and v1.4 introducing distributed monitoring and server agents. Fast movement on a young project means features arrive quickly and interfaces can shift. Anyone pinning to operacle/checkcle:latest is opting into that churn on every container restart. Pinning to a version tag is the more defensible choice for anything you depend on, and the README does not discuss upgrade or migration steps between releases.
CheckCle against Prometheus and Uptime Kuma
The honest comparison is not against a single tool, because CheckCle straddles two categories. Against Uptime Kuma, the difference is scope rather than approach: both are self-hosted uptime checkers with status pages and notifications, but Uptime Kuma does not ship a server metrics agent, so you would pair it with something else to get CPU and disk figures. CheckCle folds that in, at the cost of a heavier stack and a PocketBase dependency you may not otherwise want.
Against Prometheus with node_exporter and Blackbox Exporter, the difference is architectural. Prometheus pulls metrics on a scrape interval and stores them in a time-series database built for high-cardinality queries and long retention; alerting runs through Alertmanager with its own routing and grouping model. CheckCle pushes from an agent, stores in PocketBase, and configures alerts through a web panel with templates. Prometheus gives you a query language and a decade of ecosystem integration, and asks you to run and understand three or four components. CheckCle gives you one container and a login form, and asks you to accept its opinions about storage and retention. For a five-server shop, that trade is usually worth it. For a platform team with existing Prometheus infrastructure, adding CheckCle means a second source of truth for the same machines.
Notifications, licence and the maintenance bill
Alerting covers email, Telegram, Discord, Slack and Matrix, with alert templates configurable in the settings panel alongside user management, data retention, themes and multi-language support. The v1.5.0 release was explicitly a notification system release, so this is the area the project has invested in most recently. What the README does not describe is alert routing logic: whether you can send one channel for a warning and another for a hard down, or how repeated failures are grouped. That is a question for the docs.
The MIT licence is permissive and places no conditions on how you run CheckCle internally or modify it. It also means there is no commercial entity obligated to fix your bug, and the README's note that sponsorships are no longer accepted removes one possible funding path for sustained maintenance. Practically, your maintenance cost is the container image plus the PocketBase volume: you own the backups of /opt/pb_data, you own the upgrade timing, and you own the retention policy that keeps that volume from growing without bound. Budget for reading release notes before each bump rather than restarting onto latest and hoping.
Editorial conclusion
Adopt CheckCle if you run a handful of servers and want uptime checks, SSL expiry warnings and CPU/RAM/disk metrics behind one admin login you control, and if you accept that both the web UI and the storage layer are PocketBase. Do not adopt it if you need a managed service with an SLA, if you are monitoring thousands of targets, or if you cannot take on the upgrade work that a project shipping three minor releases in two months implies. Before rolling it out, verify three things in your own environment: that the agent script supports your OS, that your retention settings match the size of the /opt/pb_data volume you mount, and that the ports and protocols your checks need are actually reachable from the host running the container.
Community notes