Skip to content

Real-time Event Push (SSE)

After you log in to Kuboard, the browser keeps a long-lived connection to the server, which pushes cluster resource changes, K8s events, session states, and more to the UI in real time; the corresponding areas refresh automatically or flash a reminder.

Real-time Behavior on the UI

Pages such as resource detail pages have a connection icon button on the toolbar (next to the refresh button), whose color reflects the connection state:

  • Green = connected, orange = closing, red = disconnected;
  • When a new event arrives, the icon flashes for about 1.5 seconds, indicating "there is a new event";
  • Click the icon to open the event listener panel.
Panel contentDescription
Listening stateConnecting / Connected / Closing / Closed
Event listener toggleWhen turned off, no more pushes are received and the page falls back to manual / scheduled refresh
Total events listenedNumber of all events received by the current connection
Relevant eventsNumber of consumed events related to the topics subscribed by the current page
Latest event listThe most recent 10 relevant events, showing resource type (Kind), name, and the ADDED / MODIFIED / DELETED indicator

Besides the panel, SSE also drives the following "no need to click refresh" experiences:

ScenarioUI behavior
Resource detail pageWhen the displayed resource changes (including operations from other terminals / kubectl), the page automatically reloads its data
"Events" card on the resource detail pageWhen an associated K8s Event is added, the list refreshes automatically and the new event row flashes with a highlight for about 6 seconds
Node terminal NodeShellDebug session state changes automatically from Starting to Running (container ready), or to a failed state on failure
AI change approvalThe change-plan states in the approval list (approved, rejected, application progress, etc.) refresh in real time

Which Real-time Events Can You Subscribe To

Topic format

Every push belongs to a topic, which consists of five segments: scope # cluster # namespace # API group # resource type. List / detail pages subscribe to the corresponding topic automatically according to the resource you are browsing; no manual configuration is needed.

Topic characteristicsTopicTriggerUI impact
Cluster-scoped resources (Node, ClusterRole, etc.)cluster/<cluster>#<kind>Cluster-level resource created / modified / deletedThe corresponding list / detail page refreshes automatically
Namespace-scoped resources (Pod, Deployment, Service, ConfigMap, etc.)namespace/<cluster>/<namespace>#<kind>Resource change within that namespaceThe corresponding page refreshes automatically
K8s Eventnamespace/<cluster>/<namespace>#EventEvent associated with the viewed object addedThe "Events" card on the detail page refreshes automatically with a flashing hint
Node terminal sessioncluster/<cluster>#node-shellDebug session created, ready, failed, cleaned upThe node terminal banner updates its state automatically
AI change approvalkuboard#default#change-planApproval / application progress of a change plan changesThe change approval list refreshes in real time

K8s events bell

The "K8s events" list in the notification bell at the top-right is currently based on scheduled polling (Warning events are pulled approximately every 20 seconds), not SSE real-time push; when you need real-time Warning event alerts, watch the real-time-refreshing "Events" card on the corresponding resource detail page.

Disconnection, Reconnection and the Reverse Proxy

The long-lived connection occasionally drops (network jitter, server restart, browser sleep, etc.), and Kuboard reconnects automatically without any intervention. Two pitfalls to watch out for:

  • The reverse proxy must enable WebSocket: when you access Kuboard through a reverse proxy such as Nginx, the proxy configuration must enable the upgrade (Upgrade / Connection headers) for WebSocket endpoints, otherwise the connection stays stuck on "Connecting"; see Reverse Proxy Configuration;
  • Login token expiry: after the long-lived connection is established, the frontend renews the token periodically, so the connection does not drop due to authentication expiry even if you stay on the page for a long time.

Notes for HA deployments

In a multi-instance deployment, each instance maintains its own browser connections. Deployments that use a Redis cache automatically switch to Redis pub/sub broadcast: when any instance receives a cluster change, it writes it to a Redis channel, and the other instances subscribe to it and push it to their own connected browsers, keeping the data all users see consistent. In a single-node deployment (default in-memory cache), events are dispatched directly within the same process, requiring no extra configuration.

See Installation Configuration and HA Deployment.