This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Troubleshooting

This section contains general troubleshooting guidance for your Anchore Enterprise instance. If you are not sure where to start, the Quick Reference maps common observable symptoms to the most likely diagnostic path. Otherwise, the recommended general approach is to first verify all Anchore Enterprise services are up, use the event subsystem to narrow down particular issues, and then navigate to the logs for specific services to find out more information.

If you have worked through the relevant pages and still cannot isolate the cause, gather a Diagnostic Bundle before contacting Anchore Customer Success.

Throughout this section, AnchoreCTL commands are used to assist with troubleshooting. For more information on AnchoreCTL, see the AnchoreCTL section.

1 - 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.

2 - Smoke Testing

This term typically refers to a testing methodology which validates critical or crucial functionality of software. Versions of AnchoreCTL post-5.6.0 include a smoke-tests option, which can be used to validate general functionality of your Anchore Enterprise.

We recommend using this mechanism to validate functionality after upgrades.

The smoke tests are not designed for air-gapped deployments and may report failures there. Some steps assume outbound access that an air-gapped environment blocks by design — for example, wait-for-system expects the data syncer to have synced vulnerability feeds (in an air-gapped deployment you must upload them manually first), and the test-image steps pull a test image from a public registry the deployment cannot reach. In an air-gapped deployment, validate functionality manually instead by analyzing an internally-available image and evaluating a policy against it.

The test check-admin-credentials looks for an admin user in the admin account context as defined in your anchorectl.yaml.

anchorectl system smoke-tests run
...
 ✔ Ran smoke tests
┌───────────────────────────────────────┬─────────────────────────────────────────────────┬────────┬────────┐
│ NAME                                  │ DESCRIPTION                                     │ RESULT │ STDERR │
├───────────────────────────────────────┼─────────────────────────────────────────────────┼────────┼────────┤
│ wait-for-system                       │ Wait for the system to be ready                 │ pass   │        │
│ check-admin-credentials               │ Check anchorectl credentials to run smoke tests │ pass   │        │
│ create-test-account                   │ Create a test account                           │ pass   │        │
│ list-test-policies                    │ List the test policies                          │ pass   │        │
│ get-test-policy                       │ Get the test policy                             │ pass   │        │
│ activate-test-default-policy          │ Activate the test default policy                │ pass   │        │
│ create-test-image                     │ Create a test image and wait for analysis       │ pass   │        │
│ get-test-image                        │ Get the test image                              │ pass   │        │
│ activate-test-subscription            │ Activate a test subscription                    │ pass   │        │
│ get-test-subscription                 │ Get the test subscription                       │ pass   │        │
│ deactivate-test-vuln-subscription     │ Deactivate the vuln subscription                │ pass   │        │
│ deactivate-test-policy-subscription   │ Deactivate the policy subscription              │ pass   │        │
│ deactivate-test-tag-subscription      │ Deactivate the tag subscription                 │ pass   │        │
│ deactivate-test-analysis-subscription │ Deactivate the analysis subscription            │ pass   │        │
│ check-test-image                      │ Check the test image                            │ pass   │        │
│ get-test-image-vulnerabilities        │ Get the test image vulnerabilities              │ pass   │        │
│ delete-test-image                     │ Delete the test image                           │ pass   │        │
│ disable-test-account                  │ Disable the test account                        │ pass   │        │
│ delete-test-account                   │ Delete the test account                         │ pass   │        │
└───────────────────────────────────────┴─────────────────────────────────────────────────┴────────┴────────┘

Troubleshooting Failing Steps

wait-for-system

Polls the API until the vulnerability feed reports as ready (300s timeout). Failure means: The data syncer cannot reach https://data.anchore-enterprise.com or feeds have not completed their initial sync.

Verify external connectivity: curl -v https://data.anchore-enterprise.com
Check feed sync status: anchorectl feed list
Check data syncer events: anchorectl event list --level error --service data_syncer
See Data Syncer Troubleshooting for deeper diagnosis of feed sync issues.

get-test-policy / activate-test-default-policy

Verifies the policy engine is functional and default policies exist. Failure means: Policy engine is unhealthy or feed data has not been loaded yet. These steps commonly fail as a cascade when wait-for-system also fails.

See Verifying Service Health to confirm the policy engine service is up and responding.

create-test-image / get-test-image / get-test-image-vulnerabilities

Submits a test image for analysis and verifies the full analysis pipeline. Failure means: The analyzer, catalog, or policy engine is not functioning correctly.

See Verifying Service Health to check the status of the analyzer and catalog services.
See Viewing Logs and Viewing System Events for deeper diagnosis.

Note: all test resources (account, image) are cleaned up automatically at the end of the run.

3 - Viewing Logs

Anchore Enterprise services produce detailed logs that contain information about user interactions, internal processes, warnings and errors. The verbosity of the logs is controlled using the logging.log_level setting in config.yaml (for manual installations) or the corresponding ANCHORE_LOG_LEVEL environment variable (for docker compose or Helm installations) for each service.

The log levels are DEBUG, INFO, WARNING, ERROR, and CRITICAL, where the default is INFO. Most of the time, the default level is sufficient as the logs will contain WARNING, ERROR and CRITICAL messages as well. But for deep troubleshooting, it is always recommended to increase the log level to DEBUG in order to ensure the availability of the maximum amount of information.

Raising the log level to DEBUG significantly increases log output and adds load to the system. Use it while actively troubleshooting, and return the level to INFO once you have gathered what you need.

You can find further info on configuring logs in Configuration.

Anchore Enterprise logs can be accessed by inspecting the docker logs for any anchore service container using the regular docker logging mechanisms, which typically default to displaying to the stdout/stderr of the containers themselves - for example:

docker ps
CONTAINER ID   IMAGE                                       COMMAND                  CREATED          STATUS                    PORTS                                         NAMES
f7bd1bff4c90   anchore/anchore-ui:v6.0.0                   "/docker-entrypoint.…"   12 minutes ago   Up 11 minutes (healthy)   0.0.0.0:3000->3000/tcp, [::]:3000->3000/tcp   anchore-6000-ui-1
37637df74cda   anchore/enterprise-dev:v6.0.0               "/docker-entrypoint.…"   12 minutes ago   Up 11 minutes (healthy)   8228/tcp                                      anchore-6000-policy-engine-1
bf516667e360   anchore/enterprise-dev:v6.0.0               "/docker-entrypoint.…"   12 minutes ago   Up 11 minutes (healthy)   0.0.0.0:8558->8228/tcp, [::]:8558->8228/tcp   anchore-6000-reports-1
701dbb4a9ac4   anchore/enterprise-dev:v6.0.0               "/docker-entrypoint.…"   12 minutes ago   Up 11 minutes (healthy)   8228/tcp                                      anchore-6000-component-catalog-1
b64829f694ac   anchore/enterprise-dev:v6.0.0               "/docker-entrypoint.…"   12 minutes ago   Up 11 minutes (healthy)   8228/tcp                                      anchore-6000-reports_worker-1
b1044667f188   anchore/enterprise-dev:v6.0.0               "/docker-entrypoint.…"   12 minutes ago   Up 11 minutes (healthy)   0.0.0.0:8668->8228/tcp, [::]:8668->8228/tcp   anchore-6000-notifications-1
00c47016e3d9   anchore/enterprise-dev:v6.0.0               "/docker-entrypoint.…"   12 minutes ago   Up 11 minutes (healthy)   8228/tcp                                      anchore-6000-analyzer-1
5bac7677d307   anchore/enterprise-dev:v6.0.0               "/docker-entrypoint.…"   12 minutes ago   Up 11 minutes (healthy)   0.0.0.0:8228->8228/tcp, [::]:8228->8228/tcp   anchore-6000-api-1
3107c52d182c   anchore/enterprise-dev:v6.0.0               "/docker-entrypoint.…"   12 minutes ago   Up 11 minutes (healthy)   0.0.0.0:8778->8228/tcp, [::]:8778->8228/tcp   anchore-6000-data-syncer-1
aae305b431c7   anchore/enterprise-dev:v6.0.0               "/docker-entrypoint.…"   12 minutes ago   Up 11 minutes (healthy)   8228/tcp                                      anchore-6000-catalog-1
965a7c795d5c   anchore/enterprise-dev:v6.0.0               "/docker-entrypoint.…"   12 minutes ago   Up 11 minutes (healthy)   8228/tcp                                      anchore-6000-queue-1
de7993ad0f8e   redis:7.4.6                                 "docker-entrypoint.s…"   12 minutes ago   Up 12 minutes (healthy)   6379/tcp                                      anchore-6000-ui-redis-1
4ebc23aaf9ed   anchore-6000-anchore-db                     "docker-entrypoint.s…"   12 minutes ago   Up 12 minutes (healthy)   5432/tcp                                      anchore-6000-anchore-db-1

docker logs anchore-6000-analyzer-1
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-02T09:57:44.646254+00:00] [MainProcess] [MainThread] [INFO] [anchore_enterprise.common.service/_register_instance_handlers():594] | Registering api handlers
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-02T09:57:44.646589+00:00] [MainProcess] [MainThread] [INFO] [anchore_enterprise.common.service/_process_stage_handlers():231] | Processing init handlers for bootstrap stage: pre_config
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-02T09:57:44.646758+00:00] [MainProcess] [MainThread] [INFO] [anchore_enterprise.common.service/_configure():293] | Loading and initializing global configuration
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-02T09:57:44.646901+00:00] [MainProcess] [MainThread] [INFO] [anchore_enterprise.common.services/_init_versions():105] | Initializing enterprise versions
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-02T09:57:44.647043+00:00] [MainProcess] [MainThread] [INFO] [anchore_enterprise.common.service/_configure():296] | Anchore version 6.0.0, DB Schema 6000
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-02T09:57:44.647247+00:00] [MainProcess] [MainThread] [INFO] [anchore_enterprise.common.service/_configure():320] | Configuration complete
...
...

If you are using Kubernetes to run Anchore Enterprise, you can retrieve the logs from the service pods directly using kubectl commands:

You can find the desired pod name with kubectl get pods.

kubectl logs -n <your-namespace> <your-anchore-pod-name>
[service:anchore-enterprise-apiext-v6.0.0] [2024-11-12T18:11:21.475751+00:00] [MainProcess] [WSGI_2] [INFO] [anchore_enterprise.common.service/log_request():948] [req-id-aa93785c77c94d7081b1cff51d59d0aa] | 172.18.0.15:50682 - "GET /health HTTP/1.1" 200 request:0bytes response:5bytes 1.13ms
[service:anchore-enterprise-apiext-v6.0.0] [2024-11-12T18:11:21.494813+00:00] [MainProcess] [WSGI_0] [INFO] [anchore_enterprise.common.service/log_request():948] [req-id-fdec0048c96348b9ae3385866908931f] | 172.18.0.15:50694 - "GET /version HTTP/1.1" 200 request:0bytes response:86bytes 1.27ms
[service:anchore-enterprise-apiext-v6.0.0] [2024-11-12T18:11:30.499957+00:00] [MainProcess] [WSGI_2] [INFO] [anchore_enterprise.common.service/log_request():948] [req-id-8c6dd69ca53241958cfc63287ff97403] | 172.18.0.16:50360 - "GET /metrics HTTP/1.1" 200 request:0bytes response:18483bytes 14.08ms
[service:anchore-enterprise-apiext-v6.0.0] [2024-11-12T18:11:31.533531+00:00] [MainProcess] [WSGI_0] [INFO] [anchore_enterprise.common.service/log_request():948] [req-id-7d0b21bb200d491db6a63fffaeb95bf2] | 172.18.0.15:51316 - "GET /health HTTP/1.1" 200 request:0bytes response:5bytes 1.5ms
[service:anchore-enterprise-apiext-v6.0.0] [2024-11-12T18:11:31.539215+00:00] [MainProcess] [WSGI_2] [INFO] [anchore_enterprise.common.service/log_request():948] [req-id-6090039eb148412cb50bd64ceb61a634] | 172.18.0.15:51324 - "GET /version HTTP/1.1" 200 request:0bytes response:86bytes 0.94ms
[service:anchore-enterprise-apiext-v6.0.0] [2024-11-12T18:11:40.149191+00:00] [MainProcess] [WSGI_0] [INFO] [anchore_enterprise.common.service/log_request():948]

View Logs Across Helm Chart Pods

When Anchore Enterprise is deployed with the Helm chart, every pod is labeled with app.kubernetes.io/name=<release>-enterprise (where <release> is your Helm release name) and a per-service app.kubernetes.io/component label. You can use these labels with kubectl logs -l to collect or stream logs from many pods at once, rather than one pod at a time.

All pods deployed by the chart:

kubectl logs -n <your-namespace> \
  -l app.kubernetes.io/name=<release>-enterprise \
  --all-containers=true --prefix=true --tail=-1 --max-log-requests=20

--prefix=true prepends each line with its pod and container name so you can tell the services apart.
--tail=-1 returns the full available log for each pod. When you select by label, kubectl otherwise defaults to only the last 10 lines per pod.
--max-log-requests defaults to 5 and must be raised when your selector matches more pods than that, or the command errors. Set it to at least the number of matched pods.
Add -f to follow (stream) the logs live.

All logs for a single service:

Add the app.kubernetes.io/component label to target one service. For example, to follow the analyzer:

kubectl logs -n <your-namespace> \
  -l app.kubernetes.io/name=<release>-enterprise,app.kubernetes.io/component=analyzer \
  --all-containers=true --prefix=true --tail=-1 -f

The component values map to the Anchore Enterprise services as follows:

Service	`app.kubernetes.io/component`
API	`api`
Analyzer	`analyzer`
Catalog	`catalog`
Data Syncer	`datasyncer`
Notifications	`notifications`
Policy Engine	`policyengine`
Reports	`reports`
Reports Worker	`reportsworker`
SimpleQueue	`simplequeue`
UI	`ui`

kubectl logs -l reads only from currently running pods. To see the logs of a pod that has already crashed and restarted, add --previous. You can also narrow output with --since=1h or --since-time=<RFC3339-timestamp>. For durable history that survives pod restarts, ship logs to an aggregation stack such as Loki, Elasticsearch, or your cloud provider’s logging service.

Trace an Image Through the Analyzer

If you want to trace an image’s journey through the analyzer to track whether it completes successfully, you can do this using the logged events and finding the Thread that the analysis is occurring on - in the below example, we noticed that the processes related to the node:latest image we submitted for analysis were occurring on Thread-5 when observing analyzer logs, so we were able to grep for this to see the entire process;

kubectl logs -n anchore anchore-enterprise-analyzer-5f49795899-9zc65 | grep Thread-5
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:12:10.145453+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.analysis/process_analyzer_job():468] | image dequeued for analysis: admin : sha256:89fd332d61ce0d8ebb85c847a9171c67d00fd9309d20a83d45b1fe2a7207af5c
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:12:10.190503+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.analysis/perform_analyze():264] | performing analysis on image: ['admin', 'docker.io/library/node@sha256:89fd332d61ce0d8ebb85c847a9171c67d00fd9309d20a83d45b1fe2a7207af5c', 'docker.io/library/node:latest']
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:12:10.193547+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.analysis/perform_analyze():269] | analyzing image admin: docker.io/library/node@sha256:89fd332d61ce0d8ebb85c847a9171c67d00fd9309d20a83d45b1fe2a7207af5c
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:12:10.193750+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.localanchore_standalone/analyze_image():812] | Analyzing Full Tag: docker.io/library/node:latest with Source: registry Dockerfile Mode: Guessed and Contents: False
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:12:10.194239+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.localanchore_standalone/pull_image():501] | Downloading image docker.io/library/node@sha256:89fd332d61ce0d8ebb85c847a9171c67d00fd9309d20a83d45b1fe2a7207af5c for analysis to /analysis_scratch/5538f6c3-366e-4e47-8d18-690bb2eb66dd/raw
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:12:30.139926+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.utils/timer():910] | Execution of Executing analyzer /home/anchore/venv/lib64/python3.12/site-packages/anchore_enterprise/services/analyzer/analyzers/modules/01_analyzer_meta.py took: 1.13681960105896 seconds
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:12:31.355471+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.utils/timer():910] | Execution of Executing analyzer /home/anchore/venv/lib64/python3.12/site-packages/anchore_enterprise/services/analyzer/analyzers/modules/02_analyzer_windows.py took: 1.2146642208099365 seconds
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:15:02.832641+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.analyzers.syft.adapters/_convert_syft_to_engine():322] | filtering owned packages
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:15:04.437364+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.analysis/perform_analyze():286] | performing analysis on image complete admin: docker.io/library/node@sha256:89fd332d61ce0d8ebb85c847a9171c67d00fd9309d20a83d45b1fe2a7207af5c
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:15:04.438051+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.analysis/process_analyzer_job():521] | No anchore hints found in retrieved image data
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:15:04.439172+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.analysis/store_analysis_results():726] | adding image analysis data to catalog: account_name=admin image_id=0b58171b7f6dcafeb1893f84ae02f743f3e7facb3112987afc5c6f2b66e591dc image_digest=sha256:89fd332d61ce0d8ebb85c847a9171c67d00fd9309d20a83d45b1fe2a7207af5c
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:15:04.439421+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.utils/upload_document_with_retry():269] | Attempting upload of syft_sbom
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:15:05.219587+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.utils/upload_document_with_retry():276] | Successfully uploaded syft_sbom
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:15:05.219947+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.utils/upload_document_with_retry():269] | Attempting upload of analysis_data
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:15:06.323650+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.utils/upload_document_with_retry():276] | Successfully uploaded analysis_data
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:15:06.975603+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.analysis/import_to_policy_engine():350] | loading image into policy engine: account_name=admin image_id=0b58171b7f6dcafeb1893f84ae02f743f3e7facb3112987afc5c6f2b66e591dc image_digest=sha256:89fd332d61ce0d8ebb85c847a9171c67d00fd9309d20a83d45b1fe2a7207af5c
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:15:11.908357+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.utils/update_analysis_complete():126] | Updating image catalog record with analysis results
[service:anchore-enterprise-analyzer-v6.0.0] [2025-10-10T11:15:11.935663+00:00] [MainProcess] [Thread-5] [INFO] [anchore_enterprise.services.analyzer.analysis/process_analyzer_job():553] | analysis complete: admin sha256:89fd332d61ce0d8ebb85c847a9171c67d00fd9309d20a83d45b1fe2a7207af5c

4 - Viewing System Events

If you’ve successfully verified that all Anchore Enterprise services are up, but are still running into issues operating Anchore, a good place check is the event log.

The event log subsystem provides users with a mechanism to inspect asynchronous events occurring across various Anchore Enterprise services. Anchore events include periodically-triggered activities such as vulnerability data feed sync in the policy_engine service, image analysis failures originating from the analyzer service, and other informational or system fault events. The catalog service may also generate events for any repositories or image tags that are being watched when Anchore Enterprise encounters connectivity, authentication, authorization, or other errors in the process of checking for updates.

The event log is aimed at troubleshooting most common failure scenarios, especially those that happen during asynchronous operations, and to pinpoint the reasons for failures that can be used subsequently to help with corrective actions. Events can be cleared from Anchore Enterprise in bulk or individually.

Viewing Events

The recent events can be viewed inside the Anchore Enterprise GUI on the Events & Notifications tab:

If using AnchoreCTL, running the following command will give a list of recent Anchore Enterprise events: anchorectl event list

Viewing list of recent Anchore Enterprise events

anchorectl event list
 ✔ List events
┌──────────────────────────────────┬──────────────────────────────────────────────┬───────┬───────────────────────────────────────────────────────┬─────────────────┬────────────────┬────────────────────┬─────────────────────────────┐
│ UUID                             │ EVENT TYPE                                   │ LEVEL │ RESOURCE ID                                           │ RESOURCE TYPE   │ SOURCE SERVICE │ SOURCE HOST        │ TIMESTAMP                   │
├──────────────────────────────────┼──────────────────────────────────────────────┼───────┼───────────────────────────────────────────────────────┼─────────────────┼────────────────┼────────────────────┼─────────────────────────────┤
│ 329ff24aa77549458e2656f1a6f4c98f │ system.image_analysis.registry_lookup_failed │ error │ docker.io/alpine:3.4                                 │ image_reference │ catalog        │ anchore-quickstart │ 2022-08-24T22:08:29.026352Z │
│ 4010f105cf264be6839c7e8ca1a0c46e │ system.image_analysis.registry_lookup_failed │ error │ docker.io/alpine:latest                              │ image_reference │ catalog        │ anchore-quickstart │ 2022-08-24T22:08:28.991101Z │
│ 6924eb83313746ff8b842a88654e3ac1 │ system.image_analysis.registry_lookup_failed │ error │ docker.io/alpine:3.12                                │ image_reference │ catalog        │ anchore-quickstart │ 2022-08-24T22:08:28.956321Z │
│ efdcf727647c458f85cb6464926e474d │ system.image_analysis.registry_lookup_failed │ error │ docker.io/nginx:latest                               │ image_reference │ catalog        │ anchore-quickstart │ 2022-08-24T22:08:28.920222Z │
...
│ 1eb04509b2bc44208cdc7678eaf76fef │ user.image.analysis.completed                │ info  │ docker.io/ubuntu:latest                               │ image_tag       │ analyzer       │ anchore-quickstart │ 2022-08-24T22:06:13.736004Z │
│ 6f735f8db7e84ce19b221d3b024318af │ user.image.analysis.processing               │ info  │ docker.io/ubuntu:latest                               │ image_tag       │ analyzer       │ anchore-quickstart │ 2022-08-24T22:06:13.128912Z │
│ 480eb191f87440b48c9f8cfa6529badf │ user.image_tag.added                         │ info  │ docker.io/ubuntu:latest                               │ image_tag       │ catalog        │ anchore-quickstart │ 2022-08-24T22:06:08.307039Z │
...
└──────────────────────────────────┴──────────────────────────────────────────────┴───────┴───────────────────────────────────────────────────────┴─────────────────┴────────────────┴────────────────────┴─────────────────────────────┘

Details About a Specific Event

If you would like more information about a specific event, you can run the following command: anchorectl event get <event-id>

Details about a specific Anchore Enterprise event

anchorectl event get 1eb04509b2bc44208cdc7678eaf76fef
 ✔ Fetched event
UUID: 1eb04509b2bc44208cdc7678eaf76fef
Event:
  Event Type: user.image.analysis.completed
  Level: info
  Message: Image analysis available
  Resource:
    Resource ID: docker.io/ubuntu:latest
    Resource Type: image_tag
    User Id: admin
  Source:
    Source Service: analyzer
    Base Url: http://analyzer:8228
    Source Host: anchore-quickstart
    Request Id:
  Timestamp: 2022-08-24T22:06:13.736004Z
  Category:
  Details:
Created At: 2022-08-24T22:06:13.832881Z

Depending on the output from the detailed events, looking into the logs for a particular servicename (example: policy_engine) is the next troubleshooting step.

Failures Between Services

Anchore Enterprise services call one another to do their work — for example, the analyzer calls the policy engine, and the policy engine calls the catalog. When one service cannot reach another, the event or error is usually emitted by the calling service, but the root cause lies in the destination service it was trying to reach.

When an event or log line reports that one service failed while talking to another — for example, the analyzer failing to reach the policy engine, or the policy engine failing to reach the catalog — inspect the logs of the destination service (the one being called) over the same time window to find the actual failure. The calling service’s log tells you what it was attempting; the destination service’s log usually explains why it failed. See Viewing Logs for retrieving a specific service’s logs.

5 - Data Syncer

Anchore Enterprise runs a hosted data service called the Anchore Data Service. This service publishes datasets from a number of provider sources. The Data Syncer Service is a core component of Enterprise. Its job is to periodically query Anchore Data Service and download any new datasets available.

Performing a Basic Health Check

Run anchorectl feed list as admin and ensure that:

The last sync date shown is recent and that the feed has enabled set to true.

Run anchorectl feed sync as admin which will:

Queue an update to fetch the data from the data service and propagate feed data across internal services.
- Otherwise, this runs on a regular schedule.

You can also visually check the health in the System section of the GUI when logged in as admin.

Configuration Checks

Check that the feed pod/container has enough disk space:

Storage

Ensure your data syncer pod has enough storage (around 2 GB of writable space) to cache the datasets to disk, this reduces database queries.

Memory

Ensure the data syncer pod has sufficient memory (around 2 GB), especially if you are running multiple analyzers

Network

Ensure your data-syncer pod / container has network connectivity to hosted feed service by exec’ing into the container and then:
- If you have a network proxy deployed, you might need to configure your feed service to utilize it:
Ensure your policy pod / container has network connectivity to your local data-syncer pod / container
- Run e.g. curl http://anchore-data-syncer:8228/v2/datasets/vulnerability_db/6/latest returns success to confirm connectivity.

Operational Checks and Verification

Feed list show up empty: Check if your feed syncs are happening, there should be data_syncer events in the event log. You should see successful events in the event log. In case there are failures click on the event log and see the cause for failure.
Data-syncer is reporting errors fetching new datasets: Check the Anchore Data Service Status Page. If the service is reporting up and running then check your firewall settings. If the service is reporting any failures please wait for the service to recover.
I see a lot of 404’s in the data-syncer and policy engine logs as soon as the services start: This is normal, the data-syncer takes a few minutes after startup to successfully sync down the configured datasets from the Anchore Data Service. The Policy Engine Service starts asking for the latest vulnerability dataset as soon as it starts up, it takes a few minutes for the system to reconcile. (This is only true for new greenfield deployments)
My first analyzer scan takes longer than the rest: First analyzer scan can take up to 5 minutes, this is just due to the analyzer waiting for the data-syncer to sync down a ClamAV database. Subsequent scans will not incur this penalty.

6 - Verifying Service Health

You can verify which services have registered themselves successfully, along with their status, by running: anchorectl system status

anchorectl system status
 ✔ Status system
┌───────────────────┬────────────────────┬───────────────────────────────┬──────┬────────────────┬────────────┬──────────────┐
│ SERVICE           │ HOST ID            │ URL                           │ UP   │ STATUS MESSAGE │ DB VERSION │ CODE VERSION │
├───────────────────┼────────────────────┼───────────────────────────────┼──────┼────────────────┼────────────┼──────────────┤
│ simplequeue       │ anchore-quickstart │ http://queue:8228             │ true │ available      │ 6010       │ 6.1.1        │
│ component_catalog │ anchore-quickstart │ http://component-catalog:8228 │ true │ available      │ 6010       │ 6.1.1        │
│ notifications     │ anchore-quickstart │ http://notifications:8228     │ true │ available      │ 6010       │ 6.1.1        │
│ reports_worker    │ anchore-quickstart │ http://reports_worker:8228    │ true │ available      │ 6010       │ 6.1.1        │
│ data_syncer       │ anchore-quickstart │ http://data-syncer:8228       │ true │ available      │ 6010       │ 6.1.1        │
│ reports           │ anchore-quickstart │ http://reports:8228           │ true │ available      │ 6010       │ 6.1.1        │
│ analyzer          │ anchore-quickstart │ http://analyzer:8228          │ true │ available      │ 6010       │ 6.1.1        │
│ apiext            │ anchore-quickstart │ http://api:8228               │ true │ available      │ 6010       │ 6.1.1        │
│ catalog           │ anchore-quickstart │ http://catalog:8228           │ true │ available      │ 6010       │ 6.1.1        │
│ policy_engine     │ anchore-quickstart │ http://policy-engine:8228     │ true │ available      │ 6010       │ 6.1.1        │
└───────────────────┴────────────────────┴───────────────────────────────┴──────┴────────────────┴────────────┴──────────────┘

This can also be found in the GUI under the System tab, where each service will be laid out with information on its name, status, and other related information:

gui_service_health

If specific services are down, you can investigate the logs for the services. For more information, see Viewing Logs.

Database Availability

All Anchore Enterprise services depend on the shared PostgreSQL database. When the database becomes unavailable, the effect on the services depends on when it happens:

Database down at startup: Services will not finish starting. They wait on the database and never reach the available state, so anchorectl system status shows them as down (or they never register at all).
Database stops while services are running: The services keep running and may still appear up, but nearly all operations fail because the database is not reachable. Image analysis, policy evaluation, and API requests return database errors until the database is restored.
Not enough connections: If the database is running but has exhausted its connection limit, operations fail intermittently with connection errors even though the database process itself is healthy. Anchore Enterprise can require hundreds to thousands of concurrent connections; size the database’s max_connections for your number of service replicas. See Requirements.

To diagnose, confirm the database process is running and reachable from the deployment, check that it has free connections available, and review the affected service logs (see Viewing Logs) for connection or could not connect errors.

The -vvvv and -o json Options

Passing a high-verbosity flag (-vvvv) to AnchoreCTL can often help narrow down particular issues by displaying the client configuration and client functions as they are running:

Example system status with -vvvv

anchorectl system status -vvvv
[0000]  INFO anchorectl version: v6.1.0
[0000] DEBUG application config:
  url: http://localhost:8228
  username: admin
  password: '******'
  account: ""
  skip-api-version-check: false
  ui-url: ""
  check-for-updates: true
  config: /Users/lzw/.anchorectl.yaml
  quiet: false
  log:
    level: trace
    file: ""
  debug:
    api: false
    events: false
  http:
    tls-insecure: true
    timeout: 180
    headers: {}
  dev:
    profile-cpu: false
    profile-mem: false
  registry:
    insecure-skip-tls-verify: false
    insecure-use-http: false
    auth: []
  secret-search:
    cataloger:
      enabled: false
      scope: all-layers
    additional-patterns: {}
    exclude-pattern-names: []
    reveal-values: false
    skip-files-above-size: 1048576
  content-search:
    cataloger:
      enabled: false
      scope: all-layers
    patterns: {}
    reveal-values: false
    skip-files-above-size: 1048576
  file-contents:
    cataloger:
      enabled: false
      scope: squashed
    skip-files-above-size: 1048576
    globs: []
  syft-parallelism: 0
[0000] DEBUG command config:
  format: text
[0000] DEBUG checking for anchorectl updates from Enterprise
[0000] DEBUG current anchorectl version: v6.1.0
[0000] DEBUG querying Enterprise for available tools (darwin/arm64)
[0000] DEBUG version check result: enterprise=6.1.1, anchorectl=v6.1.0, mismatch=false
[0000] DEBUG anchorectl version matches Enterprise (current: v6.1.0, enterprise: 6.1.1)
[0000] TRACE worker stopped component=eventloop
[0000] TRACE bus stopped component=eventloop
┌───────────────────┬────────────────────┬───────────────────────────────┬──────┬────────────────┬────────────┬──────────────┐
│ SERVICE           │ HOST ID            │ URL                           │ UP   │ STATUS MESSAGE │ DB VERSION │ CODE VERSION │
├───────────────────┼────────────────────┼───────────────────────────────┼──────┼────────────────┼────────────┼──────────────┤
│ simplequeue       │ anchore-quickstart │ http://queue:8228             │ true │ available      │ 6010       │ 6.1.1        │
│ catalog           │ anchore-quickstart │ http://catalog:8228           │ true │ available      │ 6010       │ 6.1.1        │
│ notifications     │ anchore-quickstart │ http://notifications:8228     │ true │ available      │ 6010       │ 6.1.1        │
│ reports_worker    │ anchore-quickstart │ http://reports_worker:8228    │ true │ available      │ 6010       │ 6.1.1        │
│ data_syncer       │ anchore-quickstart │ http://data-syncer:8228       │ true │ available      │ 6010       │ 6.1.1        │
│ reports           │ anchore-quickstart │ http://reports:8228           │ true │ available      │ 6010       │ 6.1.1        │
│ analyzer          │ anchore-quickstart │ http://analyzer:8228          │ true │ available      │ 6010       │ 6.1.1        │
│ apiext            │ anchore-quickstart │ http://api:8228               │ true │ available      │ 6010       │ 6.1.1        │
│ policy_engine     │ anchore-quickstart │ http://policy-engine:8228     │ true │ available      │ 6010       │ 6.1.1        │
│ component_catalog │ anchore-quickstart │ http://component-catalog:8228 │ true │ available      │ 6010       │ 6.1.1        │
└───────────────────┴────────────────────┴───────────────────────────────┴──────┴────────────────┴────────────┴──────────────┘

Passing the -o json option to AnchoreCTL commands will output the API response data in JSON, which often contains much more information than what the CLI outputs by default for both regular successful operations, and for operations that are resulting in an error:

anchorectl -o json system status
 ✔ Status system
{
  "serviceStates": [
    {
      "baseUrl": "http://reports_worker:8228",
      "hostid": "anchore-quickstart",
      "serviceDetail": {
...
...

7 - Error Codes

Reference of Anchore Enterprise error codes with their message, HTTP status, and remediation steps.

Anchore Enterprise returns a structured error code with most API error responses. Each code has the form XX###, where the two-letter prefix identifies the domain that raised the error (for example, AP for Applications) and the number identifies the specific condition. A code ending in 000 is the general, catch-all error for that domain.

Error responses also include an anchore_request_id. When contacting Anchore support, include both the error code and the request id so the originating request can be located in the service logs.

The codes below are grouped by prefix and listed in ascending order within each group.

AP — Applications

Code	Message	HTTP	Remediation
`AP000`	General Application Error	500	Inspect server logs around the request_id for the underlying error. If the failure is reproducible, capture the request and contact support.
`AP501`	Application Not Found	404	Verify the application id (UUID) is correct. List applications under the same account to confirm the application exists. Confirm the account header on the request matches the account that owns the application.
`AP502`	Application Has Versions	409	Re-issue the delete with the `force` flag to cascade-delete the application’s versions and assets. Or delete each version under the application before deleting the application itself.
`AP503`	Policy Not Found	404	Verify the policy_id refers to an existing policy in the catalog service. Send null for policy_id to clear the policy and inherit the account default. Omit the policy_id field on update to leave the existing policy unchanged.
`AP504`	Policy Fetch Failed	502	Retry the request — the catalog service may be transiently unavailable. Verify the catalog service is healthy. Inspect server logs around the request_id for the upstream error detail.
`AP505`	Application Name Conflict	409	Pick a different name that’s unique within the account. Or update the existing application instead of creating a new one.
`AP506`	Application Field Validation Failed	422	Inspect the `detail` array for per-field validation messages. Each entry’s `loc` identifies the offending field; `msg` describes the problem. Resend the request with valid values.

AS — Assets & SBOMs

Code	Message	HTTP	Remediation
`AS000`	General Asset Error	500	Inspect server logs around the request_id for the underlying error. If the failure is reproducible, capture the request and contact support.
`AS501`	Asset Not Found	404	Verify the asset id (UUID) is correct under the given application id and version id. List assets under the version to confirm the asset exists. If the asset was just created via SBOM upload, wait for the import job to complete first.
`AS502`	Asset SBOM Not Found	404	Confirm the asset has an associated SBOM artifact in its artifacts list. If the artifact exists but its body is missing, the object-store key has been removed externally — re-upload the SBOM to re-create it.
`AS503`	Asset Name Conflict	409	Pick a different asset name that’s unique within the application version. Or update the existing asset instead of creating a new one.
`AS504`	Asset Artifact Not Found	404	Re-fetch the asset and confirm its artifacts list is non-empty. If the artifact was deleted out-of-band, re-upload the SBOM to re-create it.
`AS505`	Invalid Annotations	422	Send annotations as a flat object of string keys and string values (use null as a value to delete a key on update). Cap each annotation key at 150 characters and each value at 1000 characters. Cap total annotations on an asset at 10 entries. Inspect the response message for the specific limit that was breached.
`AS510`	SBOM Parse Failed	400	Inspect the AssetAddFailed event’s error_reason for the parser’s specific message. Validate the SBOM with the format’s reference tooling before re-uploading.
`AS511`	SPDX Parse Failed	400	Verify required SPDX fields are present (spdxVersion, SPDXID, documentNamespace, creationInfo). Validate the document with the SPDX online validator or `pyspdxtools`.
`AS512`	CycloneDX Parse Failed	400	Validate the document against the CycloneDX schema for its specVersion. Confirm the document is well-formed JSON/XML before re-uploading.
`AS513`	Unsupported CycloneDX Spec Version	400	Re-export the SBOM targeting one of the supported specVersion values listed in the error_reason.
`AS514`	Invalid CycloneDX XML Structure	400	Verify the document parses as XML and uses the http://cyclonedx.org/schema/bom/<version> namespace on the <bom> root.
`AS515`	Unrecognised SBOM Format	400	Verify the file is a non-empty Syft JSON, SPDX JSON or tag-value, or CycloneDX JSON or XML document. Inspect the AssetAddFailed event’s error_reason for the specific marker that was missing.
`AS516`	Syft Parse Failed	400	Re-export the SBOM with a current Syft or anchorectl release (`syft <target> -o syft-json` / `anchorectl image sbom`). Verify `schema.version` matches the format `MAJOR.MINOR.PATCH` (e.g. `16.0.39`).

AU — Authentication

Code	Message	HTTP	Remediation
`AU000`	General Authentication Error	401	Inspect the response message for the underlying detail. Confirm the request includes a valid Bearer token. If the failure is reproducible with valid credentials, capture the request and contact support.
`AU001`	Missing Authorization Header	401	Include an Authorization header on the request using the Bearer scheme. If using a client SDK, confirm credentials are configured before issuing the call.
`AU002`	Invalid Authorization Scheme	401	Use the Bearer scheme on the Authorization header (“Bearer <token>”). Other schemes (Basic, Digest, etc.) are not accepted on internal endpoints.
`AU003`	Authentication Not Configured	401	Wait for the service to finish bootstrapping and retry. Verify the service has a valid keys configuration (signing key or shared secret). Check service logs for token manager initialization errors.
`AU004`	Invalid or Expired Token	401	Obtain a new token and retry the request. Confirm the client and server clocks are reasonably in sync; large drift can cause valid tokens to appear expired. If using a long-lived token, confirm it has not been revoked.

AV — Application Versions

Code	Message	HTTP	Remediation
`AV000`	General Application Version Error	500	Inspect server logs around the request_id for the underlying error. If the failure is reproducible, capture the request and contact support.
`AV501`	Application Version Not Found	404	Verify the version id (UUID) is correct. List versions under the parent application to confirm the version exists. Confirm both the application id and the version id belong to the account on the request header.
`AV502`	Application Version Has Assets	409	Re-issue the delete with the `force` flag to cascade-delete the version’s assets. Or delete each asset under the version before deleting the version itself.
`AV503`	Application Version Name Conflict	409	Pick a different version name that’s unique within the parent application. Or update the existing version instead of creating a new one.
`AV504`	Invalid Previous Version Reference	422	Confirm previous_version_id is the UUID of an existing version under the same application. Send null (or omit the field) when there is no previous version.
`AV505`	Application Version Referenced	409	Update the referencing version to clear or change its previous_version_id before deleting this one. Or use the `force` flag on the delete — the server will null out the inbound references.
`AV506`	Application Version Cannot Reference Itself	422	Set previous_version_id to the UUID of a different version under the same application. Send null (or omit the field) when there is no previous version.

AX — Image Input

Code	Message	HTTP	Remediation
`AX500`	Image reference must be a non-empty string	400	—
`AX501`	Image reference has no pullable form	400	—
`AX502`	Cannot handle image input string	400	—

CF — Configuration

Code	Message	HTTP	Remediation
`CF000`	General Configuration Error	500	Inspect server logs around the request_id for the underlying error. If reproducible, capture the request and contact support.
`CF301`	Configuration File Not Found	500	Verify the configuration file path matches the deployment’s filesystem layout. Ensure the file exists and is readable by the service process. Check the deployment’s volume mounts and environment overrides for the path.
`CF302`	Configuration Validation Failed	500	Check the configuration file against the expected schema. Review the validation errors in the response and the service logs for the offending fields. Fix the offending values and restart the service.
`CF303`	Required Environment Variable Not Found	500	Set the required environment variable before starting the service. Confirm the service’s environment file or container env list includes the variable.
`CF501`	Configuration API Disabled	403	Enable the API-driven configuration feature flag in the deployment’s config file. Restart the service for the flag change to take effect.
`CF502`	Configuration Key Not Found	404	Verify the configuration key name is correct. Some keys are private to the service and not exposed via the API; consult the configuration documentation for the exposed surface.
`CF503`	Configuration Key Not Editable	403	Confirm the key is documented as editable; immutable / system-internal keys must be set in the config file at deploy time. If the key was recently demoted to read-only, capture the request and contact support.
`CF504`	Configuration Key Blocked By Config File	409	Edit the value in the deployment’s config file and restart the service. Or remove the key from the config file so the API can manage it (the service will use the default until set via API).
`CF505`	Configuration Schema Validation Failed	400	Inspect the response message for the field and constraint that failed. Submit a value matching the field’s documented type and bounds.
`CF506`	Configuration Schema Inconsistency	500	Verify that every API-editable key produces a leaf value when a default RootConfig is flattened. Check for recent changes to Optional fields or discriminated unions in the config models.
`CF507`	Configuration Key Mismatch	400	Set the body’s `key` field to the same value as the URL path segment. Or change the URL path segment to match the key already in the body.

DB — Database

Code	Message	HTTP	Remediation
`DB000`	General Database Error	500	Inspect server logs around the request_id for the underlying SQL error. If the failure is reproducible, capture the request and contact support.
`DB201`	Database Connection Failed	500	Verify the database connection string. Ensure the database server is running and accessible. Check network policies / firewalls between the service pod and the database.
`DB202`	Database TLS Error	500	Verify TLS certificates are correctly configured. Ensure the database supports the required TLS version. If using a custom CA bundle, confirm the bundle is mounted on the service pod.
`DB203`	EMS Not Enabled	500	Upgrade the database to Postgres 16 or greater. Move the deployment to non-FIPS-enabled hosts. Contact the Customer Success Team for assistance.
`DB204`	Database Insert Conflict	409	Inspect the response message for the conflicting field. Resubmit with a value that doesn’t collide with the existing row, or update the existing row instead.
`DB205`	Unhandled Database Integrity Error	500	Inspect server logs around the request_id for the underlying constraint name. If reproducible from a well-formed request, capture the request body and report a bug — this should be a 4xx with a typed code.

JB — Jobs

Code	Message	HTTP	Remediation
`JB000`	General Job Error	500	Inspect server logs around the request_id for the underlying error. If the failure is reproducible, capture the request and contact support.
`JB501`	Job Not Found	404	Verify the job id (UUID) is correct. List jobs under the parent application to confirm the job exists. Confirm the account header matches the account that submitted the job. If the job is a workflow step (not the workflow root), it is intentionally hidden — fetch the parent workflow id instead.
`JB502`	Job Not Found For Type	404	Confirm the job id matches a job whose type belongs to this endpoint’s category (e.g. SBOM-export endpoints only resolve SBOM-export jobs). Use the generic job lookup endpoint to inspect the job’s actual type.
`JB506`	Invalid Annotations JSON	422	Send the annotations form field as a JSON-encoded string of an object. Check for unescaped quotes when embedding JSON in a multipart form field.
`JB507`	Invalid Annotations Format	422	Send annotations as a flat object — no nested objects, no arrays, no numeric / boolean / null values. Cast all values to strings client-side before encoding.
`JB508`	App Version Not Found	404	Verify the app_version_id on the request body matches an existing version under the parent app. List versions under the application to find the correct version id.
`JB509`	Asset Not Found	404	Verify the asset_id on the request body matches an existing asset under the version. List assets under the version to find the correct asset id.
`JB513`	Cannot Cancel Workflow Step	409	Cancel the parent workflow job (its workflow_id is the same as its job_id) instead of the step. The response message includes the parent workflow id you should target.
`JB515`	Missing Username For Owner Filter	400	Send the x-anchore-username header on requests that use owned_by_me=true. Or drop the owned_by_me parameter to list jobs across all users in the account.
`JB516`	Export File Not Found	404	Re-submit the export job — the previous result has been garbage-collected or the disk it was on is gone. Confirm the job status is complete before requesting the download.

JF — Job Framework

Code	Message	HTTP	Remediation
`JF000`	General Job Framework Error	500	Inspect server logs around the request_id for the underlying error. If the failure is reproducible, capture the request and contact support.
`JF501`	Framework Job Not Found	404	Verify the job id is correct. List jobs through the job-framework admin surface to confirm the job exists.
`JF502`	Framework Job Logs Not Found	404	Verify the job id is correct. Logs may have been garbage-collected; for long-running diagnostics, capture logs while the job is still active.
`JF503`	Framework Job Not Found For Cancel	404	Verify the job id is correct. If the job has already terminated, no cancel is needed — re-fetch its status.
`JF506`	Job Type Not Registered	500	Confirm the service is fully started — handler registration happens during bootstrap. If the job type is new, verify the handler module is imported on service startup.
`JF507`	Job Handler Exception	500	Inspect the job’s error_reason field for the handler’s specific exception. Re-submit the job after addressing the underlying cause (bad input, missing data, transient upstream failure).
`JF508`	Job Timeout Exceeded	500	Re-submit the job — repeated timeouts on the same input may indicate an unusually large payload or a degraded backing service. If the job consistently times out, contact support to evaluate raising the per-type timeout for this deployment.
`JF509`	Job Memory Limit Exceeded	500	Re-submit with a smaller input if the size of the input scales with memory. Contact your system administrator if the failure persists at typical input sizes.
`JF510`	Job CPU Limit Exceeded	500	Re-submit the job — the limit may have been hit due to noisy-neighbour scheduling on the worker pod. If the failure repeats, contact your system administrator to evaluate raising worker resources.
`JF511`	Worker Died	500	Check worker logs for crash details. Ensure sufficient resources for workers. Re-submit the job once the worker pool has stabilised.
`JF512`	Workflow Type Not Registered	500	Confirm the service is fully started — workflow registration happens during bootstrap. If the workflow type is new, verify its module is imported on service startup.
`JF513`	Workflow Step Not Found	500	Inspect the workflow record’s step list to confirm the step was registered. If reproducible, capture the workflow id and contact support.
`JF514`	Job Retries Exhausted	500	Inspect the job’s error_reason for the failure that triggered every retry. Address the underlying cause and re-submit the job from scratch.

PG — Pagination

Code	Message	HTTP	Remediation
`PG000`	General Pagination Error	500	Inspect the response message for the underlying detail. If reproducible, capture the request and contact support.
`PG501`	Invalid Pagination Cursor	400	Drop the cursor / token parameter to fetch the first page from scratch. When paging, only ever send back the next_cursor / next_token value verbatim — don’t construct or modify cursors client-side. If the cursor stops decoding mid-walk, it likely belongs to a different list query (filters or sort changed); restart pagination with the new criteria.

PK — Packages

Code	Message	HTTP	Remediation
`PK000`	General Package Error	500	Inspect server logs around the request_id for the underlying error. If the failure is reproducible, capture the request and contact support.
`PK501`	Package Not Found	404	Verify the package id is correct. List packages under the version to confirm the package exists — packages are derived from the version’s SBOM, so absence usually means the package wasn’t in the SBOM.
`PK502`	Invalid Package Filter	422	Inspect the response message — it lists the operators allowed for the field. Switch to one of the listed operators, or pick a different field.
`PK503`	Conflicting Package Type	422	Remove the type parameter and let it be inferred from namespace. Ensure type matches the first segment of namespace.
`PK504`	Advisory Has Multiple Related CVEs	400	Query each related CVE listed in the response message directly. A singleton advisory (exactly one related CVE) or a bare CVE id is accepted.

PO — Policy

Code	Message	HTTP	Remediation
`PO000`	General Policy Error	500	Inspect server logs around the request_id for the underlying error. If the failure is reproducible, capture the request and contact support.
`PO501`	Policy Not Found	404	Verify the policy_id is correct. Confirm the policy exists in the catalog service for this account.
`PO502`	Policy Fetch Failed	502	Verify the catalog service is running and healthy. If the application has an active_policy_id, verify the policy exists. Retry the request — the upstream catalog service may be transiently unavailable.
`PO503`	No Active Policy	404	Update the application to set an active_policy_id pointing to a valid policy. Or configure an account-level default policy in the policy service so applications without an explicit policy fall back to it.
`PO504`	Policy Evaluation Stale	409	Trigger a policy re-evaluation for this app version. Retry the request after the evaluation job completes.

SE — Search & Filtering

Code	Message	HTTP	Remediation
`SE000`	General Search Error	500	Inspect the response message for the underlying detail. If the failure is reproducible, capture the request and contact support.
`SE501`	Unknown Filter Field	422	Check the OpenAPI documentation for the search endpoint to see the allowed field values. For asset annotations, use the annotations.<key> dot-notation form. Remove or correct the offending entry in the filters or sort array.
`SE502`	Unsupported Filter Operator	422	Inspect the response message — it lists the operators allowed for the field. Switch to one of the listed operators, or pick a different field.
`SE503`	Invalid Filter Value Shape	422	Inspect the response message for the expected shape. For the in operator, pass an array; for scalar comparators, pass a scalar matching the field’s type.
`SE504`	Unsupported Sort Field	422	Inspect the response message — it lists the offending field. Remove the sort entry, or pick a different field that supports ordering.

VS — Vulnerability Scanning

Code	Message	HTTP	Remediation
`VS001`	Grype rejected package input	500	Inspect the package’s purl/cpes for malformed values (URL-encoded delimiters, embedded sha256, etc.). Re-upload a corrected SBOM.

VX — Vulnerability Annotations

Code	Message	HTTP	Remediation
`VX000`	General Vulnerability Annotation Error	500	Inspect server logs around the request_id for the underlying error. If the failure is reproducible, capture the request and contact support.
`VX501`	Vulnerability Annotation Not Found	404	Verify the vulnerability annotation id (UUID) is correct. List annotations under the version to confirm the annotation exists. Confirm both the application id and the version id belong to the account on the request header.
`VX502`	Vulnerability Annotation Conflict	409	Look up the existing annotation by scope/vulnerability_id/package_* and update it instead. Or change one of scope, vulnerability_id, package_name, package_version, or package_type so the new annotation has a unique tuple.

WK — Worker

Code	Message	HTTP	Remediation
`WK000`	General Worker Error	500	Inspect server logs around the request_id for the underlying error. If the failure is reproducible, capture the request and contact support.
`WK501`	Worker Pool Not Found	404	Verify the worker pool name is correct. List worker pools to confirm the pool exists in this deployment.

8 - Helm and Kubernetes Deployments

Troubleshoot common issues with Anchore Enterprise Helm and Kubernetes deployments.

This page covers troubleshooting specific to Anchore Enterprise deployments running on Kubernetes with the Helm chart.

Pods Restart Shortly After Starting

Symptom: One or more Anchore Enterprise pods repeatedly restart soon after starting — sometimes within about ten seconds — and kubectl get pods shows a climbing RESTARTS count or pods in CrashLoopBackOff. Running kubectl describe pod <pod-name> shows Liveness probe failed or Readiness probe failed events, and the container is killed and restarted.

Cause: The default liveness and readiness probe timings can be too aggressive for slower or resource-constrained clusters, or for services that legitimately take longer to become ready — for example during first boot, a database schema upgrade or migration, or a large vulnerability feed sync. When the liveness probe fails before the service has finished starting, Kubernetes kills and restarts the container before it can come up, producing a restart loop.

Fix: Increase the probe tolerances in your values file. The chart exposes a top-level probes block that applies to all Anchore Enterprise services. Raising initialDelaySeconds, timeoutSeconds, periodSeconds, and failureThreshold gives services more time to start and respond before Kubernetes considers them unhealthy:

probes:
  liveness:
    initialDelaySeconds: 120
    timeoutSeconds: 30
    periodSeconds: 30
    failureThreshold: 6
    successThreshold: 1
  readiness:
    initialDelaySeconds: 60
    timeoutSeconds: 30
    periodSeconds: 30
    failureThreshold: 3
    successThreshold: 1

Apply the change with helm upgrade, then watch the pods stabilize:

helm upgrade <release> -n <namespace> anchore/enterprise -f anchore_values.yaml
kubectl get pods -n <namespace> -w

These values relax the chart defaults, where the liveness timeoutSeconds and periodSeconds are both 10. Treat them as a starting point and tune them to your environment. If pods still restart, view the logs and verify service health to confirm the underlying service is actually healthy (database reachable, feeds syncing) rather than simply slow to start.

Probes exist to detect genuinely unhealthy services. Raise the thresholds enough to accommodate legitimate startup time, but do not disable liveness probes outright, or a truly stuck service will never be restarted automatically.

Services Fail to Start After an Upgrade (Version Mismatch)

Symptom: After a Helm upgrade, one or more services fail to start and their logs report a database schema or version mismatch — the service code is a newer version than the database schema it is connecting to.

Cause: The chart upgrades the Anchore Enterprise database schema with a dedicated upgrade job (upgradeJob), which runs as a Helm hook during helm upgrade. If the upgrade job is disabled or did not complete, the database schema is never brought up to the new version, and the services refuse to start against a mismatched schema.

Fix: Ensure the upgrade job is enabled in your values file (it is enabled by default):

upgradeJob:
  enabled: true

upgradeJob.enabled must be true for the schema migration to run. With it disabled, helm upgrade only updates the deployment specs and images — it does not migrate the database — so the services come up against a mismatched schema and fail.

Within a single helm upgrade, the upgrade job retries the migration several times (approximately four attempts) before it gives up and the release fails. If the job fails, inspect its pod logs — not just the job object — to find the underlying cause, for example the database being unreachable or the credentials lacking the required permissions:

kubectl get jobs -n <namespace>
kubectl logs -n <namespace> job/<upgrade-job-name>          # streams the job's pod logs
kubectl logs -n <namespace> -l job-name=<upgrade-job-name>  # or target the pod(s) directly

After resolving the cause, delete the failed upgrade job (not just its pod) before re-running helm upgrade — a leftover job can block or conflict with the next attempt:

kubectl delete job <upgrade-job-name> -n <namespace>
helm upgrade <release> -n <namespace> anchore/enterprise -f anchore_values.yaml --timeout 30m

If the job failed, its logs will show why — for example, the database was unreachable or the credentials lacked the permissions needed to run the upgrade. Resolve the underlying issue and run the upgrade again.

`helm upgrade` Times Out During a v5 to v6 Migration

Symptom: helm upgrade returns an error such as timed out waiting for the condition a few minutes into a v5.x → v6.x migration, even though the upgrade job is still running.

Cause: helm upgrade waits for its hooks to complete and defaults to a 5-minute timeout. The v5.x → v6.x database schema upgrade and Legacy Imported SBOM migration can take considerably longer than five minutes on larger datasets, so Helm gives up and reports a failure while the underlying job is still working.

Fix: Raise the Helm timeout to a value that comfortably exceeds your expected migration time:

helm upgrade <release> -n <namespace> anchore/enterprise -f anchore_values.yaml --timeout 30m

A Helm timeout does not necessarily stop the upgrade job — the database migration may still complete in the background. Before retrying, check the upgrade job’s status and logs (kubectl get jobs -n <namespace>) and confirm the migration is not still in progress. See Verify the Migration.

9 - Diagnostic Bundle

When you raise a support issue, Anchore Customer Success may need logs, configuration, and other diagnostic information from your deployment to investigate. Anchore Enterprise provides a way to collect this material into a single diagnostic bundle directly from your own systems, so you can gather everything in one step and share it with Customer Success.

Reach out to Anchore Customer Success for the support bundle utility, maydayctl.