Checkmate tells you the moment a container stops running, next to the uptime monitors for the services inside it. Health states, restart timelines and per-container stats are being built now.
A container can exit at 3am and be restarted by its policy before anyone notices, or stay down until a customer does. Docker monitors track container state on the schedule you set, so either way there is a record and an alert.
If an image ships a HEALTHCHECK, the result is already collected with each check. Showing unhealthy as its own state in the dashboard is next on the list.
Restart events will be reported alongside host metrics, so a container bouncing every few minutes stops hiding behind its restart policy.
The pattern belongs in history: one restart after a deploy is noise, 40 an hour is a bug. This view is in the works.
Design preview: this view is being built.
The Capture agent already collects per-container CPU, memory, network and disk I/O. The dashboard view that puts it next to the host's own metrics is being built.
Once it lands, 'which one is it' beats SSHing in to run docker stats while the pager keeps buzzing.
Design preview: this view is being built.
Your services live in containers on one or two boxes. Watch all of them without adding a heavyweight orchestration layer.
A VPS running a compose stack is a common production setup. Container health, host health and endpoint uptime in one dashboard covers it.
20 containers accumulate fast. Get a straight answer to which ones are up, unhealthy or stuck in a restart loop.
Docker monitors sit next to HTTP, ping and the rest. Add one per container you care about, set the interval and route its alerts like any other monitor.
The HEALTHCHECK your image defines is the best signal of container wellbeing. Checkmate already stores the result with each check; a first-class unhealthy state in the dashboard is upcoming.
The container being up and the service inside answering are different facts. Run a Docker monitor next to an HTTP monitor for the same app, and know which layer broke.
The whole platform ships as a small set of containers with a compose file. Monitoring containers from containers is the normal setup here.
Add a Docker monitor for a container. Checkmate checks whether it is running on the schedule you set, records the history and alerts through your notification channels the moment it stops.
Status changes alert immediately, so a container that stops fires your channels. A dedicated restart-event timeline that makes loops visible as a pattern is upcoming.
Not yet in the dashboard. The Capture agent already collects per-container CPU, memory, network and disk I/O. The view that displays it next to host metrics is being built.
No. Checkmate watches containers and hosts, not orchestrator control planes. If you run plain Docker or compose stacks, it fits. For Kubernetes-native observability you'll want a Kubernetes-native tool.
Yes. It ships as a small set of containers: pull the compose file, run it and the dashboard is up. About 1 GB of RAM on any Docker host is enough to start.
Yes. Open source under AGPL-3.0, self-hosted, with no container or host limits.
Websites and APIs checked from 6 continents.
ICMP reachability for anything with an IP.
Databases, mail and SSH watched at the socket.
Records resolved against the resolver you choose.
Handshake checks for ws:// and wss:// endpoints.
The standard health protocol, checked on schedule.
More than 100 game types over native protocols.
CPU, memory, disk and network via the Capture agent.
Lighthouse scores and Core Web Vitals on a schedule.
Certificate and domain expiry on every HTTPS monitor.
Branded public pages served from your own instance.
12 native channels, from email to PagerDuty.
Every outage recorded, resolved and explained.
All featuresCheckmate is open source under AGPL-3.0. Self-host it and this feature ships free, on your servers, with your data.