# Sandbox Billing > How sandbox runtime, retained disks, checkpoints, and templates are billed. Sandbox plans are subscribed to a team. Usage appears in the same current-month billing view as apps and add-ons. ## Team plans | Plan | Base price | Included root disk | Runtime and quota limits | | ---------- | ---------: | -----------------: | -------------------------------------------------------------------------------- | | Basic | Free | 10 GiB | 24 hour max runtime, 20 concurrent sandboxes, template CPU/RAM shape. | | Pro | €150/month | 20 GiB | 24 hour max runtime, 100 concurrent sandboxes, CPU/RAM overrides, 5 creates/sec. | | Enterprise | Custom | Custom | Per-team overrides for disk, runtime, concurrency, CPU, memory, and create rate. | Plan fees and usage are separate. Upgrading a team to Pro raises the team's sandbox limits; it does not replace per-second runtime billing or retained-storage billing. Cancelling a self-service Pro subscription cancels the Stripe subscription immediately and refunds unused plan time. Runtime and storage usage already consumed remain billed through the normal usage ledger. ## What is billed | Line item | What it measures | | ------------------ | ------------------------------------------------------------------------------------------------------------------- | | vCPU runtime | Requested vCPU count multiplied by running seconds. | | Memory runtime | Requested GiB RAM multiplied by running seconds. | | Stopped disk | Confirmed retained root disk storage after a sandbox stops, fails, or is marked lost, until its retention deadline. | | Checkpoint storage | Named checkpoint storage by size and time. | | Template storage | Ready template version storage by size and time. | List sandbox limits to see the active resource shape, prices, and quota snapshot: ```bash curl https://api.watasu.io/v1/sandbox_limits \ -H "Authorization: Bearer $WATASU_API_KEY" ``` The response includes a `quota` object for the selected team: ```json { "sandbox_limits": { "plan": { "slug": "basic", "disk_mb": 10240, "max_timeout_seconds": 86400 } }, "quota": { "limits": { "max_running_instances": 20, "max_vcpu_count": 8, "max_memory_mb": 8192, "max_disk_mb": 10240, "create_rate_per_second": 1 }, "usage": { "running_instances": 2, "vcpu_count": 4, "memory_mb": 4096, "disk_mb": 20480 }, "reservation": { "instances": 0, "vcpu_count": 0, "memory_mb": 0, "disk_mb": 0 } } } ``` ## Runtime billing Runtime billing covers confirmed running time (`ready`). Creating, connecting, restoring, stopping, and destroying do not accrue compute charges. Runtime billing is based on the resources you request: | Resource | Price | | -------- | ------------------------: | | vCPU | €0.000020 per vCPU-second | | Memory | €0.000004 per GiB-second | For example, a sandbox using `2` vCPU and `1024` MiB RAM costs: ```text (2 × €0.000020 + 1 × €0.000004) × running_seconds ``` That is €0.1584 per hour while it is running. ## Resource shape Template versions define a `runtime_baseline`. That baseline is the default runtime shape when you start a sandbox. Basic teams use that shape. Pro and Enterprise teams can override CPU and memory within the team's active plan limits: ```json { "sandbox_template_version": { "runtime_baseline": { "cpu": 2, "memory_mb": 4096 } } } ``` When creating a sandbox, choose the template shape with `template`: ```json { "template": "base", "timeout": 3600 } ``` Root disk size is platform-managed by the team plan: Basic uses a 10 GiB root disk and Pro uses a 20 GiB root disk. It is retained for stopped sandboxes and checkpoints, but it is not a public create-time resource knob. Self-service sandbox resources use these increments: * CPU: `1`, `2`, `4`, `6`, or `8` vCPU * memory: `512` MiB to `8192` MiB in `512` MiB increments Quota checks use the resources you request. If a create or restore request exceeds quota, Watasu returns `422 Unprocessable Entity` with `error: "sandbox_quota_exceeded"` and a `quota` object that includes the limit, current usage, and requested reservation. ## Storage billing Storage is billed by size and time, prorated the same way as runtime: | Storage | Price | | ------------------------------- | ------------------: | | Retained disk (stopped sandbox) | €0.10 per GiB-month | | Checkpoint storage | €0.03 per GiB-month | | Template storage | €0.03 per GiB-month | For example, a stopped sandbox holding a `10` GiB root disk has a €1.00 monthly storage rate, prorated until it resumes, is destroyed, or reaches its retention deadline. A `4` GiB checkpoint has a €0.12 monthly rate until it expires. A paused sandbox also retains a machine-state image alongside its root disk. The retained-disk meter uses the root disk size; the machine-state image is not separately metered. Destruction removes both. ## Retained disk billing When a sandbox is stopped, Watasu keeps the root disk so the sandbox can be inspected, reconnected, restored, or cleaned up deliberately. That retained disk is billed as storage by size and time. Inactive sandbox disks expire after seven days. This includes paused, stopped, failed, and lost sandboxes. The API exposes `retained_storage_expires_at`; resume before that deadline to keep using the sandbox. Resuming ends that retention window, and a later stop starts a new one. The normal runtime timeout can destroy a sandbox sooner when `on_timeout` is `kill`. Existing retained disks receive a fresh seven-day grace period when the policy is first applied. Expired or destroyed sandboxes do not accrue retained-disk charges, and delayed physical cleanup does not extend the billing deadline. Once destruction is requested, a cleanup failure does not restart storage charges. Named persistent volumes and reusable template versions are separate resources and are not subject to this inactive-sandbox expiry. ## Checkpoint billing Ready checkpoints are billed by stored size and time until they expire or are removed by lifecycle cleanup. Checkpoint expiry defaults to 24 hours after creation when `expires_at` is omitted. Cleanup runs automatically and retries failures on the owning node. Use explicit checkpoint expiry times that match the job: ```json { "sandbox_checkpoint": { "name": "after-index", "expires_at": "2026-06-02T12:00:00Z" } } ``` ## Template billing Ready template versions are billed as template storage. This lets you keep reusable environments available for fast sandbox starts. ## Suspended billing When a team's billing account is suspended, Watasu blocks new sandbox runtime spend and returns `402 Payment Required` with `error: "team_billing_suspended"`. The response includes the team and account balance fields needed to guide the user back to billing. Blocked actions include sandbox create, restore, resume/connect, streaming process starts/signals, file writes/moves/deletes, directory create/delete, checkpoint create, and customer template builds. Pause/stop and destroy remain available so you can release resources and clean up retained disks. ## Rate limits Sandbox create and runtime mutation endpoints are rate-limited per authenticated user and remote address. When a request is limited, Watasu returns `429 Too Many Requests`, `error: "rate_limited"`, and a `Retry-After` header. ## Avoiding surprise spend * Set `timeout` on every sandbox. * Destroy sandboxes when a job is complete. * Use checkpoint expiry times instead of keeping temporary checkpoints indefinitely. * Reuse template versions instead of building duplicate templates for the same environment. * Review the team's current-month billing view after adding new automation. [View this page on the web](https://docs.watasu.io/sandboxes/billing/)