Kubernetes dashboard

Open a cluster from Kubernetes to see what runs inside it, with no kubeconfig and no tools to install. The dashboard reads the cluster live, as you: it uses the same access your kubeconfig would get from your role on the cluster, so it shows what you could see with kubectl get, and nothing more.

The dashboard only reads, with one exception: growing a volume from Storage raises its claim's storage request, as you. To change anything else inside the cluster, use kubectl, Helm or your own pipeline.

The cluster's sections

Lists refresh on their own every few seconds while the page is open. Choose a namespace to narrow a list; the choice stays in the page's address, so you can bookmark it or share it with your team.

The namespaces the cluster itself runs in — kube-system, kube-public, kube-node-lease and the managed gateway's — are left out of the namespace list and of All namespaces, so the lists show your own workloads. Turn on Show system namespaces to include them.

Who can see what

Your role is checked on every read, so a change applies at the next refresh. When your role cannot read something inside the cluster — nodes, for an editor or a viewer — its card says so instead of showing it; an editor choosing All namespaces is asked to pick one.

Only people signed in to the console can read inside a cluster. API tokens and AI agents connected over MCP cannot, even with Kubernetes access.

Workloads and their pods

Each workload shows its kind, its state, how many of its pods are ready, its images and its age:

Select a workload's name to list its pods. A cron job's pods belong to the jobs it starts, so select one of those jobs instead.

Each pod shows its status the way kubectl get pods does, such as Running, ContainerCreating or CrashLoopBackOff, with its ready containers, restarts, node, live CPU and memory use, and age.

Container logs

Select Logs on a pod to read the latest output of one of its containers:

• Container picks which one, init containers included.
• Lines reads the last 100, 200, 500 or 1,000 lines.
• Previous run shows what the container printed before it last restarted, which is where to look when it keeps crashing.
• Timestamps adds the time each line was written.

Logs do not stream: select Refresh to read again. At most 512 KB is shown, keeping the newest lines, and each person can read logs up to 30 times a minute.

Services and routes

• Services: type, cluster IP, external address — your workspace's public address, for a LoadBalancer Service — and ports, shown as port→target/protocol with the node port in brackets.
• Gateways: class, listeners with the number of routes attached to each, addresses, and whether the gateway is programmed.
• HTTP routes: hostnames, the gateways a route attaches to and whether each accepted it, and the Services it sends traffic to.
• Ingresses: each host and path with the Service it reaches, the hosts with TLS, and addresses.

Nodes

The Nodes section first shows the cluster's node pools, where you add, change and delete them. Below that, each worker as the cluster sees it: Ready or Not ready, Cordoned when it takes no new pods, any memory, disk or process pressure, its roles, internal address and Kubernetes version, and its live CPU and memory use against what pods may use on it. These are the figures kubectl top nodes shows.

The control plane is fully managed: we run and monitor it, and it runs none of your pods, so it appears in no list or chart here. A highly available cluster shows Control plane: Managed, highly available.

Monitoring

Worker usage charts the CPU and memory of every worker over the last hour, 24 hours, 7 days or 30 days. CPU is a percentage of the worker's vCPUs. The platform measures them from outside the worker every minute, so they cover everything the worker uses, not only your pods, and they keep coming when the cluster itself is struggling.

Events lists what the cluster reported recently, newest first: images pulled, pods that could not be scheduled, containers restarting. Warnings only hides the rest. The cluster keeps events for about an hour. Up to 1,000 are read and the newest 250 shown; in a busy cluster, choose a namespace to see all of its recent events.

Storage

The cluster's volumes, as in your workspace's Volumes page, each with its PersistentVolume name and how much it uses on disk, and a menu to grow it. Below them are its persistent volume claims with their phase, storage class, the volume each is bound to, size and access modes. Kubernetes volumes explains the storage classes, growing a volume and how to keep data.

Limits

The sections that read inside the cluster wait until it is ready, and show a notice while it is being created or deleted.