Verify the install

From inside your cluster

kubectl -n seylo-agent get pods
kubectl -n seylo-agent logs deploy/seylo-agent --tail=50

A healthy agent prints two confirming lines on startup:

INFO  [agent] egress: No proxy is configured (AGENT_PROXY_URL / HTTPS_PROXY /
      HTTP_PROXY are all unset); connecting directly.
INFO  [agent] preflight (startup): config, DNS, TCP and TLS all passed -
      any remaining failure is above the transport ...

followed by ENROLLED on a first install (or AUTHENTICATED afterwards) and then reporting inventory every 30s.

The agent diagnoses itself and prints one actionable line per failure.

kubectl -n seylo-agent logs deploy/seylo-agent | grep preflight

If that prints the “all passed” line, stop looking at the network — whatever is wrong is above the transport.

From the portal

Clusters → the cluster shows a green Agent: Connected chip with the agent’s version and last-seen time. Dashboard rows for that cluster carry a small agent badge, so an operator can see which data path a number came from.

The install page’s step 3 polls until the agent attaches and then shows:

Field	What it means
Agent version	The image actually running — not the one you meant to install
Protocol version	The negotiated wire version
Last seen	Heartbeat freshness
Inventory namespaces / deployments	What the agent can actually see with the RBAC you granted

That last row is the useful one. If you installed namespace-scoped and the count is lower than expected, the RoleBindings do not exist in every namespace you listed.

Via the API

curl -s https://portal.seylo.in/api/admin/clusters/<cluster-id>/agent

{
  "state": "connected",
  "connected": true,
  "agentVersion": "0.1.0",
  "protocolVersion": 1,
  "lastSeenAt": "...",
  "inventoryNamespaces": 2
}

Check what the agent may actually do

Seylo reads the agent’s real Kubernetes grant back and shows it in the portal. This is worth looking at once immediately after installing, because it is the difference between what you think you granted and what Kubernetes actually bound.

You can confirm the same thing yourself:

# Cluster-wide install: one object to read.
kubectl get clusterrole seylo-agent -o yaml

# Namespace-scoped install: the complete reachable set.
kubectl get rolebinding -A | grep seylo-agent

If those two disagree with what the portal shows, the portal is reading a stale connection — restart the agent Deployment and re-check.

Clean up

Once the agent is connected, the one-time enrollment Secret is no longer needed:

kubectl -n seylo-agent delete secret seylo-agent-enrollment

If you saved a rendered agent.yaml to disk, delete that too — it contains the enrollment token.

If it is not connected

Go to troubleshooting the agent. Start with the grep preflight command; the code in brackets is the index into the fix table.