Render's free web services sleep after 15 idle minutes

The workload

Render's own documentation for its free instance type states a specific behaviour a founder running a Free web service has to design around: the page, retrieved 16 September 2026, states that Render spins down a Free web service that goes 15 minutes without receiving any inbound traffic. The workload this creates is not operational maintenance so much as a design constraint: any Free-tier service that expects to respond instantly to an unpredictable first request has to account for the fact that it may not be running when that request arrives, which matters for anything a founder might route real user traffic to without warning, such as a webhook endpoint or an API a customer calls directly.

What the documents show

Verified: the documentation states that after inactivity spins a service down, the next inbound request triggers a restart that takes about one minute, during which Render displays a loading page to connecting browsers while the service spins up. Verified: Render's pricing page states the Free web-service tier this applies to runs on 512 MB of RAM and 0.1 CPU, and frames Free compute plans as intended for exploring the platform or building a personal project rather than production traffic. The two documents are consistent: one states the resource allotment, the other the inactivity behaviour it comes with, and neither describes spin-down as an error.

The operating cost

Verified: there is no direct dollar cost to spin-down; the Free tier remains $0 per month regardless of how often a service cycles. Estimated: the real cost is latency, not currency, since a request arriving after 15 idle minutes waits about one minute for the loading page to resolve, per the documentation. For a service where that delay is unacceptable, the pricing page's alternative is the paid Starter tier at $7 per month, which is not described as spinning down.

The stop condition

The documentation does not state a threshold for when spin-down stops being acceptable; that judgment is left to the account holder. Editorially, a reasonable stop condition is traffic-based: once a service receives real, externally-initiated requests on an unpredictable schedule, rather than requests the founder controls and can pre-warm, the one-minute cold-start delay each 15-minute idle window can create becomes a user-facing reliability issue, at which point the documented behaviour is a reason to move to a paid tier rather than to treat spin-down as a free feature to route around.

• Does anything outside the founder's control (a webhook, a third-party integration, a customer-facing API) call this service without warning?
• Is a roughly one-minute delay on the first request after 15 minutes of inactivity acceptable for this specific use case?
• Would a scheduled request every 14 minutes to prevent spin-down cost more in complexity than simply paying for the Starter tier?

Render states the spin-down behaviour plainly and without euphemism; the documentation frames it as part of what the Free tier is, not as something the service is failing to do, which is the useful distinction for anyone deciding whether Free is the right tier for a given service.