Skip to main content

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.

A PR preview that nobody is looking at burns CPU and memory for no reason. Sleep scales those previews to zero replicas after a configurable idle window, then wakes them back up on the next inbound request. The namespace, Ingress, Service, secrets, and stored data all stay — only the pods go away. Your preview URLs keep working; the first request after a sleep takes 5–20 seconds extra while the pod cold-starts.

​
What sleeps

Sleep is scoped to PR previews, not your stable workloads.
SurfaceSleeps?Why
Standalone PR previews (single-repo pull_request deploys)✅Reviewers come and go.
Convoy PR instances (multi-repo PR-spawned environments)✅ — the entire instance sleeps togetherComponents in a convoy depend on each other; we wake them all at once.
Convoy primary instances (the convoy’s own long-lived environment)❌Treated like production.
Manual / push deploys❌If you deployed it manually, you want it running.
For convoy PR instances, sleep is atomic across components — every vessel scales to zero together and wakes together. A request to any one of the convoy’s public URLs wakes the whole formation.

​
How wake-up works

When you click a sleeping preview’s URL in a browser:
  1. Your request hits nginx-ingress, which routes to slipway’s activator (a dedicated listener on the master).
  2. The activator sees the preview is sleeping and redirects you to a branded “Waking up…” page on the slipway dashboard.
  3. That page polls the wake status every 500ms while slipway scales the pod (or every component in a convoy instance) back to one replica.
  4. Once readiness probes pass, the page redirects you back to your original URL with the same path and query string.
For non-HTML requests (fetch, curl, API calls), the activator holds the connection open and proxies it through once the pod is warm — up to 30 seconds. After that you get a 503 Retry-After: 5. If multiple requests arrive at the same sleeping preview, they all share a single scale-up — slipway dedupes wake-ups internally, so 100 concurrent visitors trigger exactly one kubectl scale --replicas=1.

​
Configuration

Sleep is configured at three levels with override precedence: plan → org → repo (or convoy).

​
Plan level (operator)

The plan-level toggle is the master gate. When a plan has sleep disabled, every override below is ignored.
  • sleep_enabled — does this plan offer sleep at all?
  • default_sleep_idle_seconds — how long a preview must be idle before sleeping.
  • min_sleep_idle_seconds — the lower bound any override can pick (anti-thrash).
Configured under Admin → Plans → <plan> for self-hosted instances.

​
Org level

Org admins can narrow what the plan offers via two override fields:
  • override_sleep_enabled — force on, force off, or inherit from the plan. Force-on only takes effect when the plan already allows sleep.
  • override_sleep_idle_seconds — replace the plan’s default idle window for every repo and convoy in the org.
Manage at <org>/settings/billing (effective values are shown there; admin can edit via the admin org-billing page).

​
Repo level (standalone PR previews)

Per-repo sleep settings live at <org>/repos/<repo>/sleep:
  • Sleep idle previews — switch with three states: on, off, or inherit from organization.
  • Idle timeout (minutes) — per-repo override of the idle window, clamped to the plan’s min_sleep_idle_seconds.

​
Convoy level (PR-spawned convoy instances)

Per-convoy sleep settings live at <org>/environments/<convoy>/settings/sleep. The override applies to every PR instance spawned by that convoy. The primary instance is never affected.

​
What you see in the UI

  • Status pill on the deployment / environment detail page reads Sleeping or Resuming (with a moon icon or a spinner).
  • Wake panel on a sleeping detail page surfaces a manual Wake button — useful for warming a preview before a stakeholder demo.
  • Deployment table rows spine slate-grey when sleeping, pulse blue when resuming.
  • Phase strip keeps its normal Build → Deploy → Live ladder. Sleep is post-healthy state.

​
Hard TTL still wins

Sleep is a soft TTL. The original expires_at (hard TTL) keeps ticking the entire time a preview is sleeping. When the hard TTL expires, the namespace is deleted regardless of sleep state — sleeping doesn’t pause the clock. That’s by design: PR previews are ephemeral, and a forgotten PR shouldn’t keep stored data around indefinitely just because nobody pinged it.

​
What it costs

While sleeping:
  • CPU + memory: ~0. The Deployment is at 0 replicas; pods are gone.
  • Storage: unchanged. PVCs (if any) survive sleep — your database data, file uploads, etc. are still there when the pod wakes.
  • Network: a single ExternalName Service in the namespace pointing at the activator.

​
Caveats

  • Cold-start latency depends on your image. Node and Python apps typically warm in 5–15s; Java apps can take 30s+. Consider whether the wake-up UX is acceptable for what your preview demonstrates.
  • Background workers that need to keep running can’t tolerate sleep. Put them in a separate non-PR workload (or use a stable convoy primary instance).
  • WebSocket / SSE connections that were open at the time of sleep are dropped. The reconnect succeeds (and wakes the pod) but mid-stream state is lost.
  • First-request latency is felt by the visitor whose request happened to wake the pod. Subsequent visitors see normal latency until the next idle period.
  • Statuses — the sleeping / resuming enum values.
  • Events — the sleeping / resuming / awake event kinds.
  • Lifecycle — how a preview reaches healthy (and from there, eventually, sleeping).