Skip to main content

Missing, failed, and inconclusive results

Distinguish a confirmed configuration problem from a check that could not produce usable evidence.

On this page

A scan can finish successfully even when some individual checks fail. Completion means the report is ready; it does not mean every endpoint was reached or every check passed.

Common result meanings

ResultWhat it tells youUseful next action
Supported, present, or observedThe probe found the stated feature or behavior.Inspect its value and scope; presence alone does not establish a good policy.
Unsupported or absentThe relevant probe reports that the feature or record was not found.Decide whether the service should provide it.
Unknown or unavailableThere is insufficient usable evidence, or the feature cannot be assessed in that context.Review errors and check applicability before changing configuration.
Timeout or errorAn attempt failed to complete or returned an error.Read the error detail, check reachability, and retest when appropriate.
Not attemptedThe probe did not run, possibly because an earlier step failed.Resolve the earlier failure first.
Not applicableThe check does not apply to that endpoint or service role.Do not treat it as a missing protection.
Partial or truncatedOnly part of the intended evidence is available.Avoid conclusions about the unobserved portion.

These are interpretation guides. Individual sections use more specific labels, such as DNSSEC’s bogus or OCSP’s Not Available.

When there is no usable report

If no reachable TLS endpoints can be verified, SSLBoard can finish with an unscannable outcome rather than a normal scored report. That does not mean the domain scored zero on a completed security assessment. Check the domain, public DNS, and intended service exposure before trying again. A scan that fails for another reason can also show an error instead of a report.

Absence is different from invalidity

An absent DNSSEC deployment and a broken signed zone need different responses. A missing HSTS header and a failed HTTPS connection also establish different facts. Where the report cannot make the distinction from the returned data, review the endpoint evidence before deciding what is wrong.

When to rerun a check

Retest after a relevant configuration change, after resolving a lookup or connectivity problem, or when the report is too old for the decision you are making. A repeated timeout may reflect a deliberate access policy; it does not justify opening an internal service to the Internet.

If a result still looks inconsistent, provide support with the scan link, hostname, affected address and port, and the specific observation you expected. Share access-bearing report links only with people who should have the full report.

Try these checks on your own domain: Start a free scan. If a result needs a closer look, contact us.