What is still open

This is the page that makes the other four worth reading. Anything that claims only improvements is selling; the useful question is what we have not solved, and what that costs you.

Backups do not restore anywhere

A backup holds exactly three things: the database, the application's .env, and the uploaded-files tree. That is the right set — the code itself is in git.

What it does not do is move cleanly to a different server. A restored .env still carries the old machine's database and cache passwords and its paths, so the application cannot connect until the panel's Update is run over it. And the restore does not run database migrations, so an older backup restored under newer code sits behind the schema until that is done too.

Both have a working manual step. Neither is automatic today. So: the backup is a real backup of a real shop, and a restore onto the same box works — but do not read it as one-click disaster recovery onto fresh hardware.

A rollback does not undo database changes

Rolling the code back to a previous release does exactly that: the code. It does not reverse database migrations that ran in between.

If an update changed the database and you then roll the code back, the shop is running old code against a newer schema. Recovering from that needs a backup restore, not a rollback. Worth knowing before you need it at 2 a.m.

Measurements come from one server size

Every number on these pages was taken on a 4 GB, 2-core server, with one real shop's dataset.

We have not measured 8 GB or larger machines, so nothing here predicts them. And your catalogue's shape — how many products, how they are categorised, how add-ons are used — affects which queries matter. A shop very different in shape from the one we tested may find a slow screen we never hit.

Storage-speed figures from those runs are not usable as evidence either: they reflect which physical host the virtual machine happened to land on, not the software.

The report pages that stay in the hundreds of milliseconds

All 297 pages of the 6amMart admin panel were timed on the real 66,701-order dataset, warm, with every query profiled. The seven genuinely broken pages this section used to list — including a day-wise report that took over 17 seconds because one query ran once per day in the reporting range — were fixed in the August 2026 round; the before-and-after table is on the measured results.

What remains open is smaller, and it is a boundary rather than a defect: 22 pages still take over 200 ms, and all but two of them are report aggregates in the 300–900 ms band whose cost is one honest scan of the whole order history. A SUM over every order a shop has ever taken reads every order — that is the job. Two of those pages were explicitly measured, considered, and left unchanged because the candidate indexes made them no faster or slower.

The number worth keeping from the broken era: the day-wise report's cost grew with the length of the reporting period, not the amount of data — 63 ms over 21 days, 18.6 seconds over all time — so a developer with three weeks of test data would never see it. That is why these pages are timed on a real shop's history, and why we publish the two that will not get faster next to the five that did.

Vendor updates need a real merge

The optimised code is 6amMart with our changes on top. When the vendor ships a new release, their files and ours overlap, and the overlap is resolved deliberately — not automatically.

That is work, and it is work we do rather than work you do. But it is honest to say the shape of it: this is not a plugin that survives an update untouched. It is a maintained codebase, and maintaining it is the ongoing part of the arrangement.

Some checks stay unknown rather than guessing

Where a check cannot read what it needs — a hardened host that blocks process or system access — the result is reported as "not measured" and excluded from any score, rather than assumed good or counted as a failure. A check that could not read its input has not passed and has not failed.

That means a clean report on a locked-down host genuinely covers less ground than the same report on a server you control end to end.

One case does not yet behave that way, and it is the exception rather than the rule: where PHP runs inside a kernel sandbox, one web-server timeout is reported as unset rather than as unreadable, when the web server has in fact set it. That is a wrong answer, not a blank one, and it marks a hardened server down for being hardened. It is written up in full on the limitations page under SixPreflight.

Two smaller ones, for completeness

On SixPanel Docker — the container runtime, as distinct from the recommended SixPanel runtime, which installs its services as systemd units — the websocket service and the storefront carry no health check, so the self-healing watchdog cannot see them. If one stops, nothing restarts it automatically.

And on a release install the command-line self-update fetches and runs its installer without verifying a signature. The panel's own update path and the download link we email are the verified routes.

What this list is for

Every claim on the measured results and defects fixed is something we can show you. This page is everything we cannot, and it is short on purpose — not because there is nothing else, but because we only list what we have actually confirmed rather than padding it to look thorough.

If something here matters to your shop, ask before you buy. That conversation is cheaper for both of us than finding out afterwards.