Scan Status
Understanding Secbez scan status — pending, running, completed, completed-with-errors, and failed states.
A scan run goes through several states from queue submission to final result.
Status values
| Status | Meaning |
|---|---|
| Queued | The scan request has been accepted and published to the queue. A worker has not yet claimed it. |
| Running | A worker has claimed the job and is executing the pipeline. Live progress is exposed on the dashboard. |
| Completed | All pipeline steps finished without error. Findings are persisted, the policy decision is final, and the GitHub Check Run is published. |
| Completed with errors | The gate finished and findings are valid, but a non-critical step (LLM enrichment, graph index, explanation) failed or timed out. No findings are dropped. |
| Failed | The scan could not complete. Usually a configuration, connectivity, or budget-exceeded condition. Look at the scan run page for the error reason. |
Completed vs. completed-with-errors
A completed scan ran the entire deterministic and enrichment pipeline cleanly.
A completed-with-errors scan still produces valid, persisted findings — the gate decision is unaffected. The most common causes are:
- An LLM enrichment call timed out or returned an invalid response. The affected findings keep their deterministic explanation and
agent_prompt. - The optional graph indexer was unavailable. Findings are still produced, but cross-file context (callers, route reachability) may be reduced.
- A specific scanner exceeded its per-scanner time budget. Other scanners completed normally.
Findings are never silently dropped. If a step fails, the affected items are preserved, marked, and surfaced to the user.
GitHub Check Run conclusion
The GitHub Check Run conclusion is derived from the policy decision:
| Check conclusion | Meaning |
|---|---|
| Success | No findings exceeded warn or fail thresholds. |
| Neutral | Some findings exceeded warn thresholds but not fail thresholds. |
| Failure | One or more findings exceeded fail thresholds (default: any critical, any high+high-confidence). |
| Action required | The scan failed before policy could be evaluated. |
Idempotency
A scan run is identified by (repo, sha, mode). Re-delivery of the same webhook event is absorbed at the upsert boundary — Secbez will never run the same scan twice, and retrying a queue message is safe.