A health dashboard turns scattered checks into one view
A store's health signals live in many places: cron in a database table, indexers in a CLI command, errors in log files, disk in the operating system. Checking them one at a time is why they get checked rarely.
A lightweight platform health dashboard pulls those signals into one view that anyone can read at a glance. It is the difference between health you have to go dig for and health that is always visible.
This article covers what belongs on such a dashboard, how to gather the signals, and how to keep it lightweight enough that it actually gets built and used.
Why continuous beats occasional
A point-in-time audit tells you how the store is today. A dashboard tells you how it is changing, which is often the more useful information.
Trends catch problems that a single reading misses. A cron miss count creeping up, a disk slowly filling, or an error rate climbing are all visible on a dashboard well before they become incidents.
Continuous visibility also changes behavior. A signal that is always on screen gets noticed, while one that requires running a command gets checked after something already broke.
The signals worth showing
A useful dashboard focuses on the signals that predict problems. A handful covers most of what matters:
- Cron health, from the status counts in
cron_schedule. - Indexer status, valid or invalid, per indexer.
- Error rate, from the frequency of new entries in
exception.log. - Disk and inode usage, with headroom shown.
- Cache hit rates for the full-page cache and Redis.
- Queue depth, if the store uses message queues.
Each is a leading indicator, moving before customers feel the problem. Together they describe the store's operational health on one screen.
Business signals belong there too
The most important signal is not technical. Orders per hour is the truest measure of whether the store is actually working, because a broken checkout shows up there first.
Adding order rate, and payment failure rate alongside it, turns a technical dashboard into a business one. It answers the question that matters most: is the store making money right now.
Gathering the signals
The signals come from commands and queries the store already answers. Cron and indexer status come from database queries and CLI commands, error rate from parsing the log, and disk from the operating system.
A simple collector script can gather these on a schedule and write them somewhere a dashboard can read. The collection does not need to be sophisticated, only regular and consistent.
The point is to automate the gathering so the dashboard stays current without anyone running anything. A dashboard that requires manual updates is just a report with extra steps.
Keep it lightweight
The trap with dashboards is over-building them. A monitoring platform with hundreds of metrics is powerful and often never finished, because the effort to build it exceeds the will to do so.
A lightweight dashboard showing a dozen signals, built in a day, delivers most of the value. The goal is visibility of the signals that matter, not completeness for its own sake.
Start with the handful of leading indicators and the order rate. That covers the failures that actually happen, which is what a dashboard is for.
Set thresholds and alerts
A dashboard nobody looks at is only half a solution. Pairing it with alerts on the important signals turns passive visibility into active warning.
Alert on the conditions that matter: cron falling behind, disk crossing a threshold, error rate spiking, or order rate dropping. The alert brings attention to the dashboard exactly when it is needed, rather than relying on someone happening to look.
The thresholds should reflect real trouble, not noise. An alert that fires constantly gets ignored, so tune the thresholds to the conditions that genuinely warrant a look.
Start with what broke last
The fastest way to make a useful dashboard is to build backward from your last incidents. Whatever took the store down or degraded it recently is exactly what the dashboard should have shown.
A store that suffered a full-disk outage adds disk and inode monitoring first. One that had a checkout failure adds order rate and payment failure rate. The incident history is a ready-made list of the signals worth watching.
This keeps the dashboard grounded in real failures rather than theoretical completeness. Each signal earns its place by mapping to something that actually went wrong, which is the opposite of building an exhaustive dashboard nobody finishes.
Visibility you can act on
A platform health dashboard is the continuous companion to a point-in-time audit. The audit tells you where you stand today, and the dashboard keeps that answer current and visible.
Knowing your store's health at a glance, with the signals that predict problems and the order rate that measures success, turns platform health from something you check into something you can always see. Building that visibility is a practical outcome of a stability and observability review.