> ## Documentation Index
> Fetch the complete documentation index at: https://docs.slipway.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Sleep & wake

> Idle previews and manual runs scale to zero and wake on the next request.

A preview nobody is looking at wastes CPU and memory. **Sleep** scales an idle instance to zero after a quiet window and wakes it on the next request. The URL, data, and secrets all stay — only the running container goes away. The first request after a sleep takes a few extra seconds while the app cold-starts.

## What sleeps

Sleep applies to **non-production instances that sit idle** — PR previews and manual runs. Your primary (production) instance keeps running.

| Deployment                                         | Sleeps?                                            |
| -------------------------------------------------- | -------------------------------------------------- |
| Single-repo PR previews                            | Yes                                                |
| Multi-repo environment PR previews                 | Yes — the whole instance sleeps and wakes together |
| Manual runs                                        | Yes — same idle rule as previews                   |
| Environment primary instances                      | No — treated like production                       |
| Push to the default branch (redeploys the primary) | No — that's the production instance                |

## Waking up

Open a sleeping preview's URL in a browser and slipway shows a brief "Waking up…" page while it starts the container, then redirects you back to where you were headed. For API calls (`fetch`, `curl`), slipway holds the connection open and proxies it through once the app is warm — up to 30 seconds, after which you get a `503 Retry-After: 5`. Many requests to the same sleeping preview share a single wake-up.

You can also warm a preview ahead of a demo with the **Wake** button on its page.

Sleep and wake both narrate into the deployment's **log viewer**, not just the event timeline. A wake streams the container's real cold-start output live, the same as a fresh deploy, so you can watch it come back up.

## Configuration

Two things decide sleep behavior: your **plan** and your **per-repo / per-environment** settings.

Your plan decides whether previews sleep at all and whether you can change it. On some plans sleep is enforced with a fixed idle window; on others you tune the window down to a plan-defined floor. See [Plans & pricing](/organization/plans); your effective values show on **Settings → Billing**.

When your plan allows it, override the idle window per repo (the repo's **Sleep** settings) or per environment (the environment's **Sleep** settings — applies to its PR previews and manual runs, never its primary). Each can be on, off, or inherit from the org.

## The hard TTL still wins

Sleep is a soft idle timer. A PR preview's hard expiry keeps ticking while it sleeps — when it expires, the preview is torn down regardless of sleep state. A forgotten PR shouldn't keep data around forever just because nobody pinged it.

## Caveats

* **Cold-start latency** depends on your image — Node and Python apps usually warm in 5–15s, Java can take 30s+.
* **Background workers** that must keep running don't tolerate sleep. Put them in a stable (non-PR) workload.
* **Open WebSocket / SSE connections** are dropped when a preview sleeps; reconnecting wakes it, but mid-stream state is lost.