A fresh sandbox is ready in 0.6 ms. App scale-out from a ready warm-pool
instance takes 1.5 ms. When the warm pool is empty, cold scale-out is ready to
accept connections in about 16 ms.

These are production-host measurements from local requests. They exclude
client network latency and application response time.

## ready before demand

Kedge keeps clean sandbox runtimes and initialized app instances ready in warm
pools. They are parked in a paused state until needed. A sandbox request gets a
fresh, hardware-isolated runtime. App scale-out resumes an instance whose app
and network are already initialized.

Neither path repeats a boot or starts the app again.

## when the warm pool is empty

Kedge restores an initialized instance from the
[deploy snapshot](/docs/runtime#snapshots), so cold scale-out does not repeat
app startup.

## see it on a request

App responses report whether that request waited for an instance:

```bash
curl -si https://myapp.kedge.run | grep x-kedge-restore
```

```text
x-kedge-restore: warm
x-kedge-restore-ms: 1.5
```

`x-kedge-restore` is `warm` or `cold` when the request triggered a restore, and
`none` when an instance was already running. `x-kedge-restore-ms` appears only
for a restore and reports how long the instance took to become ready.

See [runtime & scaling](/docs/runtime) for the snapshot lifecycle or
[sandboxes](/docs/sandboxes) for one-shot and interactive use.