How Auto-Sleep Works: The 15-Minute Rule, What Counts as Traffic, and the One-Minute Wake

"My container went to sleep" is the support question we get most, usually followed by "but I was just using it". This post explains how auto-sleep behaves from where you sit: what counts as traffic, when a container is considered idle, what sleeping and waking actually do to your app, how the 100 free hours are counted, and why keeping a free container awake with a ping is the most expensive thing you can do with it.

What counts as traffic

A container is active when real HTTP requests reach your application and get a response. That is the whole definition, and three things follow from it:

• Platform health checks do not count. Your container is probed regularly to know whether it is up; those probes never keep it awake, or every container would be awake forever.
• Bots do count, when they get through. A crawler that reaches your app and gets a 200 is a request like any other. New subdomains get discovered within hours of going live, so a fresh container often receives a few visits you did not make, which is why the sleep email sometimes reports requests you cannot explain.
• WebSocket traffic is not counted. Activity is measured in HTTP responses; a page that only holds a socket open will still sleep after 15 minutes.

The 15-minute rule, and why it feels like 15 to 20

A container that has served no request for 15 minutes is put to sleep. The check runs periodically rather than at the exact second, so in practice a container whose last visitor left at 10:00 goes to sleep somewhere between 10:15 and 10:20. When it does, you get an email that says how many requests it served before it slept; that number is how most people discover the crawler visits from the previous section.

Why 15 minutes: it is long enough that a person reading a page and clicking again does not hit a sleeping container, and short enough that a container nobody is using stops spending your free hours after a quarter of an hour. Longer thresholds mostly burned hours on containers whose only visitor was a bot.

What never sleeps

• Containers with Always-On. It is per container: an Always-On container ($12/month for Small, $25 for Medium, $45 for Large) is never put to sleep, whatever its traffic.
• Medium and Large containers exist only with Always-On. If the subscription lapses, the container is stopped and kept at its size until it returns; it does not fall back to a sleeping free container.
• GPU containers, which follow their own subscription and are not part of auto-sleep at all.

What sleeping means for your app

A sleeping container is stopped, not paused: it uses no CPU and no memory, and its filesystem is gone. The image is kept and the next start uses it, but anything the app wrote to disk (a SQLite file, an uploads folder, a cache) is not there when it wakes. That is why every guide on this blog says to keep state in a database or object storage. While the container is asleep, its URL shows a wake page instead of an error, so a visitor never sees a connection failure.

What waking looks like

1. A visitor opens the URL and immediately sees the wake page with a progress indicator.
2. The container is started in the background. This is the roughly 60 seconds you experience; for a large image or a slow-starting framework it is longer, which is why we say "about a minute" and not a number we cannot promise.
3. As soon as the app answers on its port, the visitor is redirected to it. Later requests are instant while the container stays awake.

Your application's own start-up time sits inside step 2. A Go binary is ready as soon as the container is up; a Spring Boot app on a quarter vCPU adds 15 to 40 seconds of its own. Making the app start fast, and answering a health check as early as possible, is the only part of the wake you control, and it is worth doing: our language guides each have a section on it.

How the 100 hours are counted

• Hours accrue only while a container is running. A sleeping or stopped container costs nothing. The counter is per account, shared across all four free containers.
• The counter resets on a rolling monthly window that starts from your own sign-up date, not on the first of the month.
• At 50%, 75% and 90% you get an email. At 100% starting or waking a free container is refused, with a message that says so, until the window resets. Nothing is deleted.
• The Stop button in the dashboard is a manual sleep: same effect, same wake on the next visit, but you chose the moment. Stopping a container you are done with for the day is the single easiest way to make the hours last.

About keep-alive pings

People set up a cron job on another service to hit their container every ten minutes so it never sleeps. It works, mechanically: each ping is a real request, and the container never idles. It is also the fastest way to spend the free tier. A container kept awake around the clock uses 720 hours a month against a budget of 100; the budget runs out in about four days and the container then stays down until the window resets, which is worse than a one-minute wake. If an app has to answer instantly at any hour, that is what Always-On is priced for. If it does not, let it sleep; the wake page is there so the first visitor sees a loading screen rather than an error.

Making the free tier feel bigger

• Keep images small and start-up fast; a wake is mostly the app coming up.
• Put a health route in every app and make it answer before heavy initialisation finishes, so the redirect happens sooner.
• Stop containers you are not using this week. Four containers that each sleep are free; four that each get a daily ping are not.
• Put the one app that must be instant on Always-On and leave the rest free. That split is what the pricing is designed for.