Skip to main content

Resources and usage

Below an environment's resource sliders, two readings tell you what the environment itself is doing — separate from what the node underneath it looks like.

  • See the environment's own usage, not just the node's. Directly under the resource sliders, This environment's usage reads the environment's own opinion of itself: CPU utilisation against its quota, memory current and peak against its own cgroup limit with the real OOM-kill count, and disk usage on the workspace mount — refreshed on demand, and it works even on clusters where kubectl top can't (no metrics-server required). A field the reading could not measure (an unlimited memory setting, an older cgroup version) says so rather than showing a confident zero. Named warnings call out when memory or disk is close to its limit. See Runtime pods.
  • On a build-capable environment, the reading covers two containers — because the work is in the second one. The CPU and memory rows are the runtime container's, and on an environment that builds they are near-idle by construction: a build lane spends its time waiting on bounded job calls, so those figures cannot tell a healthy build from a wedged one. Every image build runs in the erun-dind sidecar instead, and the panel reports it as its own Builds block, named so the two cannot be confused. That sidecar usually declares no CPU quota — it is deliberately unlimited so a build can use the node — so it has no utilisation percentage to report; the panel states its cumulative CPU-seconds instead, which is a real measurement with no ceiling to be a fraction of. A sidecar reading that could not be taken renders as absent, never as an idle zero, and the caption keeps saying which rows exclude builds either way.
  • See whether Stop will do anything before you press it. The tab reads the environment's runtime Deployment and says what it found: running (with how many replicas are ready), stopped, or not yet deployed. Stop is offered only when the runtime actually wants pods. On one that is already stopped — or one that was never deployed — the control is disabled with the reason on screen, because a stop there is a correct no-op that would otherwise read as a broken button. When the cluster cannot be read at all, the tab says so and leaves Stop usable rather than blocking the only control you have. The helper text under the button also names the platform components a stop will not touch, so a pod that outlives the stop is not mistaken for a failed one — see erun stop · What a stop does not touch.

See what an environment is running, and take resources back​

Below that, Running in this environment reports what the pod is doing right now: how many sessions actually have a live program behind them, and the processes holding memory — Gradle daemons a finished build left resident, the container build cache — grouped by what they are. It is a reading, not a cleanup: nothing is stopped until you click the action beside a group, and your worktree, sessions, and Agent are never touched. The resource figures in the sliders above are a live snapshot of the node, and when the maximum is capped by the node being full rather than by a limit on the environment, the tab says so and points at stopping an environment nobody is using. See Runtime pods.

Where next​

  • Control panel — the sidebar's compact usage reading, for comparing environments at a glance.
  • erun usage — the same reading from the CLI.