Node Pool status

​

Node Pool fields

​

Example output

NAME               INSTANCE TYPE      TARGET   QUEUED   INPROGRESS   CURRENT   PREFILL   VALIDATED   CAPACITY                 QUOTA   AGE
example-nodepool   gd-8xh100ib-i128   2        0        0            2         0         Valid       Sufficient               Under   24h
nodepool-2         cd-hp-a96-genoa    2        1        0            1         0         Valid       QueuedAwaitingCapacity   Under   2d22h
nodepool-3         gd-8xh100ib-i128   3        0        1            2         0         Valid       Sufficient               Under   2d15h

• The VALIDATED, CAPACITY, and QUOTA columns summarize the Node Pool’s conditions.
• In a healthy, fully delivered Node Pool, CURRENT equals TARGET, and both INPROGRESS and QUEUED are 0.
• PREFILL counts the Nodes marked for prefill and being replaced. It is 0 unless prefill is enabled and one or more Nodes are being replaced. To see the prefill state of an individual Node, check its Prefill condition. See Prefill condition reasons.
• While a Node Pool is scaling up, the difference between CURRENT and TARGET is split between INPROGRESS (Nodes that are booting) and QUEUED (Nodes that are waiting for capacity). Note that a new Node can take up to 15 minutes to boot before it counts toward CURRENT.

​

Rack-based Node Pool fields

​

Node Pool full status

kubectl describe nodepool [NODE-POOL-NAME]

​

Common capacity and quota states

​

Run a Node Pool health check

# Counts and condition columns for every Node Pool
kubectl get nodepool

# All conditions for one Node Pool, with reasons and messages
kubectl get nodepool [NODE-POOL-NAME] -o jsonpath='{range .status.conditions[*]}{.type}={.status} ({.reason}): {.message}{"\n"}{end}'

# Recent events for the Node Pool, oldest first
kubectl get events -A --field-selector involvedObject.name=[NODE-POOL-NAME] --sort-by=.lastTimestamp

# Nodes in the Node Pool, with schedulability and age
kubectl get nodes -l compute.coreweave.com/node-pool=[NODE-POOL-NAME]

# Whether each Node in the Node Pool is active (True) or idle (False)
kubectl get nodes -l compute.coreweave.com/node-pool=[NODE-POOL-NAME] -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .status.conditions[?(@.type=="CWActive")]}{.status}{end}{"\n"}{end}'

​

Diagnose a Node Pool that is not at target

​

Nodes are queued

​

Nodes are in progress

​

Nothing is queued or in progress

• Validated: Invalid: CKS rejected the configuration, most often an instance type that isn’t offered in the zone (the events show CWInstanceTypeNotInZone) or a Node affinity matchFields requirement on a key other than metadata.name (the events show CWNodePoolInvalidNodeAffinity). This check reads matchFields only. A broken matchExpressions block, such as an In operator with an empty value list, leaves Validated at Valid and surfaces on the Capacity condition instead. Applying the manifest still succeeds. These checks run after the API server accepts the Node Pool, so kubectl apply, Helm, and Terraform all report success while the Node Pool sits at Invalid. Check the conditions after every change. To confirm an instance type is offered in a zone, see the Availability matrix.
• Quota: Over: The organization-wide total of targetNodes for this instance type, compute class, and zone exceeds your quota and no headroom is left, so CKS queued nothing for the request. A request that exceeds the quota while headroom remains behaves differently: CKS caps it to the headroom, queues that many Nodes, and leaves the Quota condition at Under. Seeing Over means the headroom is gone, not that the request was trimmed. See Resource quotas and the quota events table earlier on this page.
• Quota: NotSet: Your organization has no quota for this instance type, compute class, and zone. CKS queues nothing and emits a CWNoQuota or CWOverQuota event with the message Quota limit is 0. To request a quota, contact support.
• Capacity: Partial or NoneAvailable: The zone is short of the instance type. The CWInsufficientCapacity event message reports what was assigned, for example Assigned (8 out of 10), while CURRENT reports what has joined. CKS keeps what it assigned and retries the rest automatically. See Common capacity and quota states.
• Capacity: PartialNodeAffinity or NoneAvailableNodeAffinity: The Node Pool’s affinity constraints ruled out some or all of the Nodes of that instance type in the zone. An affinity that matches nothing lands here rather than on Validated: Invalid, and so do two broken affinities: one CKS can’t interpret, and one that targets a different InfiniBand fabric than the fabric assigned to the cluster. Both of those also emit CWNodePoolInvalidNodeAffinity, so read the event message before you start hunting for zone capacity. See the Capacity condition.

kubectl get nodes -l compute.coreweave.com/node-pool=[NODE-POOL-NAME] -L backend.coreweave.cloud/fabric,ib.coreweave.cloud/fabric

​

At target but Pods will not schedule

kubectl get nodes -l compute.coreweave.com/node-pool=[NODE-POOL-NAME]

​

Current is above target

• A Pod stuck in CrashLoopBackOff keeps its Node active even though it does no useful work. Delete the Pod, or scale down the Deployment that recreates it.
• Idle GPUs don’t make idle Nodes. With IdleOnly, a Node is eligible for removal only when every counted Pod is gone. Workloads spread thinly across many Nodes can block scale-down even when most GPUs sit unused. Consolidate workloads, or switch the strategy to PreferIdle.

​

When to contact support

• A CWNodePoolDisabled event. Despite the event message about configuration issues, repeated delivery failures usually cause this state. The disabled object is the Node Pool’s Node Profile, which support re-enables or replaces.
• QUEUED that doesn’t move and no Nodes reaching INPROGRESS, while Quota is Under.
• Any condition stuck at InternalError that doesn’t clear on its own.
• AtTarget: UnderTarget while Capacity is Sufficient and nothing is queued or in progress.
• Idle Nodes (CWActive: False) that CKS still hasn’t removed about 10 minutes into a scale-down.