Idle sleep: what happens to a free service with no traffic
Idle sleep stops a free web service that has had no requests and starts it on the next one. What can sleep, what never does, and how to handle cold starts.
What this covers
Idle sleep means a web service that has had no requests for a while is stopped, and started again by the next request that arrives. It is a trade with two sides, and both are worth stating plainly: a service that sleeps uses no memory or processor while nobody is using it, and in exchange the first request after a quiet spell waits while the service starts.
On Voroa, a free (Nano) web service sleeps after 15 minutes with no requests. It is rolling out now, so some free services will keep running for a while longer before it reaches them. Free services and databases also share a monthly pool of running hours per workspace - see Free instances. If a service of yours shows an error rather than the “starting” page, idle sleep is not the explanation - check deploy status and your deploy history and logs instead.
Idle sleep is also not a switch in your dashboard. There is no setting to turn it on for a service and none to turn it off. It is decided by the size a service runs on and by what the service is.
What a visitor would see while a service wakes
When a request arrives for a sleeping service:
- The request is held rather than refused. Your visitor does not get an error page.
- A plain Voroa page appears saying the service is starting. It refreshes itself every few seconds.
- As soon as the service is ready, that page is replaced by the content that was asked for.
The wait is your service’s own cold start - the same time it takes to become healthy after a deploy. A small service is usually well under a minute; a service that runs migrations, warms a cache or loads a large model at boot takes as long as that work takes. Once awake, it stays awake and serves normally until it goes quiet again.
Two things decide whether a service wakes at all:
- Only an HTTP request to the service’s own address wakes it, including requests to a custom domain you have attached. An uptime monitor pinging every minute would therefore keep a service permanently awake, and the traffic it generates counts towards your bandwidth allowance.
- Work that is not a request does not wake it. A queue filling up, a file landing in storage, or a job running somewhere else will not start a sleeping web service.
Which services can sleep, and which never do
| Web service on a free (Nano) size, with a health check path set | Can sleep |
| Web service with no health check path | Never sleeps |
| Web service built from a Dockerfile | Never sleeps |
| Web service running more than one copy | Never sleeps |
| Any service on a paid instance size | Never sleeps |
| Background worker | Never sleeps |
| Cron job | Never sleeps |
| Static site | Never sleeps |
| Managed Postgres and Key Value | Not affected |
| A service whose payment has failed | Not slept while that is unresolved |
The reasons matter, because most of them are things you control.
Paid instance sizes are not slept for being idle. That is the practical difference you are buying alongside the memory and the processor, and it applies per service: paying for one service changes nothing about another. This is not a setting anyone can get wrong on your behalf: a paid size cannot be given an idle timeout at all, so there is no combination of options that ends with a service you are paying for being stopped for being quiet.
A web service needs a health check before it can sleep. An older service that does not have one yet gets one automatically - its service restarts once, with no rebuild - and it starts sleeping after that. Waking is only useful if Voroa can tell the difference between “the service has started” and “the service can answer”. Without a health check path, a service that is still booting looks ready, the held request is released too early, and your visitor gets an error - which is worse than the memory that sleeping saves. You set the path under Settings, then Health Checks; see health checks for what makes a good one.
A service built from a Dockerfile cannot have that health check today. Voroa adds its health probe to the images it builds for you, and cannot add it to an image built from your own Dockerfile, so such a service is never slept - even with a health check path filled in.
A service running more than one copy is never slept. Sleeping and scaling do not combine: a sleeping service is woken as a single copy at a single address. This holds both ways - a service set to sleep cannot be scaled up, and Voroa refuses that change rather than doing something surprising with it.
A service whose payment has failed is left alone. Degrading the service of a customer we are in the middle of collecting from is the wrong response to a failed payment, so a service is not slept while its account is in that state. That is a statement about idle sleep only. It does not change anything else that follows an unpaid invoice - see usage and billing.
Background workers, cron jobs and static sites are excluded by what they are. A worker has no inbound requests, so nothing could ever wake it - sleeping one would just stop it, silently and for good. A cron job has to be running when its schedule fires. A static site is already the cheapest thing you can run, so there is nothing worth reclaiming.
Background workers and scheduled jobs
Neither a background worker nor a cron job sleeps, and one of those two is the right home for work that has to keep happening - not a web service kept alive by a pinger.
One case is worth knowing about. A scheduled task attached to a web service runs inside that service’s own container. A stopped container cannot run one, so those runs would be missed for as long as the service stayed asleep, and would resume once traffic woke it. If a web service of yours carries scheduled tasks that must not be missed, move that work to a cron job, which runs on its own.
What sleeping does not change
- Your data. A managed Postgres or Key Value database is not touched by any of this, and neither is a persistent disk.
- Your address. The service URL, any custom domain, and the HTTPS certificate all stay as they are.
- Your settings. Sleeping and waking is not a deploy. Nothing is rebuilt, nothing is re-read from your repository, and your environment variables are unchanged.
- What you are told. A sleeping service is shown as Sleeping in your dashboard, in neutral grey rather than as a failure, and while it is asleep it is not reported to you as one.
- Your bill. Idle sleep does not change what a service costs or which plan it is on.
What to do about cold starts
- Cut your startup time. The wait is your service booting, so the shorter that is, the smaller the cost of sleeping. Moving migrations and other one-time work out of the start command is the usual win - see build and start commands.
- Keep the health check cheap and honest. It decides when the held request is released. One that answers before your dependencies are ready releases the request too early; one that runs a real query makes every wake slower.
- Use a paid instance size for anything user-facing. If a slow first request is not acceptable for a particular service, that is the direct answer - see instance types.
- Let the rest sleep. A demo, a staging service, an internal tool or a hobby project is exactly what a free service that sleeps is for.