> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloud.vessl.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Resource limits

> Which resource limits VESSL Cloud enforces, what happens when a workload exceeds one, and which data survives.

VESSL Cloud enforces resource limits on workspaces and batch jobs based on the resource spec you select at launch. This page describes which limits apply and how the platform behaves when a workload exceeds one.

## Which limits apply

| Resource          | Where the limit comes from           |
| ----------------- | ------------------------------------ |
| CPU               | Resource spec (for example, 8 vCPUs) |
| Memory (RAM)      | Resource spec (for example, 64 GiB)  |
| GPU memory (VRAM) | GPU model (for example, H100 80 GB)  |
| Temporary storage | Allocated per container at launch    |

<Info>
  You select a resource spec when you create a Workspace or Job. To review available specs, see [Create a workspace](/member/workspace/create) or [Create a job](/member/job/create).
</Info>

## What happens when a limit is exceeded

| Limit exceeded    | Result                                                                                                    |
| ----------------- | --------------------------------------------------------------------------------------------------------- |
| Memory            | The container is killed (Out of Memory Killed, `OOMKilled`)                                               |
| Temporary storage | The container is removed from the node                                                                    |
| CPU               | The workload slows down but keeps running                                                                 |
| GPU memory (VRAM) | The process receives a CUDA out-of-memory (OOM) error; what happens next depends on your application code |

## How workloads recover

When a container is killed by the Memory or Temporary storage limit, recovery depends on the workload type.

| Workload  | Recovery behavior                                                                                                                                              |
| --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Workspace | The platform restarts the container on a healthy node and re-attaches Cluster storage and Object storage volumes. Temporary data and in-memory state are lost. |
| Job       | The job is marked as `failed`. There is no automatic retry — submit a new batch job to try again.                                                              |

## Which data survives

| Data location           | After the limit is exceeded |
| ----------------------- | --------------------------- |
| Container memory state  | Lost                        |
| Temporary storage       | Lost                        |
| Cluster storage volumes | Preserved                   |
| Object storage volumes  | Preserved                   |

<Note>
  Data on Cluster storage and Object storage volumes is unaffected when a workload exceeds a resource limit. Store anything you can't afford to lose on one of these volumes.
</Note>

## Check resource usage

Track usage in real time and review historical patterns:

* [Monitor workspace metrics](/member/workspace/metrics) — GPU, VRAM, CPU, memory, and network usage
* [Monitor job metrics](/member/job/metrics) — the same metrics for batch jobs
* [Workspace logs](/member/workspace/logs) — review `OOMKilled` and eviction events
* [Job logs](/member/job/logs) — review failure causes

## Related

* [Credit exhaustion policy](/admin/billing/credit-exhaustion-policy) — what happens when your credit balance reaches zero
* [Container Compute service terms](/legal/container-compute) — contractual terms for resource limits