Verify your install

Confirm the control plane is healthy, the modules you expect are enabled, and a request can actually get through.

Check the pods#

kubectl get pods -n agentfleet-system

Every pod should reach Running and report 1/1 ready. On a first install a restart count of one or two is normal: services start before PostgreSQL is accepting connections and retry until it is.

Check readiness, not just liveness#

Each service exposes /healthz for "the process is up" and /readyz for "the dependencies this service needs are reachable". Readiness is the one worth reading, because it names the dependency that is failing.

kubectl port-forward -n agentfleet-system svc/agentfleet-gateway 8080:8080 &
curl -s http://127.0.0.1:8080/readyz

{
  "status": "ready",
  "checks": [
    { "name": "registry",  "status": "ready",    "required": true },
    { "name": "scheduler", "status": "disabled", "required": false },
    { "name": "policy",    "status": "ready",    "required": true },
    { "name": "approval",  "status": "ready",    "required": true },
    { "name": "context",   "status": "disabled", "required": false }
  ]
}

Confirm migrations applied#

When a module uses PostgreSQL, its schema version is recorded in a ledger table. This is the fastest way to tell whether the migration Job actually ran:

SELECT component, version, name
FROM agentfleet_schema_migrations
ORDER BY component, version;

Send a request#

A healthy control plane that denies everything is still not working. Send one real request and read the decision:

curl -s http://127.0.0.1:8080/v1/run \
  -H 'Content-Type: application/json' \
  -d '{"tenant":"retail","capability":"refund-processing",
       "input":{"message":"test"}}'

A 403 with policy_denied means the control plane is working and no allow rule matches yet. Continue to Write a policy that allows traffic.

If something is wrong#

See Troubleshooting for the symptoms you are most likely to hit and what each one means.