Repository: bluewave-labs/Checkmate
Stars: 9637
CLAUDE.md
CLAUDE.md
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
Project Overview
Checkmate is an open-source uptime and infrastructure monitoring application. It monitors server hardware, uptime, response times, and incidents with real-time alerts. The companion agent Capture provides infrastructure metrics (CPU, RAM, disk, temperature).
Development Commands
Client (React/Vite)
cd client
npm install
npm run dev # Start dev server at http://localhost:5173
npm run build # TypeScript check + production build
npm run lint # ESLint (strict, max-warnings 0)
npm run format # Prettier formatting
npm run format-check # Check formattingServer (Node.js/Express)
cd server
npm install
npm run dev # Start with hot-reload (nodemon + tsx) at http://localhost:52345
npm run build # TypeScript compile + path alias resolution
npm run test # Run Mocha tests with c8 coverage
npm run lint # ESLint v9
npm run lint-fix # Auto-fix lint issues
npm run format # Prettier formattingDocker Development
cd docker/dev
./build_images.sh
docker run -d -p 27017:27017 -v uptime_mongo_data:/data/db --name uptime_database_mongo mongo:6.0Environment Setup
Server .env (minimum required)
CLIENT_HOST="http://localhost:5173"
JWT_SECRET="my_secret_key_change_this"
DB_CONNECTION_STRING="mongodb://localhost:27017/uptime_db"
TOKEN_TTL="99d"
ORIGIN="localhost"
LOG_LEVEL="debug"Client .env
VITE_APP_API_BASE_URL="http://localhost:52345/api/v1"
VITE_APP_LOG_LEVEL="debug"Architecture
Monorepo Structure
-
/client - React 18 + TypeScript + Vite + MUI frontend-
/server - Node.js 20+ + Express + TypeScript backend-
/docker - Multi-environment Docker configs (dev, staging, prod, arm, mono)Backend Layers
server/src/
βββ controllers/ # Route handlers (authController, monitorController, etc.)
βββ service/ # Business logic
β βββ business/ # Core monitoring logic
β βββ infrastructure/ # Server/system utilities
β βββ system/ # App-level settings
βββ db/
β βββ models/ # Mongoose schemas (Monitor, Check, Incident, User, etc.)
β βββ migration/ # Database migrations (run on startup)
β βββ modules/ # Database-specific modules
βββ middleware/v1/ # verifyJWT, rateLimiter, sanitization, responseHandler
βββ routes/v1/ # API route definitions
βββ validation/ # Joi input validation schemas
βββ repositories/ # Data access layerFrontend Structure
client/src/
βββ Components/ # Reusable UI components
βββ Pages/ # Page components (Auth, Uptime, Infrastructure, Incidents, etc.)
βββ Features/ # Redux slices (Auth, UI)
βββ Hooks/ # Custom React hooks
βββ Utils/ # Utilities (NetworkService.js is main API client)
βββ Validation/ # Input validation
βββ locales/ # i18n translationsAPI
- Base URL:
/api/v1- Documentation:
http://localhost:52345/api-docs (Swagger UI)- OpenAPI spec:
/server/openapi.jsonKey Technologies
- State Management: Redux Toolkit + Redux-Persist
- Data Fetching: SWR + Axios
- Database: MongoDB with Mongoose ODM
- Queue/Cache: Redis + BullMQ + Pulse (cron scheduling)
- i18n: i18next + react-i18next (translations via PoEditor)
---
Backend Architecture Patterns
Repository Pattern & Separation of Concerns
The backend enforces a strict three-layer separation between HTTP handling, business logic, and data access:
Request β Controller β Service β Repository β MongoDB (Mongoose)- Controllers (/controllers) handle HTTP concerns only: parsing request params, calling the appropriate service, and returning a response via the responseHandler middleware. They contain no business logic.
- Services (/service/business) contain all business logic: deciding whether an incident should be created, whether a notification should fire, what state a monitor is in, etc.
- Repositories (/repositories) are the sole layer that talks to MongoDB through Mongoose. They expose clean, reusable query methods (e.g. findByMonitorId, createCheck) so that services never construct raw DB queries directly.
This separation makes each layer independently testable and keeps Mongoose-specific code out of business logic. When adding a new feature, the pattern to follow is: add a repository method for any new DB query, call it from a service, and expose it via a controller route.
Monitoring Flow: From Check to Notification
Background monitoring runs on a scheduled queue, not on the HTTP request cycle. The high-level flow for uptime monitoring is:
Pulse (cron) β BullMQ Job β StatusService
βββ performs HTTP/port/ping check
βββ saves Check via CheckRepository
βββ evaluates monitor state change
β βββ calls IncidentService (create / resolve incident)
βββ calls NotificationService (email, Slack, Discord, webhook)1. Pulse (cron scheduler) enqueues a job into a BullMQ queue for each active monitor at its configured interval.
2. A BullMQ worker picks up the job and calls StatusService, which performs the actual check (HTTP request, TCP port probe, ping, etc.).
3. The result is persisted as a Check document via the repository layer.
4. StatusService compares the new result against the monitor's previous state. If the monitor transitions from up β down (or down β up), it delegates to IncidentService to open or resolve an Incident document.
5. On a state change, NotificationService reads the monitor's configured Notification documents and dispatches alerts to all enabled channels (email, Discord, Slack, webhooks).
Queue System (BullMQ + Redis)
Redis serves two roles: job queue storage for BullMQ and ephemeral caching. BullMQ manages concurrency, retries, and backpressure for monitoring jobs, ensuring checks are processed reliably even under load.
- Each monitor type (HTTP, port, ping, infrastructure) maps to its own queue worker so failures in one type don't block others.
- Job scheduling interval is driven by the interval field on the Monitor model.
- Failed jobs are retried with configurable backoff before being moved to a dead-letter state.
- Redis is also used to cache frequently read data (e.g. aggregated stats) to reduce MongoDB query pressure.
When working on anything related to check scheduling, incident lifecycle, or notifications, trace the flow starting from the relevant BullMQ worker rather than from the controller layer.
---
Code Conventions
Internationalization
All user-facing strings must use the translation function:
t('your.key') // Never hardcode UI stringsBranching
- Always branch from
develop (not master)- Use descriptive names:
feat/add-alerts, fix/login-error- PRs target
develop branchFormatting
- Client: Prettier with
printWidth: 90, tabs, double quotes- Server: Prettier with
printWidth: 150, tabs, double quotes- Both use ESLint with strict settings
Testing
Server tests use Mocha + Chai + Sinon:
npm test # Run all tests with coverage
npm test -- --grep "pattern" # Run specific testsTest files:
server/tests//*.test.jsDatabase Models
Key Mongoose models in /server/src/db/models/:
- Monitor - Monitoring configuration (website, infrastructure, port, etc.)
- Check - Individual monitoring check results
- Incident - Downtime incidents
- User - User accounts
- Team - Team/workspace management
- StatusPage - Public status pages
- Notification - Alert configuration (email, Discord, Slack, webhooks)
- MaintenanceWindow - Scheduled maintenance periods
- AppSettings - Global application settings
README.md
<p align=center> <a href="https://trendshift.io/repositories/12443" target="_blank"><img src="https://trendshift.io/api/badge/repositories/12443" alt="bluewave-labs%2Fcheckmate | Trendshift" style="width: 250px; height: 55px;" width="250" height="55"/></a></p>









<h1 align="center"><a href="https://bluewavelabs.ca" target="_blank">Checkmate</a></h1>
<p align="center"><strong>An open source uptime and infrastructure monitoring application</strong></p>
<img width="1660" alt="image" src="https://github.com/user-attachments/assets/b748f36d-a271-4965-ad0a-18bf153bbee7" />
This repository contains both the frontend and the backend of Checkmate, an open-source, self-hosted monitoring tool for tracking server hardware, uptime, response times, and incidents in real-time with beautiful visualizations. Checkmate regularly checks whether a server/website is accessible and performs optimally, providing real-time alerts and reports on the monitored services' availability, downtime, and response time.
Checkmate also has an agent, called Capture, to retrieve data from remote servers. While Capture is not required to run Checkmate, it provides additional insights about your servers' CPU, RAM, disk, and temperature status. Capture can run on Linux, Windows, Mac, Raspberry Pi, or any device that can run Go.
Checkmate has been stress-tested with 1000+ active monitors without any particular issues or performance bottlenecks.
If you would like to sponsor a feature, see this link.
π Table of contents
- π¦ Demo
- π User's guide
- π οΈ Installation
- π Performance
- π Questions & Ideas
- π§© Features
- ποΈ Screenshots
- ποΈ Tech stack
- π A few links
- π€ Contributing
- π° Our sponsors
Demo
You can see the latest build of Checkmate in action. The username is [email protected] and the password is Demouser1! (just a note that we update the demo server from time to time, so if it doesn't work for you, please ping us on the Discussions channel).
User's guide
Usage instructions can be found here.
Prerequisites
- Docker installed
- Git installed
Installation
See installation instructions in Checkmate documentation portal.
Alternatively, you can also use Coolify, Elestio, K8s, Sive Host (South Africa), Cloudzy or Pikapods to quickly spin off a Checkmate instance. If you would like to monitor your server infrastructure, you'll need Capture agent. Capture repository also contains the installation instructions.
Using a Custom CA
If you need to monitor internal HTTPS endpoints with certificates from private Certificate Authorities (like Smallstep), see our Custom CA Trust Guide for Docker configuration options.
For more documentation, see the docs directory.
Performance
Thanks to extensive optimizations, Checkmate operates with an exceptionally small memory footprint, requiring minimal memory and CPU resources. Hereβs the memory usage of a Node.js instance running on a server that monitors 323 servers every minute:
You can see the memory footprint of MongoDB and Redis on the same server (398Mb and 15Mb) for the same amount of servers:
Questions & Ideas
If you have any questions, suggestions or comments, you have several options:
- Discord channel (preferred)
- GitHub Discussions (we check here from time to time)
Feel free to ask questions or share your ideas - we'd love to hear from you!
Features
- Completely open source, deployable on your servers or home devices (e.g Raspberry Pi 4 or 5)
- Website monitoring
- Page speed monitoring
- Infrastructure monitoring (memory, disk usage, CPU performance, network etc) - requires Capture agent
- Selective disk monitoring with mountpoint selection
- Docker monitoring
- Ping monitoring
- SSL monitoring
- Port monitoring
- Game server monitoring (3.0)
- Incidents at a glance
- Status pages
- E-mail, Webhooks, Discord and Slack notifications
- Scheduled maintenance
- JSON query monitoring
- Multi-language support for English, German, Japanese, Portuguese (Brazil), Russian, Turkish, Ukrainian, Vietnamese, Chinese (Traditional, Taiwan)
Short term roadmap:
- Plugins that will help Checkmate get any information from a remote service (e.g database, etc)
- Better notifications
- Network monitoring
- ..and a few more features
If you would like to sponsor an additional feature, see this page.
Screenshots
<p>
<img width="1628" alt="image" src="https://github.com/user-attachments/assets/2eff6464-0738-4a32-9312-26e1e8e86275" />
</p>
<p>
<img width="1656" alt="image" src="https://github.com/user-attachments/assets/616c3563-c2a7-4ee4-af6c-7e6068955d1a" />
</p>
<p>
</p><img width="1652" alt="image" src="https://github.com/user-attachments/assets/7912d7cf-0d0e-4f26-aa5c-2ad7170b5c99" />
</p>
<p>
<img width="1652" alt="image" src="https://github.com/user-attachments/assets/08c2c6ac-3a2f-44d1-a229-d1746a3f9d16" />
</p>
Tech stack
- ReactJs
- MUI (React framework)
- Node.js
- MongoDB
- Recharts
- Lots of other open source components!
A few links
- If you would like to support us, please consider giving it a β and click on "watch".
- Have a question or suggestion for the roadmap/featureset? Check our Discord channel or Discussions forum.
- Need a ping when there's a new release? Use Newreleases, a free service to track releases.
- Watch a Checkmate installation and usage video
Contributing
We are Alex (team lead), Gorkem, Aryaman, Mert and Karen helping individuals and businesses monitor their infra and servers.
We pride ourselves on building strong connections with contributors at every level. Despite being a young project, Checkmate has already earned 7000+ stars and attracted 90+ contributors from around the globe.
Our repo is starred by employees from Google, Microsoft, Intel, Cisco, Tencent, Electronic Arts, ByteDance, JP Morgan Chase, Deloitte, Accenture, Foxconn, Broadcom, China Telecom, Barclays, Capgemini, Wipro, Cloudflare, Dassault SystΓ¨mes and NEC, so donβt hold back β jump in, contribute and learn with us!
Here's how you can contribute:
0. Star this repo :)
1. Check Contributor's guideline. First timers are encouraged to check good-first-issue tag.
2. Read a detailed structure of Checkmate if you would like to deep dive into the architecture.
3. Open an issue if you believe you've encountered a bug.
4. Check for good-first-issue's if you are a newcomer.
5. Make a pull request to add new features/make quality-of-life improvements/fix bugs.
6. Check out this interactive walkthrough of the Checkmate codebase on CodeCanvas here. To refine existing dataflow simulation or create new ones, follow the quick tutorial here.
<a href="https://github.com/bluewave-labs/checkmate/graphs/contributors">
<img src="https://contrib.rocks/image?repo=bluewave-labs/checkmate" />
</a>

Our sponsors
Thanks to Gitbook for giving us a free tier for their documentation platform, and Poeditor providing us a free account to use their i18n services. If you would like to sponsor Checkmate, please send an email to [email protected]
If you would like to sponsor a feature, see this page.