You can score your own store before anyone else does
Most store owners find out their platform was unhealthy the hard way, during an outage or a failed upgrade. It does not have to work that way, because most of the signals are readable on demand.
A structured self-audit turns "the store feels fine" into a set of scores you can act on. It will not replace a forensic review, but it will tell you where you stand and where to look first.
This article walks through scoring your store across the dimensions that matter: performance, stability, security, infrastructure, checkout, and technical debt, with concrete checks for each.
Why a score beats a feeling
A feeling about store health is reactive and vague. It only sharpens after something breaks, which is exactly too late.
A score is specific and repeatable. It names what is healthy and what is not, and running it again later shows whether things are improving or drifting.
The goal is not a perfect number. It is a consistent, honest snapshot that points at the areas most in need of attention, ranked rather than guessed.
How to score each check
Keep the scoring simple so it actually gets done. A green, yellow, red per check is enough, where green is healthy, yellow is worth watching, and red is a problem to address.
Score each dimension below, then look at the pattern. A store with reds scattered across many dimensions is in a different situation than one with a single weak area.
Performance: is the store actually fast
Performance scoring starts with the cache and the database, since those decide most of it. Check that the store runs in production mode, that the full-page cache uses Varnish, and that the cache hit rates are high.
Read the full-page cache hit rate and the Redis hit rate directly. A full-page cache below a healthy hit rate, or a Redis cache that is evicting, is a yellow or red that explains a slow storefront.
On the database side, confirm the buffer pool is sized to the working set and the slow query log is not full of frequent offenders. A store scanning tables and missing its cache scores red on performance no matter how fast the hardware is.
Stability: is the store failing quietly
Stability is read from the logs, cron, and indexers. Rank exception.log by frequency and note whether the top signatures are growing, which is a direct instability signal.
Check cron health by grouping cron_schedule by status, and check indexer state with bin/magento indexer:status. Piles of missed or errored cron jobs, or indexers stuck invalid, are reds that mean background work is failing.
A self-audit scorecard turns six dimensions of store health into a single readable snapshot.
Security: are you carrying known risk
Security scoring is about known, fixable exposure. Confirm the Magento version and its security patch level, and check whether the version is still supported at all.
Run composer audit to list dependencies with disclosed vulnerabilities, and confirm the PHP version still receives security fixes. A store several patches behind, on an end-of-life version, or on unsupported PHP scores red here.
Add a check for core file integrity and unexpected admin exposure. Hand-edited vendor files and an unprotected admin path are both security reds worth finding before an attacker does.
Infrastructure: is the foundation sound
Infrastructure scoring covers the layers Magento runs on. Confirm sessions and cache live in Redis, that disk and inode usage have headroom, and that file ownership follows the two-user model.
Check that logs are rotated and debug logging is off in production, since an unbounded log is a latent outage. A store one full disk away from downtime scores red regardless of how the application looks.
Also confirm the environment matches version control, with no config or code drift. A production that has quietly diverged from staging is an infrastructure yellow at best.
Checkout: does the money path work
Checkout gets its own dimension because it is where revenue lives. Confirm that payment and shipping integrations have sane timeouts and are not leaving orders stranded in pending_payment.
Check the quote tables for bloat and the inventory reservations for consistency, since both affect whether checkout behaves correctly. A pile of stuck orders or drifting salable quantity is a checkout red with a direct revenue cost.
Walk the critical path yourself: add to cart, checkout, pay. A checkout that works in a manual test is table stakes, and any friction found there scores against the store immediately.
Technical debt: how expensive is the store to change
The last dimension is how much the store costs to maintain and upgrade. Count the custom modules and third-party extensions, and note how many are abandoned, outdated, or heavily coupled to core through preferences and around-plugins.
Check the database size against the order history, since a database many times larger than the business justifies is debt in the form of bloat. Read whether upgrades have been kept current or deferred for years.
A store with many abandoned modules, a bloated database, and a version far behind scores red on debt, which predicts expensive, risky changes ahead.
Frontend performance, not just backend
Backend speed is only half of what customers feel. The frontend, especially on Luma themes, can be slow even when the server responds quickly, because of heavy JavaScript and render-blocking assets.
Score the delivered page weight and the core loading metrics on a few key pages using browser tools. A fast server behind a heavy, poorly bundled frontend still gives customers a slow experience, and that scores against performance.
This matters for both users and search ranking. A store that scores green on backend response but red on frontend weight is optimizing the half customers notice least.
Observability as its own check
A dimension worth scoring is whether you can even see problems. A store with only uptime monitoring is blind to failed checkouts, dead cron, and errors that never reach the Magento logs.
Score your observability by asking three questions: can you tell the store is up, can you tell it is actually working, and when it breaks, can you tell why. Gaps in any of those are yellows or reds that make every other problem harder to catch.
This is the meta-dimension. Poor observability does not just score badly on its own; it means your scores on everything else are less trustworthy, because you may not be seeing the failures.
Data quality is a hidden dimension
The numbers a store reports are only useful if they are real. Bot registrations, spam carts, and card-testing traffic inflate customer counts and skew conversion and abandonment metrics.
Score whether your registration, order, and cart data reflect real customers. A sudden mismatch between account growth and actual orders, or quote tables growing far faster than sales, points at automated abuse polluting the data.
This dimension is easy to miss because the store still functions. But a store making decisions on bot-inflated numbers is scoring green on data it cannot actually trust.
A concrete checklist to run
To make the scoring practical, here is a checklist of specific checks, each a command or a query you can run. Score each green, yellow, or red:
- Deploy mode is production, confirmed with
bin/magento deploy:mode:show. - Full-page cache uses Varnish, and its hit rate is high.
- Redis backs cache and sessions, on separate databases, with low evictions.
- Cron is healthy, with few missed or errored rows in
cron_schedule. - Indexers are valid, per
bin/magento indexer:status. - The Magento version is supported and current on security patches.
composer auditreports no unpatched vulnerabilities.- PHP is a supported version still receiving security fixes.
- Disk and inodes have headroom, per
df -handdf -i. - Logs are rotated and debug logging is off in production.
- The database size is proportional to the order history, not many times larger.
- No orders are stranded in
pending_payment, and reservations are consistent.
Each of these maps to a specific problem covered in depth elsewhere. The checklist is the fast pass; the depth is there when a check comes back red.
Turning scores into a plan
A scored store is only useful if the scores drive action. Order the reds by blast radius, so a checkout or security red comes before a slow admin grid.
Then work down the list, fixing the highest-impact reds first and re-scoring as you go. The self-audit gives you the ranked worklist that turns a vague concern into a sequence of concrete fixes.
This is the same prioritization a formal audit produces, applied to what you can measure yourself. It will not catch everything, but it will catch the obvious things in the right order.
Patterns the scores reveal
The distribution of the scores tells a story on its own. A single isolated red is usually a specific, fixable problem, and the rest of the store is sound.
Reading the pattern is as valuable as the individual scores. It tells you whether you are looking at a targeted fix or a store that needs structural attention.
Automate the collection
Most of these checks are commands and queries, which means they can be scripted. A simple script that gathers the values and prints the scores turns a manual audit into a repeatable one.
Automated, the self-audit can run on a schedule, and the trend over time becomes visible. A dimension drifting from green toward red is an early warning you gave yourself, weeks before it would have become an incident.
The automation does not have to be sophisticated. Even a shell script that runs the commands and flags anything outside a healthy range is enough to make the scorecard a habit rather than a one-time exercise.
Combining the dimensions
With each dimension scored, the overall picture emerges from the pattern. All green is a genuinely healthy store, and a single red points at one area to fix.
Several reds across dimensions describe a store that has been maintained reactively, where the problems are likely connected. That pattern is the signal that the store needs structured attention, not a single fix.
Scoring every dimension together makes the weak areas, and the overall shape, obvious at a glance.
What the self-audit can and cannot do
A self-audit is a real tool with real limits. It reliably tells you where the obvious problems are, using signals the store already exposes, and that alone is worth the hour it takes.
What it cannot do is find the subtle, interacting causes that only show up under expert investigation. A red on stability tells you the store is failing; it does not always tell you why, which is where a forensic review goes deeper.
Used well, the self-audit is the triage step. It tells you whether the store is healthy, and if not, which dimensions need the deeper look.
Score it honestly
The self-audit only works if you score it honestly. The temptation is to mark a dimension green because it usually works, rather than because you checked and it is genuinely healthy.
A generous score defeats the purpose. The point is to find the reds before they find you, and a scorecard graded on optimism hides exactly what it was meant to reveal.
When a check is ambiguous, score it yellow and look closer, rather than rounding up to green. An honest yellow is more useful than a comfortable green that turns out to be wrong.
Triage, not diagnosis
It helps to be clear about what the self-audit is. It is triage: a fast pass that sorts the store into healthy and not-healthy across each dimension.
Triage tells you where it hurts, not always why. A red on stability says the store is failing; the underlying cause may take deeper investigation to pin down, which is where a forensic review earns its place.
Treating the self-audit as triage keeps expectations right. It is the tool that decides whether you need the deeper look, and where, not the tool that replaces it.
What a healthy store looks like
It helps to know the target. A healthy store scores green across the board: production mode, high cache hit rates, healthy cron, valid indexers, a supported and patched version, bounded logs, and a database proportional to the business.
That store is not perfect, and no store is. It is one where the known, measurable risks are managed, so the team's attention goes to growth rather than firefighting.
Most stores are not there, and that is normal. The point of the scorecard is to show the distance to that target and the shortest path to closing it.
Where the self-audit points next
The self-audit ends with a decision. If everything scores green, the store is healthy and the audit becomes a routine check to keep it that way.
If the scores show scattered reds or a serious single red, the audit has done its job by pointing at where a deeper look pays off. Knowing you have a stability problem, or a security exposure, is exactly the input that justifies a forensic review focused there.
Either way, you end with clarity instead of a vague worry. That clarity, produced from signals the store already exposes, is the real value of scoring your own store.
Run it, then run it again
The self-audit is most valuable as a habit. Run it once to establish a baseline, and again on a schedule to see whether the store is improving or drifting.
A dimension trending from green toward red is an early warning you gave yourself. A dimension moving the other way is proof that the work you did held.
The habit is what makes it powerful. A store scored once is a snapshot, but a store scored every month is a trend line, and a trend line catches drift long before it becomes a failure.
Scoring your own store turns platform health from a vague worry into a tracked metric. Knowing where you stand across every dimension is the first step, and it is exactly what a structured audit formalizes when the stakes justify going deeper.