Skip to main content
A finding is a silent failure Zespan found by checking a trace against what is stored for it: an answer that is not valid JSON, a tool that was called but is not defined, a total that does not add up. Nothing threw, so nothing showed in your logs.
Findings are off by default in the dashboard and appear when they are turned on for your organization. Self-hosted: build the dashboard with NEXT_PUBLIC_FINDINGS_UI=1. What each person may see is decided as described in Who sees findings.

​
Findings on a trace

When a trace has findings, a Findings on this trace card sits under the verdict. Each finding shows: A trace with no findings shows no card.

​
Tiers

A finding marked Needs review is one Zespan held back for a person to look at. Only owners and admins see that queue.

​
The Findings page

Findings in the sidebar lists the project’s findings, newest first. Filter by:
  • Agent (exact name)
  • State (open or needs review)
  • Check family (D1 to D7 and the domain packs, named as on Silent-failure coverage)
  • Tier
  • Time range (24 hours, 7 days, 30 days)
The page shows up to 100 findings at a time and says so; narrow the filters to see others. Each finding links to its trace.

​
Who sees findings

Findings are recorded from the first trace, but they are shown only when the project’s detectors are on. While they run in preview, owners and admins see them marked Preview and everyone else sees nothing. When the detectors are off, nobody sees any.

​
Free and paid

Every finding shows its cause, fix and written prevention advice on every plan. Drafting a policy that Zespan tests on your own recorded traffic needs the Pro plan; below it the Prevent section shows what kinds of prevention exist, with no draft content.

​
Checks that could not run, and why

A check that needs an input your SDK did not record reports that it could not run and names the input, instead of passing. When readiness is enabled for your deployment (self-hosted: CAPTURE_READINESS=on), GET /v1/projects/{id}/traces/{traceId}/functional/unchecked lists the checks that could not run on a trace, and GET /v1/projects/{id}/functional/readiness?days=7 shows, for the project, the share of checks that could run (readiness, not a quality score), the missing inputs that cost the most, whether capture can fix each one, and what to do. Neither route holds any content. The reasons and what each input needs are listed in Capture fields.

​
Next steps

  • Issues — recurring failures grouped from failed and degraded traces
  • Traces — the verdict and where it broke
  • Silent-failure coverage — which failures are checked and the check families
  • Stack layers — what the layer chip means
  • Policies — where a drafted policy shows its test results