Understanding Sandbox Active vs Standby States and Billing

Last updated: March 24, 2026

How Sandbox States Work

Blaxel sandboxes operate in two distinct states that affect your billing:

Active Mode

Sandboxes stay active as long as there's an active connection to them. You are charged for memory usage (based on allocated RAM) and storage while a sandbox is in active mode. CPU resources are allocated by Blaxel based on your selected memory allocation and are not charged separately.

Key points about active connections:

  • An active connection (HTTP, WebSocket, or TCP with data flow) keeps a sandbox active

  • For idle connections (like WebSocket connections with no data flow), there's a 15-minute timeout

  • After 15 minutes of no data transmission, the sandbox will automatically transition to standby. Read more about standby control.

Standby Mode

If a sandbox has no active connections, it automatically transitions to standby mode in approximately 15 seconds.

When transitioning to standby:

  • Blaxel creates a snapshot of the entire state (including file system and running processes)

  • You are not charged for CPU/memory while in standby

  • You are only charged for storage of the snapshot and volumes

  • Reconnecting restores the sandbox in under 25ms with all processes preserved

Common Issues Preventing Standby

Missing Sandbox API

The most common reason sandboxes don't enter standby is a missing or outdated sandbox API. The sandbox API is required for proper shutdown functionality.

To fix this issue:

  1. Ensure you're using the latest sandbox API in your Dockerfile

  2. Add this line to your Dockerfile: COPY --from=ghcr.io/blaxel-ai/sandbox:latest /sandbox-api /usr/local/bin/sandbox-api

  3. Make sure the sandbox API starts first in your entrypoint and wait for it to be ready on port 8080 before starting other processes

  4. Delete and recreate your sandbox after updating the image

Preview URLs and Connections

Deployed preview URLs do not maintain persistent connections to sandboxes and will not prevent standby mode. You do not need to delete and recreate previews to allow standby transitions.  However, each incoming request through a preview URL will wake the sandbox from standby.

Process Keep-alive

The process keep-alive feature that controls the sandbox's auto-hibernation behavior.

When launching a process with keepAlive: true or keep_alive: True, the sandbox will stay awake (auto-hibernation disabled) until the process completes or times out. If a timeout value is not specified, it defaults to 600 seconds. For processes that should run indefinitely until they complete naturally, set the timeout to 0.

Monitoring Sandbox States

While the API status shows "DEPLOYED" for both active and standby sandboxes, you can use these methods to monitor state:

  • Check CPU or Memory metrics charts in the Console - when they show 0%, the sandbox was in standby

  • Monitor your billing in the Billing Explorer to track compute runtime charges (measured in GB-seconds)

  • If you're being charged continuously for compute runtime, your sandbox is likely stuck in active mode

Troubleshooting Continuous Billing

If you notice continuous compute charges (e.g., 24/7 billing for a sandbox that should be idle):

  1. Verify the sandbox API is properly installed and running

  2. Ensure all connections are properly closed when idle

  3. Check that no background processes are keeping connections open

  4. Delete and recreate the sandbox after fixing the sandbox API

Remember: A properly configured sandbox should only incur compute charges when actively processing requests, not when idle.