# How Fast Does a Cloud Sandbox Start, Resume and Fork? Measured

> Measured from our machine on 2026-10-27 in eu-central, 10 runs per size: a new sandbox reported ready in a median 3.2 seconds, a resume with memory in 1.35 seconds, and a fork in 3.35 seconds. The first command then took about 0.2 seconds. Every figure includes CLI and network time.

Source: https://sandboxer.com/guides/how-fast-does-a-cloud-sandbox-start-resume-and-fork. Updated 2026-10-27.

**Short answer:** Measured from our machine on 2026-10-27 in eu-central, 10 runs per size: a new sandbox reported ready in a median 3.2 seconds, a resume with memory in 1.35 seconds, and a fork in 3.35 seconds. The first command then took about 0.2 seconds. Every figure includes CLI and network time.

## Conditions

| | |
| - | - |
| Date and time | 2026-10-27, 03:00:35 to 03:07:19 UTC |
| Region | `eu-central` |
| Sizes | `small` (2 vCPU, 4 GB) and `default` (4 vCPU, 8 GB), 10 runs each |
| Client | Measured from our machine, with `ping sandboxer.com` averaging 27.2 ms round trip |
| What a number means | Wall-clock time around one `sbx` command, so it includes the CLI and every network round trip |
| Runs | One sandbox at a time, each deleted at the end of its run |

These are measurements of Sandboxer only. We didn't time any other service.

## Results

All times in milliseconds.

| Step | Size | Min | Median | p90 | Max |
| - | - | - | - | - | - |
| `sbx new` to ready | `small` | 3189 | 3191 | 3193 | 3193 |
| `sbx new` to ready | `default` | 3189 | 3200 | 3244 | 7813 |
| First command (`sbx exec <id> true`) | `small` | 205 | 210 | 212 | 218 |
| First command | `default` | 205 | 209 | 213 | 217 |
| `sbx resume` to ready (memory restored) | `small` | 1343 | 1348 | 1354 | 1356 |
| `sbx resume` to ready (memory restored) | `default` | 1343 | 1350 | 1366 | 1444 |
| First command after resume | `small` | 205 | 207 | 214 | 222 |
| First command after resume | `default` | 204 | 208 | 210 | 215 |
| `sbx fork --wait` to ready | `small` | 3352 | 3354 | 3360 | 3361 |
| `sbx fork --wait` to ready | `default` | 3350 | 3358 | 3362 | 3367 |
| First command in the fork | `small` | 200 | 202 | 207 | 240 |
| First command in the fork | `default` | 198 | 203 | 204 | 211 |

p90 is the 9th of 10 sorted runs. All 20 resumes reported `"memoryRestored": true` with `resumeReason` null, and in all 20 a `sleep` process started before the stop had the same PID after the resume. Size made no visible difference: the `small` and `default` medians are within 10 ms of each other for every step.

One run stands out: `default` run 10 took 7813 ms to be ready. The other 19 creates took 3.19 to 3.24 seconds.

We also timed a resume that has to boot from disk, by resuming a stopped `small` sandbox as `default` (a size change always cold-boots), 5 runs at 03:06 to 03:07 UTC. With 5 runs, p90 here is the slowest run:

| Step | Min | Median | p90 | Max |
| - | - | - | - | - |
| `sbx resume --type default` to ready (cold boot) | 3379 | 3382 | 3389 | 3389 |

Each of those reported `"memoryRestored": false` and `"resumeReason": "resized"`, and the `sleep` process was gone, as expected after a boot from disk.

## Why the numbers cluster

`sbx new`, `sbx resume` and `sbx fork --wait` check the sandbox's state at once, after 1 second, then every 2 seconds. `sbx resume` and `sbx fork --wait` also run `true` in the sandbox before they print `ready`. So the times land in steps: a sandbox seen at the 3-second check shows about 3.2 seconds, whether it came up at 1.5 or 2.9 seconds. The sandbox was up somewhere inside the last step.

Read the table that way:

- **Create:** up by the 3-second check in 19 of 20 runs. The 7.8-second run was seen two checks later.
- **Resume with memory:** up by the 1-second check in all 20 runs.
- **Fork and cold resume:** up by the 3-second check in every run.

## What makes a resume fast or slow

A stop writes the VM's memory and device state to disk. A resume loads that image back, so the VM skips booting and its processes carry on. That is the 1.35-second case.

A resume boots from disk instead, keeping files but not processes, when:

- you change size (`sbx resume <id> --type large`). Our cold-boot runs above are this case;
- the memory image is missing, for example for a sandbox created with `--no-snapshots`;
- no machine with the same CPU type as the one it stopped on is free. The resume waits up to 2 minutes for one, then boots from disk and reports `"memoryRestored": false` with `"resumeReason": "cpu_mismatch"`. That wait is part of the resume time. Pass `sbx resume --require-memory` to keep waiting (up to 30 minutes) rather than boot from disk.

None of our 20 memory resumes fell back. Check after any resume with:

```bash
sbx info $id --json | jq '.sandbox | {memoryRestored, resumeReason}'
```

```json
{
  "memoryRestored": true,
  "resumeReason": null
}
```

A fork always boots fresh from a copy of the disk, so it never restores memory and its `memoryRestored` is null. In our runs the source was stopped when we forked it, so only one sandbox ran at a time.

## The script

This is the script we ran, unchanged. It needs a signed-in `sbx` and `jq`, and deletes everything it creates.

```bash
#!/usr/bin/env bash
# Sandboxer start / first command / resume / fork timings. Wall-clock from the machine running this script, so every
# number includes the CLI and the network round trips to sandboxer.com. Needs a signed-in sbx (or SANDBOXER_API_KEY)
# and jq. Runs one sandbox at a time and deletes everything it creates.
#   N=10 TYPE=small ./bench.sh > small.tsv
N=${N:-10}; TYPE=${TYPE:-default}; PREFIX=${PREFIX:-aeo-bench}; SBX=${SBX:-sbx}; SLOT=${SLOT:-}
ms_now() { echo $(( $(date +%s%N) / 1000000 )); }
state() { $SBX info "$1" --json 2>/dev/null | jq -r '.sandbox.state // empty'; }
wait_archived() { for _ in $(seq 1 240); do [ "$(state "$1")" = archived ] && return 0; sleep 0.5; done; return 1; }

echo -e "type\trun\tstarted_utc\tcreate_ready_ms\tfirst_exec_ms\tresume_ready_ms\tresume_exec_ms\tmemoryRestored\tresumeReason\tsame_pid\tfork_ready_ms\tfork_exec_ms"
for i in $(seq 1 "$N"); do
  slot=""; [ -n "$SLOT" ] && slot=$($SLOT acquire "$PREFIX-$TYPE-$i")
  started=$(date -u +%H:%M:%S)

  # 1. create to ready
  t0=$(ms_now)
  id=$($SBX new --type "$TYPE" --name "$PREFIX-$TYPE-$i" --no-env --ttl 900 --json | jq -r 'select(.event=="ready") | .id' | tail -1)
  t1=$(ms_now)
  if [ -z "$id" ]; then echo "run $i: create failed, stopping" >&2; [ -n "$slot" ] && $SLOT release "$slot" >&2; exit 1; fi

  # 2. first command
  $SBX exec "$id" true >/dev/null; t2=$(ms_now)

  # 3. stop (memory snapshot), then resume to ready
  $SBX exec "$id" --detach "sleep 100000" >/dev/null
  pid_before=$($SBX exec "$id" "pgrep -f 'sleep 100000'" | head -1)
  $SBX stop "$id" >/dev/null; wait_archived "$id"
  t3=$(ms_now)
  $SBX resume "$id" >/dev/null
  t4=$(ms_now)
  pid_after=$($SBX exec "$id" "pgrep -f 'sleep 100000'" | head -1)
  t5=$(ms_now)
  mr=$($SBX info "$id" --json | jq -r '.sandbox | "\(.memoryRestored)\t\(.resumeReason)"')
  same=$([ -n "$pid_before" ] && [ "$pid_before" = "$pid_after" ] && echo yes || echo no)

  # 4. fork to ready (source stopped again, so only one sandbox runs at a time)
  $SBX stop "$id" >/dev/null; wait_archived "$id"
  t6=$(ms_now)
  fid=$($SBX fork "$id" --wait --no-env --ttl 900 --json | jq -r 'select(.event=="ready") | .id' | tail -1)
  t7=$(ms_now)
  if [ -n "$fid" ]; then $SBX exec "$fid" true >/dev/null; else echo "run $i: fork failed" >&2; fi; t8=$(ms_now)

  echo -e "$TYPE\t$i\t$started\t$((t1-t0))\t$((t2-t1))\t$((t4-t3))\t$((t5-t4))\t$mr\t$same\t$((t7-t6))\t$((t8-t7))"
  echo "run $i: $id fork $fid" >&2
  [ -n "$fid" ] && $SBX delete "$fid" --yes >/dev/null
  $SBX delete "$id" --yes >/dev/null
  [ -n "$slot" ] && $SLOT release "$slot" >&2
done
```

`SLOT` is optional. We set it to a small helper that limits how many sandboxes our team runs at once; leave it empty and the script runs one sandbox at a time anyway. The resume time starts after the sandbox reports `archived`, so it doesn't include writing the stop snapshot.

The first rows of the `small` output:

```text
type	run	started_utc	create_ready_ms	first_exec_ms	resume_ready_ms	resume_exec_ms	memoryRestored	resumeReason	same_pid	fork_ready_ms	fork_exec_ms
small	1	03:00:35	3189	212	1348	207	true	null	yes	3352	202
small	2	03:00:50	3191	211	1344	207	true	null	yes	3352	201
small	3	03:01:05	3189	207	1356	222	true	null	yes	3353	202
…
```

## Earlier results

We published an earlier run of the create and resume steps, measured on 2026-10-24 with `default`, 10 runs: [conditions and results](/guides/bench/README.txt) and [script](/guides/bench/create-resume.sh). It did not time forks or `small`. This page quotes only tonight's numbers.

## FAQ

### Why is a resume quicker than a new sandbox?

A resume with memory loads the saved VM image back instead of booting. In our runs it was up by the CLI's 1-second check every time, while creates, forks and cold resumes were seen at the 3-second check.

### Does a bigger size start more slowly?

Not between `small` and `default` in our runs: their medians were within 10 ms for every step. We didn't time `large` or `xlarge`.

### What happens to the time if memory can't be restored?

The sandbox boots from disk. When we forced that with a size change, resume took a median 3.38 seconds and running processes were gone. A CPU mismatch can add up to 2 minutes of waiting for a matching machine before that boot.

### Do resumes and forks count against my start limits?

Yes. Creates, resumes and forks each count as one start (see [limits](/docs/limits)).

### What if I need an answer at once when no machine is free?

Pass `--fail-fast` to `sbx new`, `sbx resume` or `sbx fork`. Within about a second and a half you get either the usual `202` or `503 no_ready_machine`, and a refused request isn't billed or counted as a start.

## Related

- [Pause and resume a cloud sandbox with its memory](/guides/pause-and-resume-a-sandbox-with-memory)
- [Can you fork a running cloud sandbox, memory and all?](/guides/fork-a-running-sandbox-with-memory)
- [Snapshots: stop, resume and fork](/docs/snapshots)
- [Machine sizes](/docs/machines)