gorkem-bwl
96b2266a9d
The gauge row on the infrastructure details page laid out memory, CPU
and one gauge per disk in a single flex row with no wrapping and no
overflow handling. Each gauge is capped at 260px, so on a host with
enough disks the row ran past the content column.
RootLayout sets overflow: "hidden" on that column, so the excess was
clipped outright rather than becoming scrollable - the later disks
rendered but could not be reached by any means.
Three changes, all scoped to this row:
flexWrap moves the overflow onto additional rows.
useFlexGap is required alongside it. MUI's Stack implements `spacing`
as `& > :not(style) ~ :not(style) { marginLeft }`, and that selector is
DOM-order based rather than line-aware, so the first card of each
wrapped row would carry a spurious 16px left margin and misalign
against the row above. useFlexGap switches to a real flex gap.
flexBasis on the children is what actually makes the line break.
BaseChart sets `flex: 1`, which expands to `flex: 1 1 0%`; wrapping is
decided by the sum of items' hypothetical main sizes, so with a zero
basis that sum is 0 and the row never overflows. The cards would
instead shrink to min-content (roughly the 70px gauge plus the widest
label) and stay on one cramped line. Giving each child a 260px basis
makes the row wrap at the intended card width.
The basis is applied through the row's own `& > *` selector rather than
by changing BaseChart, which has eight other consumers that default to
maxWidth: "100%" and would have had their layout altered.
The repeated 260 literals are now a named constant.
Only affects viewports at or above the md breakpoint; below it the
stack is already a column, where flexWrap is inert.
Claude-Session: https://claude.ai/code/session_01AbYLvwpEaZFXktHVcqrFRd
🇺🇸 English | 🇸🇦 العربية | 🇪🇸 Català | 🇨🇿 Čeština | 🇩🇪 Deutsch | 🇪🇸 Español | 🇫🇮 Suomi | 🇫🇷 Français | 🇮🇹 Italiano | 🇯🇵 日本語 | 🇧🇷 Português (Brasil) | 🇷🇺 Русский | 🇹🇭 ไทย | 🇹🇷 Türkçe | 🇺🇦 Українська | 🇻🇳 Tiếng Việt | 🇨🇳 简体中文 | 🇹🇼 繁體中文
Checkmate
An open source uptime and infrastructure monitoring application
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.
📚 Table of contents
- 📦 Demo
- 🔗 User's guide
- 🛠️ Installation
- 🚀 Performance
- 💚 Questions & Ideas
- 🧩 Features
- 🏗️ Screenshots
- 🏗️ Tech stack
- 🔗 A few links
- 🤝 Contributing
Demo
You can see the latest build of Checkmate in action.
The username is demouser@demo.com 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
Installation
The quickest way to run Checkmate is the reference Docker Compose file. It starts two services: the all-in-one Checkmate application image (ghcr.io/bluewave-labs/checkmate) and a separate MongoDB service.
What “all-in-one” means: the Checkmate application is packaged in a single image; MongoDB is not embedded in that image and remains required. The reference Compose file starts MongoDB for you. For custom deployments, configure
DB_CONNECTION_STRINGto use an external MongoDB instance.
curl -O https://raw.githubusercontent.com/bluewave-labs/checkmate/master/docker/docker-compose.yaml
JWT_SECRET="$(openssl rand -hex 32)" docker compose up -d
Then open http://localhost:52345. If the app is reached at another origin (domain or LAN IP), set CLIENT_HOST accordingly. To build the image yourself, run docker build -f docker/Dockerfile -t checkmate . from a checkout. For TLS, put any reverse proxy (Caddy, Traefik, nginx) in front of port 52345.
There are also 1-click installation options like Repocloud, Pikapods, Coolify, Elestio, K8s, Sive Host or Cloudzy.
Configuration
The image is configured entirely through environment variables on the server container:
| Variable | Required | Description |
|---|---|---|
DB_CONNECTION_STRING |
Yes | MongoDB connection string, e.g. mongodb://mongodb:27017/uptime_db |
JWT_SECRET |
Yes | Secret used to sign auth tokens; generate one with openssl rand -hex 32 |
CLIENT_HOST |
Yes | The URL users reach the app at, e.g. https://checkmate.example.com; used for CORS and for links in notifications and emails |
LOG_LEVEL |
No | Server log level: error, warn, info, or debug (default debug) |
The web client needs no configuration by default: it calls the API on the same origin it was served from (/api/v1). For setups where the defaults don't apply — for example, the API is reached through a different origin than the page — the server renders overrides into the client at runtime via these optional variables:
| Variable | Description |
|---|---|
CLIENT_CONFIG_API_BASE_URL |
Full base URL the client calls the API at, e.g. https://api.example.com/api/v1; defaults to same-origin /api/v1 |
CLIENT_CONFIG_CLIENT_HOST |
Origin used when the client builds absolute links (invites, status pages); defaults to the browser's current origin |
CLIENT_CONFIG_LOG_LEVEL |
Browser console log level: error, warn, info, or debug (default error) |
Upgrading from an older image? The
UPTIME_APP_*variables (UPTIME_APP_API_BASE_URL,UPTIME_APP_CLIENT_HOST,UPTIME_APP_LOG_LEVEL) are no longer read. In most setups no replacement is needed — the same-origin defaults cover them; if you pointed the client at a different origin, use theCLIENT_CONFIG_*equivalents above. Thecheckmate-client,checkmate-backend,checkmate-mongo, andcheckmate-backend-mono-multiarchimages are no longer updated — switch toghcr.io/bluewave-labs/checkmate, keeping your existing MongoDB service and data volume.
See full installation instructions in the 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)
- Several monitoring options: Uptime, Docker, Ping, SSL, Port, Game server
- Page speed monitoring
- Infrastructure monitoring (memory, disk usage, CPU performance, network etc) - requires Capture agent
- Selective disk monitoring with mountpoint selection
- Incidents at a glance
- Status pages with 4 beautiful themes
- E-mail, Webhooks, Discord, Slack, PagerDuty, Matrix, Rocket.Chat, Microsoft Teams, Telegram, Pushover, Twilio (SMS) notifications
- Scheduled maintenance
- JSON query monitoring
- Multi-language support for Arabic, Chinese (Simplified), Chinese (Traditional, Taiwan), Czech, English, Finnish, French, German, Japanese, Portuguese (Brazil), Russian, Spanish, Thai, Turkish, Ukrainian, and Vietnamese
Monitor Lifecycle
- A monitor executes a check (HTTP / ping / port / hardware via Capture agent)
- The result is stored (success/failure + response time)
- Recent check results are evaluated against the monitor's configured status change threshold
- If the monitor's status change threshold is met and the current status is not equal to the previous status, the monitor's state changes (e.g.
initializing,up,down,breached) - Upon a state change: an incident is either created or resolved, depending on the monitor's current status
- Notifications are triggered based on configuration
Screenshots
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 and Mert 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 almost 11K+ stars and attracted 150+ 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:
- Star this repo :)
- Check Contributor's guideline. First timers are encouraged to check
good-first-issuetag. - Read a detailed structure of Checkmate if you would like to deep dive into the architecture.
- Open an issue if you believe you've encountered a bug.
- Check for good-first-issue's if you are a newcomer.
- Make a pull request to add new features/make quality-of-life improvements/fix bugs.
- Check out this interactive walkthrough of the
Checkmatecodebase on CodeCanvas here. To refine existing dataflow simulation or create new ones, follow the quick tutorial here.