Scan runs
Did the last runs cover the catalog, and where did the coverage go missing?Reading the filter from the URL…
MonitorScan runs
demoThis build is a demo. The catalog and detections are a fixed sample.Scopereading…Sound is used for one thing: a short tone when a long scan finishes while this tab is in the background. The A/B listening check plays audio either way, because there the sound is the evidence.Reading the filter from the URL…
MonitorScan runs
demoThis build is a demo. The catalog and detections are a fixed sample.Scopereading…Sound is used for one thing: a short tone when a long scan finishes while this tab is in the background. The A/B listening check plays audio either way, because there the sound is the evidence.Reading the scan runs…
Showing 0 of 0 runs — filtered to state=failed in the browser, against the state each card displays. The endpoint’s own state parameter filters the stored column, which never holds stalled — the service promotes that state after the query. Filtering there would silently return nothing for one word of the vocabulary.
Nothing here can re-run a scan.
The monitor API commissions no work. There is no route that starts or resumes a scan — the write routes that exist record dispositions, exports and reconciliation, and none of them touches a job. The per-candidate cause a retry would key on IS published now, on the run detail: FAILURE_CAUSES in monitor_router.py:72 marks audio_fetch_403, audio_fetch_timeout and rate_limited as retryable and decode_unsupported as not, and GET /api/monitor/scans/{run_id} returns the grouped counts. What is missing is the verb, not the evidence.
Not reached is not failed. Every card prints candidates_total − candidates_scanned under that name, and prints — where either side is missing rather than subtracting from a null. A candidate the run never got to and a candidate it tried and could not fetch are two different facts, and only the second one is retryable. The split by cause lives on each run’s own page, where failed_by_cause arrives grouped with the retryable flag the service assigns each cause — not linked from here, because there is no one run to link to.
No percentage. §10.2 puts a scan over candidates in the counted class and forbids a percentage for it by name; §10.3’s worked example prints one anyway, and the endpoint publishes progress_pct. The bar draws the fraction, both counts are printed beside it, and no % is printed on this screen.
The list is capped at 100 runs and the endpoint reports how many it returned, not how many exist. Where the cap binds, the oldest runs are simply not here — paging is supported by the route and is not wired to a control.