Supabase scored 100—and the scan still hit an inspection limit

supabase.com · observed 2026-10-02T18:19:12.627Z

The qualifier that should not disappear

The Supabase snapshot returned a 100/100 public technical-readiness score with high observation confidence. It also contained a homepage-truncated finding: the response inspection stopped at 786432 bytes. The saved report disclosed that some signals later in the document might not have been inspected.

Those facts should travel together. A high score can describe the checks supported by the collected portion of a response; it cannot make a bounded response exhaustive. Hiding the qualifier would give readers a broader impression of the test than the evidence supports.

A limit in our method is not necessarily a defect in their site

The existence of an inspection limit is a property of the collector and its resource budget. It does not, by itself, establish that a website is slow for users, improperly implemented or unsuitable for agents. The report’s own finding says no action is required solely because the inspection was truncated.

A useful next step depends on the question. If a missing signal might occur after the boundary, review that signal through an appropriately bounded alternative method. If the relevant signals were already observed, retain the qualifier and avoid treating the result as an inspection of every page, script and execution path.

The reporting habit worth copying

Put measurement limits beside the headline, not only in an appendix. State the exact surface and date. Separate the returned score, the coverage of the broader assessment and any unresolved collector condition. This allows a reader to decide whether the report is sufficient for the decision at hand.

The same habit applies to evidence outside web scanning. An interaction count with incomplete consent coverage cannot describe every visitor. A payment handoff is not a settled sale. A partial log export is not the full history of an agent journey. Making the boundary explicit is what keeps later decisions from resting on an inflated premise.

What to verify next

Run a public scan on a hostname you control and inspect both the headline and the limitations. Choose one signal whose meaning matters to an actual integration or customer task. Preserve the initial result before making a change so a retest has a legitimate comparison point.

For ongoing observation, use connected evidence appropriate to your question and keep its collection limits visible too. The goal is not an audit without caveats. It is a result whose claims, scope and next action can survive examination by another operator.