# Sleeping and waking Services can sleep when nobody uses them, and asleep their size costs nothing. A [volume](/docs/volumes) is billed by its size either way, awake, asleep or stopped, since its disk is kept. Asleep is **paused**: the app's virtual machine is frozen where it was, for as long as it sleeps. The next request lets it go on, and it answers almost at once. Nothing asleep is ever stopped; only you stop a service (see [Switching a service off](#switching-a-service-off)). For its first half hour asleep, an app keeps everything in memory. After that it sleeps **deeply**: its memory moves to the server's disk (swap) and comes back as the app touches it, so the first answers after waking take a little longer: a small app's first answer took about a tenth of a second instead of a few hundredths. That's what lets a server keep many apps asleep without holding their memory. A server short of memory (it keeps a quarter free) does the same sooner, for the apps paused longest. ```diagram sleep A service is awake while it answers requests, billed at its size. After 10 minutes without a request (you choose how long) it's asleep: paused, frozen where it was with its memory kept, its size not billed. After half an hour it's deeply asleep: its memory moved to the server's disk. The next request wakes it from either and is held until it answers, in about 40 ms when paused and about a tenth of a second for a small app deeply asleep; calls from the project's other services wake it too. Only Stop switches it off, and then no request wakes it until Start. ``` The first request after a deployment starts the new version instead. While it starts it gets two cores, whatever its own size, so it's up sooner; the extra cores aren't charged. Either way the request is held, not dropped, and answered once the app is up. If the app opens its port before it can serve (many frameworks do), give it a [health check path](/docs/deployments): the request is then held until that answers, instead of reaching an app that isn't ready. ## Choosing In the service's **Scaling** tab, **When nobody is using it**: - **Sleep**: after 1, 5, 10 (the default) or 30 minutes, 1 or 6 hours, or a day without requests. - **Keep running once started**: never sleeps after the first request. - **Always on**: starts right away and keeps running. ## Private services A private service always runs, unless you ask it to sleep: **Sleep — a call from inside the project wakes it** in its **Scaling** tab, or `sleep = "10m"` beside `public = false` in [alf.toml](/docs/alf-toml). It then sleeps like a public one, and a call from the project's other services wakes it (see below). A [database](/docs/databases) never sleeps. Only calls wake it, so keep these running: - A worker that takes jobs from a queue: nothing calls it. - Anything with a timer of its own (a scheduler inside the app, a polling loop): it's paused with the rest. [Scheduled commands](/docs/deployments#running-something-on-a-schedule) are fine: they run in a container of their own. - A service that pushes to its callers on its own (a WebSocket hub broadcasting, a gRPC stream fed by a timer). A connection nothing moves on doesn't keep it awake. `alf doctor` warns about a private service that sleeps and that nothing in its project has called for a week: most likely one of these. ## Calls from inside the project A sleeping service wakes for the project's other services too, not only for visitors: when another service calls it by name (`web:3000`), the call is held while the app wakes, then answered. Calls from inside also count as use, so a service that's only ever called by your own backend doesn't fall asleep in the middle of it. How: every app has a stable address inside the project, held by its server (its front), and its name resolves there. The server wakes the app if needed and passes the call on; HTTP and gRPC calls are kept with the service's requests, saying which service made them. Databases are reached at their containers directly, as they're always there. Good to know: - When an app wakes from sleep, the services on its server that it called lately wake beside it, so a chain of sleeping services (a web app calling an API calling another) wakes side by side rather than one after the other. One that isn't called after all goes back to sleep after half a minute. A service on another server wakes when the call gets there. - A connection that's been quiet for a while (a kept-alive connection in a pool) doesn't keep the service awake. It stays open while the service sleeps, and the next call on it wakes the service first. - This needs private networking on the server (WireGuard; the Servers page says if it's missing). The service's **Networking** tab says whether calls from inside wake it. - TCP wakes it. UDP is passed straight to the container: it reaches an app that's awake, and doesn't wake one that sleeps. - These calls pass through the server program, like visitors' requests do: when it updates itself (a few seconds), open connections from inside are cut and callers reconnect. HTTP callers keep their own connection to the server, so an app being deployed again or waking doesn't cut it. ## Switching a service off Sleeping is the service's own idea and the next request undoes it. Switching it off is yours, and nothing undoes it: **Stop** on the service's page keeps it down until you press **Start**. While it's off: - Its address answers with a page saying it's switched off, and no request wakes it. - An always-on service stays down too, and a crash isn't restarted. - It isn't alerted on — nobody should be paged for a service they turned off themselves. - Deploying to it is refused: start it first. - Nothing is deleted. Its container is kept, so it comes back with the filesystem it was stopped with, and so do its volumes, its variables and its address. While it's off its size isn't billed; its volumes still are, by their size. Agents can do the same with the `stop_service` and `start_service` tools, and the API with `POST /services/{id}/stop` and `/start`. ## Good to know - Apps that start slowly (large runtimes, migrations on start) make the first visitor after a deployment wait longer. Keep those running, or make startup lighter. - Background work inside a sleeping app stops too: it's paused. Run it in a private service that's always on instead. - A paused app wakes exactly where it was, its open connections included. If the other side closed one meanwhile (a database that drops idle connections), the app reconnects as it would after any network blip; most database libraries do that by themselves. - **Wake-ups** and **wake time** are charted on the service's **Overview**, under **All metrics**.