Stability is easier to manage when you can score it
Platform stability usually gets discussed in vague terms. The store "feels stable" or "feels shaky," which is impossible to track or act on.
A lightweight scorecard fixes that. By pulling a handful of concrete signals from the logs, cron, and indexers, you can turn a vague feeling into a repeatable score you can watch over time.
This article covers the signals worth scoring, how to read each one, and how to combine them into a simple stability picture you can run on a schedule.
Why a scorecard beats a gut feeling
A gut feeling about stability is reactive. It only changes after something breaks, by which point the problem is already customer-facing.
A scorecard is proactive, because the signals it reads move before an outage. Cron falling behind, errors climbing, and indexers going stale all happen before the store visibly fails.
Scoring those signals turns them into an early warning. A score trending the wrong way is a prompt to look, well before the trend becomes an incident.
The exception log error rate
The first signal is how much the store is failing. The frequency of errors in exception.log, read as a rate rather than a raw count, is a direct measure of instability.
Rank the log by signature and count, and watch the total and the top signatures over time. A rate that is climbing, or a new high-frequency signature appearing, is the log telling you something changed.
This is not about zero errors, which no busy store achieves. It is about the trend and the top offenders staying flat, not growing.
Cron health
Cron is the second signal, because so much depends on it. The counts of missed and errored jobs in cron_schedule show whether background work is keeping up.
Group the schedule table by status and score the missed and error counts. A healthy store shows mostly success with a small pending queue, and any drift from that shape is worth a point against the score.
Indexer status
The third signal is whether the storefront data is current. bin/magento indexer:status reports whether each indexer is valid or invalid, and a persistently invalid indexer means stale data reaching customers.
An occasional invalid status during a reindex is normal. An indexer stuck invalid, or repeatedly falling behind, is a stability problem that shows up as wrong prices, stale stock, or missing search results.
Scoring the indexers is simple: valid is good, and anything stuck invalid counts against the store. It ties directly to cron, since scheduled indexing depends on cron running.
Supporting signals
A few more signals round out the picture without much effort. Each is quick to read and adds a dimension the others miss:
- The size of
cron_schedule, since a bloated table points at cron maintenance failing. - Disk and inode usage, because a full partition is a sudden outage regardless of anything else.
- Message-queue depth, since a growing backlog signals a stuck or overwhelmed consumer.
None of these needs a monitoring platform. Each is a single command or query, which is what keeps the scorecard lightweight.
Combining the signals into a score
The scoring does not need to be sophisticated. A simple green, yellow, red per signal, combined into an overall status, is enough to be useful.
Green across the board is a healthy store. A yellow or red on any signal is a prompt to investigate that area, and several reds together describe a store under real stress.
The value is not precision, it is consistency. The same simple rubric, applied the same way each time, makes the trend visible even if any single reading is rough.
Run it on a schedule
A scorecard is only useful if it runs regularly. Captured once and forgotten, it is a snapshot; run weekly, it becomes a trend.
Automating the collection, even as a simple script that gathers the counts and prints the score, turns it into something the team sees without effort. The trend over weeks is what turns individual readings into an early-warning system.
This is the same discipline as post-deploy verification, applied continuously. A store that scores its stability weekly finds problems on its own schedule rather than on a customer's.
From feeling to evidence
A stability scorecard replaces "the store feels shaky" with a set of readings you can point at. Logs, cron, and indexers between them describe most of what stability means, and they are all cheap to read.
Knowing your error rate, your cron health, and your indexer status, tracked over time, turns stability into something you manage rather than hope for. Building that scorecard is a practical capstone to any stability review.