Limitations

A tool that always has an answer for everything is guessing somewhere. SixPreflight is built to say when it does not know, rather than filling the gap with something that looks confident and might be wrong.

Read this page before you rely on the score alone.

The short version

• Some checks cannot read their input on a hardened or managed host. Those are excluded from the score, not failed.
• One check is worse than that: it can read the absence of a web-server setting as the setting being unset. That is a real wrong answer, and it is described below.
• A quick check cannot see anything that needs a live HTTP response, including certificate expiry.
• The exposure step is not a penetration test.
• The benchmarks describe this machine at this moment, not the hardware in general.

Everything below is one of those in full.

It cannot see what the server will not show it

Checks that need direct process access or kernel-level file access degrade to "not measured" rather than guessing at a value.

Managed hosting panels disable different things from each other, so a row can be populated on one host and blank on another for reasons that have nothing to do with your actual configuration.

What a confined PHP cannot read

On any managed panel, PHP is commonly confined to the site's own directory — a setting called open_basedir. That is correct security practice and worth keeping.

It also means a handful of things genuinely cannot be read from inside the tool: process and memory details, the operating system release file, the web-server config, the PHP-FPM pool config. Seven checks then have no answer to give.

Those rows say "not readable from here", and are excluded from the score entirely rather than counted as a failure. A check that cannot read its input has not failed — it has returned nothing, and scoring that as a fault would punish you for a hardening measure you should keep. One row in the PHP section explains this once and gives you both ways around it, if you want the fuller picture on a server you control end to end.

Where being hardened produces a wrong answer, not a blank one

The paragraph above describes checks that go quiet. This one is worse, and it is the reason this page exists.

On a server where PHP runs inside a kernel sandbox, SixPreflight cannot read the web server's configuration at all. For most rows that is fine — they report "not readable from here" and step out of the score. But one web-server timeout is not handled that way: SixPreflight finds no value, and reports the setting as unset.

The web server has in fact set it. SixPreflight simply could not see it.

It is listed here rather than quietly fixed later because a reader deciding whether to trust the number needs to know the one place it is currently untrustworthy.

A disabled PHP function used to end the whole scan

Shared hosts routinely disable PHP functions — shell_exec, proc_open, posix_getpwuid and friends. SixPreflight calls several of them to measure the server.

On PHP 8, calling a function the host has disabled is a fatal error, not a warning. It cannot be suppressed with @, and it cannot be caught as an ordinary error. The scan runner had no error handling around any of it.

So one disabled function ended the entire scan with a stack trace instead of a report. Not one blank row — the whole thing, including the ninety-odd checks that had nothing to do with the function in question.

The servers this happened on were shared cPanel and Plesk hosting: the hosts that disable the most, and the ones most likely to need a readiness check in the first place.

This is fixed. A disabled function is now one row saying it could not be measured, and the scan runs to the end. If you are on a copy that still stops with a PHP error partway through, update it — see Troubleshooting.

A quick check cannot see everything a deeper one can

Compression, static-asset caching, live connection reuse, the server's version banner, HSTS, and certificate expiry are all read off a real HTTP response rather than a config file, so they only appear on a Deeper check — never on a quick "Check now".

Certificate expiry is one of the checks that can block your score outright, so a quick check cannot tell you your certificate expires next week. Run the deeper pass before you trust a green result on anything that touches the web server.

The tool disagrees with itself on free disk space

The requirements table says you need 20 GB free; the hardware check itself only warns between 10 and 20 GB and fails below 10.

Two different answers to the same question, on the same page. Both are shown rather than picking one and hiding the disagreement, because that is the honest way to report a tool that has not fully reconciled itself yet. Either way, aim for well above both numbers and the gap will not matter to you.

It reports what the server says, not what is actually in effect

If a hosting panel applies configuration at a layer this tool cannot see into, trust the panel's own interface over this tool's reading of a config file.

Some panels manage PHP and database configuration through their own UI and can silently overwrite a hand-edited file — if a setting keeps reverting after a restart, that is the panel rewriting it, and the fix is to change it through the panel rather than the file.

The exposure step is not a penetration test

It fetches a fixed list of known-risky addresses off your own site and reports exactly what came back.

It does not search for unknown vulnerabilities, and it is not a substitute for a code audit — it catches the specific, common mistakes that leak a database password or a source file, not everything that could possibly be wrong with a server.

One credential genuinely cannot be verified from a server

The Google Maps client key is restricted by browser referrer rather than by server address, so a request made from your server would fail on a perfectly good key just as easily as on a broken one.

SixPreflight can tell you the key is missing, or that it is dangerously identical to your server key, but it cannot confirm a correctly restricted one from the server side — and says so rather than showing you a pass it has not earned.

The benchmarks measure this machine, right now

A noisy neighbour on shared infrastructure makes every benchmark number look worse than the hardware really is. Check the load-average row before drawing a conclusion from a single benchmark run — see Speed and sizing for how to run it more than once.

Row counts are estimates, not exact figures

Table sizes shown in the benchmark come from the database's own internal statistics, which are close estimates rather than exact counts. An exact count would mean scanning every row of every table on a server that might be live and taking real traffic.

It is a checker first

The scan itself changes nothing on your server.

A handful of specific surfaces do write when you press their own button — clearing a log file, sending a real test push notification, running the optional database benchmark, or saving a password — and the setup script applies changes only when you run it with its apply flag. Every one of those is a deliberate action you take, never something the scan does on its own.

Where to go next

• Reading the report — how "not measured" and the score cap interact with the number
• Troubleshooting — what to do when the scan itself misbehaves
• Security and privacy — what the tool does and does not do on your server