Skip to main content
Sleep scales a web service to zero replicas after a stretch with no traffic, then brings it back when the next request arrives. A sleeping service costs nothing while it is asleep. Sleep is set per service, so a low-traffic admin panel can sleep while the API beside it keeps serving.

​
Which services can sleep

A service you have paused by hand is left alone: it is not put to sleep, and a request does not wake it. Start it first. A service can sleep only if it has a public port. The only thing that wakes one is an HTTP request arriving at its public URL, so a worker, a cron service, an internal-only service or a managed database would scale to zero and never come back. Those services do not offer the Sleep tab.

​
Setting it

Open the service’s Sleep tab. The strip at the top shows the current state: awake with the time of the last request, sleeping with a Wake button, or waking. Turn the switch on and pick an idle window: 5 minutes, 15 minutes, 30 minutes, 1 hour, or a custom value. Changes apply live. Turning sleep on or off and changing the window all take effect on the running service with no redeploy, and turning sleep off wakes the service first if it is asleep.
The floor is 5 minutes. A shorter window would put pods back to sleep faster than they can warm up, so a smaller value is rounded up.

​
On the Free plan

On the Free plan, sleep is always on for every wakeable service with a fixed 5-minute window. It cannot be changed or turned off. Services that cannot wake, such as workers and databases, run normally and draw from your balance instead. Because sleep owns the replica count, a wakeable service runs at one replica here even if it is set to autoscale. The deploy goes through and its timeline says so. Workers and databases keep their scaling settings, since sleep never reaches them. On a paid plan, sleep is off by default and entirely yours to set. See Plans.

​
What happens when a service sleeps

Sleep scales the service to zero replicas. Variables, secrets, disks and the public URL are all untouched, and the deployment itself stays healthy. Only the named service moves. When a request arrives for a sleeping service, slipway holds it, scales the pods back to their deploy-time replica count, and forwards the request once the service is ready. The first visitor waits out the cold start, usually a few seconds depending on how fast your app boots. Browsers get a waiting page; API calls are held open until the service answers. You can also press Wake to warm a service up before sending it traffic. Nothing wakes while the organization is paused for an empty balance or suspended for a payment problem. A sleeping service reads Paused alongside everything else, and top up brings it back with the rest. See Billing. Requests to a sleep-enabled service always pass through slipway’s in-cluster router, awake or asleep. The router is the only thing that sees your traffic, so it is what measures the idle window. The hop stays inside the cluster and adds a negligible amount of latency, and turning sleep off removes it.
An internal call does not wake a sleeping service. Only traffic arriving at the public URL does, so a sibling calling http://api inside the project fails until something wakes it from outside. Leave sleep off on a service that is mostly called by its siblings.

​
Billing

Compute metering stops the moment a service sleeps and resumes when it wakes. Its siblings bill normally throughout.

​
What sleep does not combine with

slipway rejects either combination when you save the setting, and again at deploy time.

​
Previews sleep differently

A preview sleeps and wakes as a whole instance, every service together, rather than per service. It is on by default, and the window is set on the base project’s Settings → Previews.

Pausing

Stop a service deliberately, on demand or on a schedule.

Scaling

Fixed replica counts and autoscaling.