Observe and maintain JustScan
Monitor health, scan progress, notifications, and maintenance changes before they affect delivery workflows.
Treat JustScan as a release-decision service once CI depends on policy outcomes. Monitor the service and its dependencies, then keep a visible maintenance process for changes.
Signals to review
- Backend health: use
/api/v1/livezfor process liveness and/api/v1/readyzfor dependency-aware readiness./api/v1/healthremains a compatibility endpoint. Readiness checks PostgreSQL and checks local Trivy only when Trivy is enabled; an Xray-only backend does not require a Trivy binary or local database. - Scan activity: review pending, active, stale, and failed scans; inspect scan step progress and backend logs before changing global timeouts.
- Process Center: use the durable process entry for an authenticated scan to see whether work is queued, running, succeeded, failed, or cancelled. Its phase is the persisted scan step; a missing percentage means the current scanner cannot provide a trustworthy total.
- Scanner readiness: use the administration scanner health view and confirm registry reachability, database freshness, and available worker capacity.
- Queue capacity: administrators can use the scan queue summary's queue depth, oldest queued lag, active workers, and utilization fields. Non-administrators receive only workspace-scoped durable activity, so one workspace cannot infer another workspace's queue.
- Notifications: test channels and inspect delivery logs and queued delivery state after configuration changes.
- Audit records: review organization and administrator activity when investigating access, ownership, policy, or token changes.
The admin scanner settings API applies engine toggles, command timeout, scanner database age, and OSV Java enrichment on subsequent work. Worker concurrency is fixed when the backend starts and is reported as restart-required; pending durable scans are requeued during startup and by the recovery dispatcher. The Process Center reconciles its linked records from persisted scan status and phase, so a process entry should be checked together with the scan detail when diagnosing a restart or stale worker.
The Process Center list shows recent process records for operational history; those records are not a second copy of findings or SBOM data. Completed and failed entries can be removed individually or in bulk from one user's Process Center view without deleting shared organization history or backend diagnostics. Deleting the linked scan removes the process entry. There is no Process Center retry action: correct credentials, registry access, scanner data, or input errors before submitting a fresh scan, and use a fresh scan when the original input or policy decision must be replaced.
CVE Intelligence health
Review CVE Intelligence after enabling the feature and whenever a security feed incident is suspected. The admin page exposes the last successful checkpoint, retry state, recent sync runs, and live progress for an active run. Watch the completed/total event count and the last progress timestamp, not only the running badge: source events can continue appearing while current-record enrichment is still in progress.
Keep the initial lookback bounded in production. The worker follows a resumable NVD change cursor and does not enumerate every Vulnerability Knowledge Base entry during normal operation. A newly created or widened checkpoint can still create a large upstream backlog, so inspect the current CVE, unique-CVE count, backend logs, and NVD response errors before changing the interval or retrying manually.
Planned maintenance
Use the administration maintenance setting to communicate planned work to application users. Before an upgrade, capture backups, pin the target release tags, and tell CI owners whether the policy gate should be temporarily non-blocking. After the change, verify health, authentication, a registry connection, a representative scan, and notification delivery.
If a signal is unhealthy, work from troubleshooting before increasing concurrency or timeouts. A larger timeout can hide a credential, network, or scanner-data failure instead of resolving it.