Skip to main content
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.
DeploymentSleeps?
Single-repo PR previewsYes
Multi-repo environment PR previewsYes — the whole instance sleeps and wakes together
Manual runsYes — same idle rule as previews
Environment primary instancesNo — 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; 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.