Quick Reference

Use this page as a starting point. Match the symptom you are seeing to the most likely diagnostic path, then follow the linked page for detailed steps.

If your symptom is not represented here — or you have worked through the linked path without resolving the issue — gather a Diagnostic Bundle before contacting Anchore Customer Success.

Common Symptoms

Symptom	Likely cause	Start here
A service shows as `down` or `unavailable` in `anchorectl system status`.	The service process has crashed, the container has exited, or the readiness probe is failing.	Verifying Service Health
A service shows as `orphaned` in the GUI System view.	The service can no longer reach the catalog or its database registration has lapsed. After a Helm upgrade, orphaned entries are expected — see the note below.	Verifying Service Health, then inspect that service’s log.
An image is stuck in the `analyzing` state for an extended period.	The analyzer cannot pull the image, registry lookup is failing, or the analyzer is overloaded.	Viewing Logs — trace the analyzer thread for that image.
Image analysis or SBOM ingestion is slow, or a backlog of submitted work is building.	Analysis throughput is not keeping up with the submission rate — commonly too few analyzer workers for the load.	See Image Analysis or SBOM Ingestion Is Slow.
Download Full Report takes a long time to complete for a large report.	Generating a large report on demand is expensive and slow.	Save the report and generate it immediately on save, or set it up as a scheduled report so the results are precomputed and ready to download. See Reporting.
`registry_lookup_failed` events appear repeatedly.	Registry credentials are missing or expired, or the registry is unreachable from the catalog.	Viewing System Events
Vulnerability data is stale or missing for one or more feed groups.	The Data Syncer has not pulled the relevant dataset, or the upstream provider is unreachable.	Data Syncer
Newly-published CVEs are not appearing on existing analyses.	Feed sync completed after the image was analyzed; the analysis needs to be re-evaluated.	Data Syncer
A policy evaluation returns an unexpected result (`stop` vs `pass`, or vice versa).	Policy or feed data has changed, or a gate is referencing data that is not yet available.	Viewing System Events and review the policy evaluation output.
On a brand-new deployment, images fail to display and policy evaluations fail.	The initial vulnerability feed sync has not completed yet, so the vulnerability and policy data those views depend on is not available. This is expected until the first sync finishes.	Data Syncer — confirm the initial feed sync is still in progress. It typically completes in minutes rather than hours; low throughput or high latency to the Anchore Data Service can extend it. In an air-gapped deployment the sync cannot run automatically — you must enable air-gapped operation and upload at least one dataset, as feeds do not ship with the software.
Widespread failures on a previously-working deployment — feed syncs fail, policies cannot be loaded, and images fail to display.	If you use an external object store, it may be misconfigured or its credentials/IAM permissions may be insufficient, so Anchore Enterprise cannot read or write stored documents.	Viewing Logs — check the catalog log for object store or `access denied` errors, then verify the object store configuration and permissions.
Nearly all operations fail with database errors, although the services still appear to be up.	The PostgreSQL database has become unreachable after the services started — it has stopped, is unreachable over the network, or has exhausted its connection limit. Services stay up but cannot complete work without the database.	Verifying Service Health — confirm PostgreSQL is running, reachable, and has free connections, then check the affected service logs.
The database is very large or growing quickly.	A high volume of stored SBOMs and reporting data consumes significant database space, and that data is retained until something removes or offloads it.	See Database Is Very Large or Growing.
Uploading feeds into an air-gapped deployment fails with a `grypedb` version error.	AnchoreCTL is a different version than your Anchore Enterprise deployment, so the dataset schema it produces is incompatible.	Use an AnchoreCTL version that matches your Anchore Enterprise version, then re-download and re-upload the datasets. See Air-Gapped Operation.
`anchorectl airgap feed download` fails with a permission-denied error.	The license used for the download has expired. Feed access now expires together with the license.	Download again using your newest license key or file. See Air-Gapped Operation.
AnchoreCTL cannot connect to Anchore Enterprise.	The URL, credentials, TLS trust, or API version are misconfigured.	Run `anchorectl system status -vvvv` and inspect the configuration dump along with any TLS or HTTP errors.
You need to validate the system end-to-end after an upgrade or configuration change.	A known-good baseline check is required.	Smoke Testing

Orphaned Services After a Helm Upgrade

Seeing orphaned services in the System view after a Helm upgrade is expected. Each upgrade attempt replaces the running pods, and the previous service registrations are marked orphaned until they age out — typically within 24 hours. As long as you also see the expected number of active instances of each service — one of each by default, or however many you have set via the service replicaCount values — the orphaned entries are almost certainly leftovers from the upgrade and can be ignored.

Pods being replaced for other reasons (for example, rescheduling or repeated restarts) can produce the same orphaned entries. If the active count for any service is wrong, or orphaned entries persist beyond a day, investigate further with Verifying Service Health.

Database Is Very Large or Growing

A large or steadily growing database is usually driven by the volume of stored SBOMs and reporting data. Work through the following:

Enable report data egress. In the UI, go to System → Configuration and search for egress, then ensure enable_data_egress is enabled and an egress window is set. Data egress periodically removes reporting data that has already been removed elsewhere in the system; leaving it disabled lets the reporting tables grow unbounded. See Data egress.
Check how many SBOMs are stored. In the UI, go to System → Usage and review Total SBOMs. Large counts — on the order of 5,000, 10,000, or 15,000+ — consume a lot of space. Each stored SBOM and its packages are indexed in the database and remain there until something removes them.
Remove or archive SBOMs you no longer need in the active set. Two mechanisms reduce the active working set:
- An artifact lifecycle policy automatically deletes or archives artifacts on a schedule.
- Image archival moves images out of the active set. Note that, by default, archived data is still stored in the database unless you have configured an external object store for the analysis archive.
Offload object data to an external object store. Configuring an external object store (for example, Amazon S3) moves large objects out of the database and can significantly reduce its size. For an existing deployment, switching the object store requires running the object store (OSAA) migration to move existing data. See Migrating the Object Store.

Image Analysis or SBOM Ingestion Is Slow

If images take a long time to move from submission to analyzed — or SBOM ingestion lags — the deployment is likely accepting work faster than the analyzers can process it. Confirm a backlog exists, then scale out.

See what is queued or incomplete. In the UI, for each account, go to Images → View Incomplete Analysis to list images that have been submitted but have not finished analyzing. A large or growing list indicates a backlog.
Confirm work is actively progressing. In the UI, check the Events tab for each account. A steady stream of image analysis events means the analyzers are working through a queue rather than being stalled. If nothing is progressing at all, the problem is a stalled analyzer rather than throughput — trace the analyzer in Viewing Logs.
Add analyzer capacity. If a backlog persists while the analyzers are busy, add more analyzer workers. For Helm, increase the analyzer replicaCount in your values file. Anchore generally recommends maintaining roughly a 4:1 analyzer-to-core-services (api, catalog, policy) ratio as you scale. See Requirements.

If Your Symptom Is Not Listed

Re-run anchorectl system status and confirm every service reports up and available.
Run anchorectl event list and look for recent error-level events tied to the affected resource.
Pull the relevant service log (see Viewing Logs) and grep for the resource identifier (image digest, image tag, or thread number).
If you still cannot isolate the cause, prepare a Diagnostic Bundle for Anchore Customer Success.