checkcle

The Problem

CheckCle solves the operational gap between uptime monitoring and infrastructure visibility. Most monitoring tools give you either service uptime or server metrics, rarely both in one place. Teams end up stitching together multiple tools and still lack a unified view of incidents, maintenance windows, and status pages.

What This Does

CheckCle is a self-hosted monitoring platform combining uptime checks (HTTP, DNS, Ping, TCP), infrastructure server monitoring (CPU, RAM, disk), and incident management. The application/ directory holds a React/TypeScript frontend (290 TSX files, 265 TS files) with dashboards, Docker container views, and public status pages. The server/ directory contains Go backends, including core_backend-server (598 code files) and service-operation, handling check execution and data persistence.

The platform supports distributed regional monitoring via agents, scheduled maintenance windows, and notifications through email, Telegram, Discord, Slack, and Matrix. The application/public/upload/notification/ directory shows the supported channels. Docker deployment is first-class, with docker-compose.yml at the root and separate Dockerfiles for frontend and backend.

How It Is Wired

The call graph shows 618 internal modules with 670 import edges and zero circular dependencies—a clean structure. The frontend entry point is application/index.html → application/src/App.tsx, which routes through application/src/api/index.ts for API calls and application/src/api/realtime/index.ts for real-time updates. The application/src/App component has the highest instability (0.95), importing 19 modules—it's the composition root but changes there ripple outward.

The backend's effect surface lives in the Go modules. The server/core_backend-server/apis/ directory handles HTTP endpoints, with the largest files being test suites (collection_test.go at 1532 lines, record_auth_with_oauth2_test.go, record_crud_test.go). The service-operation module handles background check execution and notification dispatch.

The highest-blast-radius module is application/src/services/types/maintenance.types.ts—12 modules depend on it (Ca=12, Ce=0). It's a leaf type definition, so its stability is good, but any breaking change to those types forces updates across a dozen consumers.

One notable wiring gap: the server/service-operation/.env file exists in the repo, flagged as a potential committed secret. This is a security concern worth verifying immediately.

How To Use It

git clone https://github.com/moses-y/checkcle
cd checkcle

# Docker Compose (recommended)
docker compose up -d
# Access http://localhost:8090
# Default: admin@example.com / Admin123456

# Or build the frontend separately
cd application
npm install
npm run dev

Configuration lives in environment variables and the server/service-operation/.env file. The docker-compose.yml maps host port 8090 to the container and mounts /opt/pb_data for persistent storage. The frontend uses Vite (application/vite.config.ts) and Tailwind for styling.

Real-World Use

A DevOps team running a SaaS product deploys CheckCle on a single VM via Docker. They configure HTTP checks for their API endpoints, install the agent script on Linux servers for CPU/memory metrics, and set up a public status page at status.company.com. When a server's disk fills, CheckCle triggers a Discord notification, creates an incident record, and updates the status page—all without a separate incident management tool.

Code Health & Issues

Static analysis found 228 issues: 28 high, 200 medium, across 5 kinds. The most significant:

• High - Deep nesting (48 instances) - application/src/components/dashboard/StatusCards.tsx, EditServerDialog.tsx, ResponseTimeChart.tsx reach indentation depth 8. Control flow is hard to follow; early returns would help.
• High - Duplicated code (1543 repeated 6-line blocks across 284 files) - sendTestEmail.ts and testEmail.ts are near-identical. DRY refactoring is overdue.
• High - Oversized files (7) - The three Go test files exceed 1500 lines each. These are hard to maintain and slow to run.
• Medium - Hub module - maintenance.types.ts has 12 dependents; keep it stable.
• Medium - High branching density (3 files) - IncidentDetailDialog.tsx has 16 branch points over 46 lines.

The repo has CI (GitHub Actions), tests (264 files), and a license. The committed .env file in server/service-operation/ is the most urgent concern—rotate any secrets in it and add it to .gitignore.

The Bottom Line

CheckCle is a functional, full-featured monitoring platform with a clean module graph and zero circular dependencies—a solid foundation. The duplicated code and oversized test files suggest the codebase grew quickly, but nothing here is blocking adoption. Teams wanting a self-hosted alternative to UptimeRobot or HetrixTools with built-in incident management should evaluate it; the committed .env file needs immediate attention before production use.