WebSocket Events
Real-time change notifications via /api/v1/ws — what each message carries, and what it deliberately doesn't.
GET /api/v1/ws upgrades to a WebSocket that tells the UI something changed
so it can refetch. When authentication is enabled, pass the access token as a
query parameter: /api/v1/ws?token=<access-token>.
Message shape
Every message is a JSON envelope:
{ "type": "resource:updated", "data": { … } }
For resource events, data is a notification, not the object:
{
"type": "resource:updated",
"data": {
"kind": "Deployment",
"metadata": { "namespace": "shop", "name": "checkout", "uid": "…" }
}
}
To see what changed, fetch it through the REST API (for example
GET /api/v1/resources/deployments/shop/checkout), which applies the same
redaction and role checks as the rest of the product.
The socket never carries object bodies. It used to send the full informer
object, which meant every Secret change reached every connected browser;
since 2.0.3 it sends only {kind, namespace, name, uid}.
There is no per-kind subscription: a client receives every notification for the clusters it is viewing and decides what to refetch. Frames the client sends are read and ignored.
Event types
| Type | data | When |
|---|---|---|
resource:updated | {kind, metadata: {namespace, name, uid}} | A watched object was added or changed — Kubernetes Events included |
resource:deleted | {kind, metadata: {namespace, name, uid}} | A watched object was removed |
insight:new | The insight | A new insight fired |
insight:resolved | The insight | An insight resolved |
cluster:connected | {context, clusterId} | A previously-failed agent-proxy connector recovered — the UI refreshes cluster state immediately |
cluster.switched | {context} | The active cluster changed |
clusters.changed | null | The cluster registry changed (added, removed, renamed) |
Only the cluster you are viewing emits resource and insight events. Clusters parked in the background keep their informers and insights engine running, but stay quiet on the socket.
Broadcast buffer: 4096 messages. Messages are dropped silently when no clients are connected, and a client that can’t keep up is disconnected; the UI reconnects with backoff and its 30-second refetch covers anything missed.