Spot Node Pools - CoreWeave Docs

Spot Node Pools provide pay-as-you-go access to high-performance bare-metal compute resources without long-term commitments or reservations. They are suited for fault-tolerant, interruptible workloads where flexibility on capacity matters more than guaranteed availability. Instances in a Spot Node Pool are identical to instances in standard Node Pools. The key difference is that instances in Spot Node Pools operate on a preemptible basis, meaning CoreWeave can reclaim them when capacity is needed elsewhere. You can manage Spot Node Pools using the same tools and methods as standard Node Pools. The instances themselves have no special configuration. An instance becomes a Spot instance by being part of a Node Pool created with computeClass: Spot.

Key characteristics

Availability: Capacity for Spot Node Pools is not guaranteed and depends on current availability in the region.
Preemptible: Unlike instances in on-demand Node Pools, CoreWeave can reclaim instances in Spot Node Pools at any time if the capacity is required elsewhere.
Automatic scaling: When all instances are preempted, the Spot Node Pool remains active and automatically scales back up when capacity becomes available again.

Availability

Spot Node Pools are supported in all General Access Availability Zones, and for all instance types except Superchip-powered instances (for example, GH200, GB200, GB300).

Check Spot capacity before you provision

Spot capacity is not guaranteed and varies by Availability Zone. Before you create a Spot Node Pool, use Capacity Finder in the Cloud Console to compare placement availability across Zones for your requested instance type and Node count. Capacity Finder can also pre-fill a Spot Node Pool from a recommended Zone.

Create a Spot Node Pool

Create a Spot Node Pool by setting the computeClass field to spot in your Node Pool configuration in either a Kubernetes manifest or the Cloud Console. See Create a Node Pool for more information.

Use Kubernetes

To create a Spot Node Pool using Kubernetes, set the spec.computeClass field to spot in your Node Pool manifest.

apiVersion: v1
kind: NodePool
metadata:
  name: my-spot-pool
spec:
  region: EU-SOUTH-04A
  computeClass: spot
  # ... other configuration ...

Use the Cloud Console

To create a Spot Node Pool using the Cloud Console, set the Compute Class to spot in the configuration settings.

Navigate to the Node Pools dashboard.
Click Create Node Pool.
In the configuration settings, enter spot as the Compute Class string (spec.computeClass).

Instance preemption

Because instances in Spot Node Pools are preemptible, CoreWeave may reclaim them when capacity is needed elsewhere. When this happens, a controlled preemption process removes instances from the pool. When CoreWeave selects an instance for preemption, the process provides a seven-minute window (maximum) to gracefully stop running jobs and save state before the instance leaves the pool. The following timeline describes each phase of that window and the signals your workloads receive at each stage.

Detailed timeline

Warning and cordon (T=0:00)

When CoreWeave designates an instance for preemption, it immediately cordons the Node to prevent scheduling new jobs. Running jobs continue executing normally at this stage. The system sends a Kubernetes warning event with the reason Preemption pending and applies the label qos.coreweave.cloud/pending-preemption: true to the Node. This is your application’s initial signal that preemption is imminent.

Drain and signal (T=0:02)

Two minutes after the initial warning, CoreWeave automatically initiates a Node drain to terminate workloads. The system sends another Kubernetes warning event with the reason Preemption in progress and applies the label qos.coreweave.cloud/evicted-at: [timestamp] to track when the drain started. At this point the normal Kubernetes Pod termination process starts.

Kubernetes triggers any Pod PreStop lifecycle hooks.
Kubernetes sends a Linux SIGTERM signal to all running processes to indicate that the Pod is terminating. This gives processes an opportunity to perform graceful shutdown procedures that the PreStop lifecycle hooks didn’t trigger.
The system waits for 30 seconds, or the length of time specified in the Pod’s terminationGracePeriodSeconds.
After the grace period, Kubernetes sends a SIGKILL signal to any remaining running processes in the Pod. Processes can’t catch or ignore this signal, and the receiving process can’t perform any cleanup. The process terminates immediately.

Removal from pool (T=0:07)

When the Node fully drains or when the seven-minute window expires (whichever comes first), CoreWeave removes the instance from your cluster and Spot Node Pool. The system sends a final Kubernetes warning event with the reason Deleted for preemption to confirm the removal is complete.

Sequence diagram

Fully preempted Spot Node Pools

If all instances in a Spot Node Pool are preempted, the pool itself remains active but effectively scales to zero instances. The Spot Node Pool continues to exist in your cluster configuration and automatically attempts to provision new instances when capacity becomes available again in the region. Your workloads remain in a pending state until instances rejoin the pool.

Handle preemption events

Your application must handle preemption events gracefully and tolerate preemption without causing data loss or downtime. If your application doesn’t natively handle SIGTERM signals for graceful shutdown, use a Kubernetes PreStop hook in your Pod definition to trigger the necessary cleanup steps before the container terminates. CKS-initiated scale-down doesn’t wait for DaemonSets unless they carry qos.coreweave.com/graceful-interruptible: "true" and don’t tolerate eviction taints. If a DaemonSet on a Spot Node must finish work before the Node leaves, label it accordingly.

Mix Spot and on-demand capacity

A common pattern runs the resilient majority of a workload on Spot and keeps a smaller on-demand Node Pool for the parts that can’t be interrupted. Schedule interruptible replicas onto the Spot pool, and pin critical singletons to an on-demand pool with a nodeSelector. To target Pods to a specific pool, see Workload scheduling on CKS.

Monitor preemption events

You can watch for preemption warnings using kubectl events:

kubectl events --types=Warning --watch | grep "Reason: Preemption pending"

Search for preempted Nodes in Grafana

To check whether CoreWeave preempted any of your Nodes, use Grafana Explore with the preconfigured preemption query. The query returns Nodes that CoreWeave removed due to preemption. Preemption logs are retained for 1 week. Open preemption query in Grafana Explore For more information about Pod termination, see Termination of Pods in the Kubernetes documentation.

Monitor Spot usage

To track Spot instance usage and estimate costs, use Grafana with the billing:instance:total metric and filter by compute_class="spot". This example groups Spot usage by instance type:

sum by (label_node_kubernetes_io_instance_type) (
  billing:instance:total{compute_class="spot"}
)

For the full list of labels on this metric, more query examples, and cost-estimation techniques, see Cost and usage monitoring. For a Cloud Console view of Spot usage alongside your other capacity plans, see Billing insights.

​Key characteristics

​Availability

​Check Spot capacity before you provision

​Create a Spot Node Pool

​Use Kubernetes

​Use the Cloud Console

​Instance preemption

​Detailed timeline

​Warning and cordon (T=0:00)

​Drain and signal (T=0:02)

​Removal from pool (T=0:07)

​Sequence diagram

​Fully preempted Spot Node Pools

​Handle preemption events

​Mix Spot and on-demand capacity

​Monitor preemption events

​Search for preempted Nodes in Grafana

​Monitor Spot usage