CheckCle is a self-hosted, open-source monitoring platform designed to provide continuous, real-time observability across systems, applications, and infrastructure—without relying on third-party SaaS dashboards. Positioned for developers, sysadmins, and DevOps teams, the project combines uptime checks, infrastructure metrics, incident tracking, alerting, and public status pages into a single deployable stack that can run “anywhere” you can run containers.

The project’s pitch is straightforward: if your environment spans servers, services, endpoints, and TLS certificates—and you want to own the data and the operational surface—CheckCle aims to be a pragmatic “full-stack monitoring” baseline that’s simpler to deploy than assembling multiple components from scratch.

Why CheckCle exists: full-stack monitoring without vendor lock-in

In practice, monitoring is rarely just “is it up?” Teams need to understand why something is slow, broken, or intermittently failing—often across multiple layers (network, instance, service, certificate, user experience). CheckCle’s focus is to unify common operational needs:

Uptime and protocol monitoring (HTTP, DNS, Ping) plus TCP-based service checks (e.g., API endpoints and other TCP services).
Incident history and state tracking (UP/DOWN/WARNING/PAUSE), plus maintenance scheduling and incident management features.
SSL and domain monitoring, including issuer, expiration, “days left,” and related status signals.

The platform also highlights the reality that many teams run mixed estates (cloud + on-prem, multiple regions, production + staging), so it includes distributed regional monitoring as a first-class concept.

Core capabilities at a glance

From the project’s published feature list, the key areas are:

Uptime, services, and infrastructure monitoring

Protocol checks: HTTP, DNS, Ping, plus TCP-based/API service monitoring.
Visibility into uptime, response times, and performance issues.
Infrastructure server metrics (CPU, RAM, disk usage, network activity), with support called out for Linux distributions and “Windows (Beta)” for server monitoring.

Incident tracking and operational controls

Incident history and lifecycle states (UP/DOWN/WARNING/PAUSE).
Maintenance scheduling and incident management.
Public-facing status pages for communicating availability externally.

Notifications and reporting

Notifications via email, Telegram, Discord, and Slack.
Reporting and analytics to support trend analysis and operational reviews.

Administration and platform settings

A settings panel covering user management, data retention, multi-language support, themes (dark/light), and alert/channel templates.

Deployment: designed for quick self-hosting

CheckCle is built to be deployed with containers, with documentation and examples emphasizing Docker as the quickest start. The project’s docs specify baseline requirements (CPU/RAM/storage) and provide a guided “Quick Start” path.

System requirements (as documented)

The Quick Start documentation lists minimum resource guidance (CPU, memory, storage, and a typical Linux host environment), which is useful for sizing a small VM or a lightweight bare-metal deployment for monitoring.

Architecture support

The project states support for:

x86_64 (amd64) PCs, laptops, and servers
arm64, including modern Raspberry Pi 3/4/5 (with a 64-bit OS) and Apple Silicon Macs

Default port and initial access

The project documentation and README indicate a default web UI port and default credentials intended for first-run access. In any real deployment, rotating these credentials and applying standard access controls (reverse proxy, SSO, IP allowlisting, etc.) is a prudent first operational step.

Example deployment (Docker Compose)

Below is the project’s published Docker Compose pattern (presented here as a practical illustration of the documented setup):

version: '3.9'

services:
  checkcle:
    image: operacle/checkcle:latest
    container_name: checkcle
    restart: unless-stopped
    ports:
      - "8090:8090"
    volumes:
      - /opt/pb_data:/mnt/pb_data
    ulimits:
      nofile:
        soft: 4096
        hard: 8192
Code language: JavaScript (javascript)

This approach also highlights persistent storage mapping (/opt/pb_data to /mnt/pb_data) to retain configuration and state across restarts—an important detail if you’re treating the monitoring platform as production infrastructure rather than a disposable utility.

Where CheckCle fits operationally

CheckCle is best understood as a practical “single-pane” monitoring foundation for teams that want:

A self-hosted platform for uptime + SSL + server metrics + alerting
A consolidated workflow for incident tracking, maintenance windows, and status pages
A deployable option that works for small-to-mid environments without immediately requiring a large observability engineering investment

For many organizations, this category of tooling becomes especially relevant when the monitoring surface area expands (more services, more endpoints, more certificates, more teams), and operational risk rises faster than budget or headcount.

Licensing and ecosystem stance

The project is published under the MIT License, and it explicitly frames its future support model around ecosystem and community partnerships rather than traditional sponsorship flows.

More information in Github