Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt

Use this file to discover all available pages before exploring further.

Spot Node Pools provide pay-as-you-go access to high-performance, bare-metal compute resources without long-term commitments or reservations. Instances in a Spot Node Pool are identical to instances in standard Node Pools and provide the same hardware and performance. The key difference is that instances in Spot Node Pools operate on a preemptible basis, meaning they can be reclaimed by CoreWeave 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, instances in Spot Node Pools can be reclaimed by CoreWeave 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).

​
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.

​
Using 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 ...

​
Using the Cloud Console

To create a Spot Node Pool using the Cloud Console, set the Compute Class to spot in the configuration settings.
  1. Navigate to the Node Pools dashboard.
  2. Click Create Node Pool.
  3. 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, individual instances are removed from the pool through a controlled preemption process. When an instance is selected for preemption, the process provides a seven-minute window (maximum) to gracefully stop running jobs and save state before the instance is removed from the pool.

​
Detailed timeline

​
1. Warning and cordon (T=0:00)

When an instance is designated for preemption, it is immediately cordoned to prevent new jobs from being scheduled. Running jobs are not interrupted at this stage and continue executing normally. 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 gives your application an initial signal that preemption is imminent.

​
2. 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 is initiated.
  1. Any Pod PreStop lifecycle hooks are triggered.
  2. A Linux SIGTERM signal is sent to all running processes, warning them that the Pod is being terminated. This gives them an opportunity to perform graceful shutdown procedures that were not triggered by the PreStop lifecycle hooks.
  3. The system waits for 30 seconds, or the length of time specified in the Pod’s terminationGracePeriodSeconds.
  4. After the grace period, a SIGKILL signal is sent to any remaining running processes in the Pod. This signal cannot be caught or ignored, and the receiving process cannot perform any clean-up. The process is immediately terminated.

​
3. Removal from pool (T=0:07)

When the node is fully drained or when the seven-minute window expires (whichever comes first), the instance is removed from your cluster and Spot Node Pool. A final Kubernetes warning event is sent 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 will automatically attempt to provision new instances when capacity becomes available again in the region. Your workloads remain in a pending state until instances rejoin the pool.

​
Handling preemption events

It is your responsibility to ensure that your application can handle preemption events gracefully and tolerate preemption without causing data loss or downtime. If your application does not 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 is terminated.

​
Monitoring 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 any of your Nodes were preempted, use Grafana Explore with the preconfigured preemption query. The query returns Nodes that were 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.
Last modified on May 4, 2026