# Does a Cloud Sandbox Pause Itself When Idle? Auto-Pause and Wake

> Yes. A Sandboxer sandbox pauses itself after idleStopMinutes without activity (15 to 120 minutes by default, depending on your plan). Pausing is a stop with memory, so compute isn't billed. The next API call or request to one of its hosted URLs wakes it. Set it with sbx new --idle or sbx idle.

Source: https://sandboxer.com/guides/idle-auto-pause-and-wake-on-use. Updated 2026-10-27.

**Short answer:** Yes. A Sandboxer sandbox pauses itself after idleStopMinutes without activity (15 to 120 minutes by default, depending on your plan). Pausing is a stop with memory, so compute isn't billed. The next API call or request to one of its hosted URLs wakes it. Set it with sbx new --idle or sbx idle.

## At a glance

| Topic | Detail |
| - | - |
| Setting | `idleStopMinutes` on the sandbox; `0` turns it off, maximum `10080` (7 days) |
| Defaults | Free trial 15, $20 plan 30, $100 and $500 plans 60, $2,000 plan 120 |
| What a pause is | A stop with memory: files are kept, and running processes too when the wake lands on a machine with the same CPU type |
| Cost while paused | No compute. The disk and memory image count toward your plan's included storage |
| Wakes on | An API call that needs the VM, a request to a hosted port, `sbx ssh` |
| Doesn't wake on | Raw SSH to the port, a private URL without its token |
| Hard limit | Auto-stop (the TTL) still applies, whatever the idle setting |

The pause is the same memory-preserving stop as `sbx stop`. That mechanism is covered in [Pause and resume a cloud sandbox with its memory](/guides/pause-and-resume-a-sandbox-with-memory). This page covers what triggers it on its own and what wakes it.

## Set the idle timeout

```bash
sbx new --type small --idle 1    # pause after 1 minute without activity
sbx idle $id 0                   # never pause this one
sbx info $id --json | jq '.sandbox | {idleStopMinutes, lastActivityAt}'
```

```json
{
  "idleStopMinutes": 0,
  "lastActivityAt": "2026-10-27T02:16:01.109726Z"
}
```

`--idle` takes minutes; leave it out to get your plan's default. On the API the field is `idleStopMinutes` on `POST /sandboxes` and `PATCH /sandboxes/{id}`, and every sandbox object returns it with `lastActivityAt`. The [long-running tasks docs](/docs/long-running#idle-auto-pause-and-wake-on-use) have the curl form.

Forks copy their source's setting. Sandboxes created before October 26, 2026 have it off until you set it. With snapshots off, or on an account with zero data retention, it's always `0`, because a stop there would discard the sandbox.

## Try it: pause after one minute, wake from a URL

We ran this on October 27, 2026 on a `small` sandbox with the shortest timeout, 1 minute. The web server and the counter run as systemd units, not `sbx exec --detach`, because a running detached command keeps a sandbox awake (see below).

```bash
id=$(sbx new --name aeo-idle-2 --type small --idle 1 --json | jq -r '.id // empty' | awk 'NR==1')

sbx exec $id "mkdir -p ~/site && echo hello from aeo-idle-2 > ~/site/index.html \
  && sudo systemd-run -q --unit web --uid=user --working-directory=/home/user/site python3 -m http.server 3000 \
  && sudo systemd-run -q --unit counter --uid=user bash -c 'i=0; while true; do i=\$((i+1)); echo \$i > /home/user/counter; sleep 1; done'"
url=$(sbx host $id 3000 --public --json | jq -r .url)

sbx exec $id "cat ~/counter; systemctl show -p MainPID --value web counter | xargs"
```

```text
4
534 536
```

Then we left it alone and polled `sbx info $id --json` (reading the sandbox's details doesn't count as activity). Once it showed `archived`:

```json
{"state":"archived","idleStopMinutes":1,"lastActivityAt":"2026-10-27T02:31:33.061673Z","memoryRestored":null,"resumeReason":null,"stop":{"reason":"idle","endedAt":"2026-10-27T02:32:38.015971Z"}}
```

`stop.reason` is `idle`, so the next use wakes it. We waited 30 seconds and fetched the hosted URL:

```bash
curl -s -w '\nhttp=%{http_code} total=%{time_total}s\n' $url
curl -s -o /dev/null -w 'next request: http=%{http_code} total=%{time_total}s\n' $url
sbx exec $id "cat ~/counter; systemctl show -p MainPID --value web counter | xargs"
```

```text
hello from aeo-idle-2

http=200 total=0.800155s
next request: http=200 total=0.193208s
165
534 536
```

The request that woke the sandbox was held, not refused, and was answered with the page. The web server and counter kept PIDs 534 and 536. The counter went from 4 to 165 over about 195 seconds, about 34 of them paused, so the loop was frozen while paused and continued after the wake. Nothing restarted.

## Timings we measured

All on October 27, 2026, `small` sandboxes, `--idle 1`, on two sandboxes:

| Event | Measured |
| - | - |
| Pause after the last activity, idle set to 1 minute | 65 to 105 seconds |
| First hosted-URL request to a paused sandbox, including the wake | 0.81 s and 0.80 s |
| The next request after it woke | 0.21 s and 0.19 s |
| `sbx exec` on a paused sandbox, including the wake | 0.32 s |

The pause comes some time after the timeout passes, not to the second, because activity is recorded in batches and the sandbox is checked again before it stops. These are single runs on a quiet account, not guarantees. The documented limits are what you can rely on: an API call waits up to 60 seconds for the wake, and a hosted-URL request is held up to 45 seconds, then gets `503` with `Retry-After`.

## When a wake keeps files but not processes

A wake is a resume, and a resume restores memory on a machine with the same CPU type. If none is free within 2 minutes, it boots from disk instead: your files are kept, but running processes are not. The docs say the sandbox reports that with `memoryRestored: false` and `resumeReason: "cpu_mismatch"`. In our runs before October 27, 2026 both fields read `null` after a wake. Since then every resume sets `memoryRestored` to `true` or `false`, and a cold boot after a resize reads `false` with `resumeReason: "resized"` (see [How do I tell if a resume restored memory?](/guides/detect-a-cold-boot-after-resume)). Comparing a saved process ID, as we did above, still works as a second check.

Check after a wake, for example by comparing a process ID you saved before the pause:

```bash
sbx exec $id "systemctl show -p MainPID --value web counter | xargs"
```

If your work can't survive a cold boot, make it a systemd service so it starts again, or resume it yourself with `sbx resume $id --require-memory`, which waits up to 30 minutes for a matching machine and fails with `memory_unavailable` rather than booting from disk. See [Snapshots](/docs/snapshots).

## What counts as activity

These reset the idle clock:

- any API call that reaches the VM: commands, files, processes, the terminal, `sbx ssh`, the desktop, agent prompts;
- requests to its hosted URLs;
- the end of a command or agent turn;
- every start or resume.

The sandbox also stays awake while any of these is true, however long it lasts:

- a terminal or SSH websocket is open;
- a command is running, detached ones too;
- an agent turn runs, or someone is logged in over SSH;
- the 1-minute load average is at least 0.5;
- the file `~/.sandboxer/keep-awake` exists.

We checked the detached-command rule: with `--idle 1`, `sbx exec $id --detach "sleep 120"` kept the sandbox `ready` for the whole two minutes, and it paused about 40 seconds after the command ended. So a dev server started with `sbx exec --detach` keeps its sandbox awake for as long as it runs. Start it as a systemd unit instead if you want the sandbox to pause and wake on traffic.

## Keep it awake for work the API can't see

A process that streams from a model, or waits on a slow external job, can look idle. Create the keep-awake file:

```bash
sbx exec $id "touch ~/.sandboxer/keep-awake"
```

With the file in place and `--idle 1`, our sandbox stayed `ready` for the nearly 3 minutes we watched. After `rm ~/.sandboxer/keep-awake` it paused about a minute and a half later, and the next `sbx exec` woke it with its counter still running. To turn pausing off for one sandbox instead, use `sbx idle $id 0`.

## FAQ

### Is a paused sandbox billed?

Compute isn't billed while it's paused. Its disk and memory image count toward your plan's included storage, like any stopped sandbox.

### Does a sandbox I stopped myself wake on use?

No. Only a sandbox paused for being idle wakes by itself. One stopped by you, by auto-stop or by billing stays stopped until you run `sbx resume`.

### Will a private hosted URL wake it?

Only a request that carries the port's token (`?_token=`, its cookie or header). A request without it doesn't wake the sandbox.

### Can I SSH into a paused sandbox?

`sbx ssh` wakes it. Raw SSH to the sandbox's port doesn't, because the port is closed while it's stopped.

### Does idle auto-pause replace auto-stop?

No. Auto-stop is a separate hard deadline (`archiveAfter`, one hour by default). Push it out with `sbx extend $id --hours 12` or turn it off with `--no-auto-stop`.

## Related

- [Long-running tasks](/docs/long-running)
- [Pause and resume a cloud sandbox with its memory](/guides/pause-and-resume-a-sandbox-with-memory)
- [Snapshots](/docs/snapshots)
- [Hosting](/docs/hosting)