Troubleshooting

3AM stays in setup mode until a valid licence is installed. Open the console and upload it, or check GET /v1/status for the reason (expired, wrong fingerprint, tampered). See Licensing troubleshooting.

It is kept in /var/lib/3am/admin-token inside the container:

podman cp 3am-core:/var/lib/3am/admin-token ./admin-token && cat ./admin-token && rm ./admin-token   # or docker cp

On Kubernetes it is in the threeam-admin Secret:

kubectl -n bank-ops get secret threeam-admin -o jsonpath='{.data.token}' | base64 -d

To set your own, start 3AM with THREEAM_ADMIN_TOKEN.

Run 3am-core preflight --deep. unreachable means a firewall or address issue (test from the 3AM host); auth means the credential is wrong or expired; forbidden means the account lacks a permission listed on the connector's page.

Check that the alert source is configured and healthy, that the service isn't set to off, and search the audit log for signal. events. 3AM groups repeats of one alert into one incident.

Some causes need judgement (for example, a memory limit that is too low). 3AM then sends advice with the evidence instead of a change. In shadow mode it records the proposal but asks no one: see Safety rails.

The check had no data or no way to run here: a metric your exporter doesn't publish, or a connector that isn't configured. The verdict's detail says which. 3AM never treats missing data as proof.

The model is not configured or did not answer in time (60 s by default). See Models. Nothing else is affected.

Treat it as a security incident: keep the data volume as it is, restore the last good backup to a separate host for comparison, and contact [email protected].