Reading the report
The report is built to answer one question first — can you open the shop — and only after that, why. Everything below the top line exists to back up that first sentence with specifics you can act on.
The verdict comes first, not a number
The first thing you see is a sentence, not a score. "0 out of 100, grade F" tells a developer plenty and a shop owner almost nothing, so SixPreflight leads with what will actually happen.
| You see | It means |
|---|---|
| Not ready to take orders | Something here will stop customers ordering, lose payments, or expose your passwords. Do not open the shop. |
| Open at your own risk | More than five settings are wrong — enough that this is not one broken feature but a server that was never configured for this. |
| Works, but something is broken | The shop runs. A feature does not, and will not until you fix it. |
| Safe to open, but slower than it should be | Nothing is broken. Several settings are below what your shop needs, so pages feel slower than they have to. |
| Ready to open | Nothing broken, nothing exposed. Small improvements may remain, none urgent. |
On a server with no application installed, the same five verdicts are worded for that — "Not ready to go live", "Looks good", and so on.
What the colours mean
| Status | Meaning |
|---|---|
| Need fixing | This stops something working, or leaks something. Not an opinion. |
| Worth improving | Works, but below what your shop needs. Usually speed. |
| Fine | Checked and correct. Nothing to do. |
| Not tested | Not a pass. SixPreflight could not determine this, and says so rather than guessing. |
"Not tested" matters most on the exposure checks. If your site did not answer a request from itself, SixPreflight says the test was not performed, rather than showing a green tick it has not earned. When you see that, check by hand — open https://your-domain.com/.env in a browser. If it downloads, your database password and every payment key are public.
A fourth answer, "not readable from here", is a different thing again — see Limitations for why some rows on a managed panel say this and what it means.
How the score is built
The number is a weighted average, not a count of passes. Every check carries a weight based on what it costs you if it is wrong: APP_DEBUG=true sits at 200, an operating-system name sits at 12. A pass earns its full weight, a warning earns half, a problem earns nothing.
A check the tool could not run is excluded from the score entirely. That is the single most important rule to understand about the number. On a managed panel, PHP is often confined to the site's own folder — correct and worth keeping — which means a handful of checks have no answer to give. Scoring those as failures would punish you for good security; scoring them as passes would be lying. So they are left out, and a locked-down server is never marked down for being locked down.
Grades
| Score | Grade | What it means |
|---|---|---|
| 90 and above | A | Production ready |
| 75–89 | B | Good. Clear the amber items and re-check |
| 55–74 | C | Workable, but leaving real performance on the table |
| 35–54 | D | Not ready. Several settings will hurt under load |
| Below 35 | F | Do not go live on this configuration |
One red row caps the score at 88, so read the rows
If any single row is red, the score cannot go above 88 however good the other hundred checks are. An A grade is unreachable with one red finding on the page.
That makes a capped number close to uninformative on its own. A capped score tells you one row is red. It tells you almost nothing about the rest.
Here is what that looks like in practice. In one round, two servers scored 88 and 96. Read as grades, that is a B and an A — a gap you would act on.
The underlying weighted scores differed by 0.03 across roughly a hundred checks. The entire visible eight-point gap was one stale background job on the lower server. Everything else on both machines was the same.
A score is a summary, not a verdict
Two servers eight points apart can be identically configured, and one of them will read as a grade lower purely because one row tripped the cap. Open the red rows and read them. The number exists to tell you whether to look, not to tell you what you would have found.
Blockers cap it harder
Some failures are not "points off" — they mean the shop cannot trade at all. One blocker caps the score at 74, two cap it at 54, three or more cap it at 34. Those caps sit below the 88 one and override it.
The blocker list is short and specific on purpose:
.envreadable over the web, or logs served over the web- An uploaded
.phpfile that actually executes - The site stuck in maintenance mode
- New stores unable to register
- No usable payment method
- The database unreachable, or storage misconfigured
- Mail failing, or SMS failing
- A database mode the platform breaks under, or the wrong character set
- The scheduler not running
- A certificate expiring inside 14 days
- A handful of
.envfaults — a missing or shippedAPP_KEY,APP_DEBUG=true, a broken database block, a broken mail block, duplicate keys
What is deliberately not a blocker
Files above the document root being readable is graded as a warning, not a blocker — that is disclosure, not a breach. The list stays short on purpose: if everything is an emergency, nothing is.
One consequence worth knowing: a certificate expiring soon is a blocker, but it is only measured on a Deeper check, because it is read off a live TLS handshake. A quick "Check now" cannot tell you your certificate expires next week — run the deeper pass before you trust a green result.
Anatomy of a finding
Every row on the fix list carries the same four things, which is what makes the list something you can act on rather than just something that alarms you:
- A plain-English name beside the technical one, so a setting also reads as what it does
- What it is set to now, measured on this server, not assumed from a default
- What it should be, computed from this machine's RAM, cores and version, with a copy button
- What happens if you leave it, and the exact command or setting that changes it — written for the hosting panel you are actually on
Why order matters
Findings are sorted by consequence, not severity alone. Anything that leaks credentials or stops orders is listed before anything that only costs milliseconds — so fixing the top five items is usually worth more than fixing everything below them.
Each row also carries an impact label: Stops orders, Can stop orders, Serious risk, Risk, Slows the site, Worth fixing, Tidying. That label is what tells you whether to act tonight or next week.
Where to go next
For the full list of what to change and how, see The "What to fix" page. If a row says "not readable from here" and you want to know why, see Limitations.