Verify and history
A single score, seen once, tells you almost nothing. What you actually want to know is "I raised the buffer pool and restarted — did that help?" — and answering that needs the scan from before the change, sitting next to the one from after it. SixPreflight keeps that history for you automatically.
Every scan is kept
Each run is saved as its own file, and you get the score over time plus, for every run, exactly which checks were newly fixed and which newly broke since the one before it. Any saved run can be opened again, exported as plain text to send to a developer, or deleted individually.
The newest 60 runs are kept; older ones are pruned automatically, so the history never grows without bound.
Why files, not a database table
History is stored as files inside the tool's own folder, never inside your application's database. Three reasons, in order of weight:
- The tool's one hard promise is that it never writes to an application table. A history table would break that promise outright.
- You want your history most exactly when the database is the thing that is broken. Storing it in the database means the record vanishes at the moment it matters most.
- The tool has to work by copying one folder into any install, with no setup step. A folder of saved files does that; a database table does not.
Two comparisons it deliberately refuses to make
A full scan is never compared against a quick one. The full scan runs steps the quick scan does not, so its score is legitimately different — comparing the two would report a collapse in health when nothing on the server actually changed. Where there is no earlier run of the same kind to compare against, the change column shows a dash rather than a misleading number.
The trend line plots one kind of scan at a time, for the same reason — mixing quick and deep runs on one line would make a routine deeper check look like a sudden regression.
A scan that never completed a single step is kept on disk but never charted. Scoring it would produce a real-looking zero — every check absent reads exactly like every check failed — which would drag the trend line down and make the next genuine scan look like a dramatic improvement that never happened.
Exporting a run
Every saved run can be exported as plain text, holding the same information the on-screen report shows: every finding in order, its current value, the value it should have, and the full advice for fixing it. Send that file to a developer rather than a screenshot — a screenshot usually cuts off the advice column, which is the part that actually says what to do.
Where to go next
- Reading the report — what the score and grade in a saved run actually mean
- Findings API — pull the last saved run into your own dashboard automatically