# Cold Starts Explained: Why Free-Tier Apps Sleep > Cold starts make the first request to a sleeping app slow. Why free tiers spin down, what it costs, and how to keep an app warm without paying for idle. 1. [Home](/) 2. [Blog](/blog) 3. What Are Cold Starts — and Why Your Free-Tier App Keeps Falling Asleep DeploymentJune 22, 20267 min read # What Are Cold Starts — and Why Your Free-Tier App Keeps Falling Asleep Cold starts make the first request to a sleeping app painfully slow. Here's why free hosting tiers spin down, what it costs you, and how to keep an app warm without paying for idle capacity. ## The short version A cold start is the delay a request pays when it lands on an app the platform had stopped. Free tiers spin containers down after roughly 15 minutes idle, and waking one costs seconds rather than milliseconds. It is a property of the plan, not of your code — so optimising startup only shaves a floor the platform set. [Teo Marquardt](/about#author)· Updated August 21, 2026 You open your side project to show a friend, and the first page just sits there. Eight seconds, maybe more. You refresh and it loads instantly. That gap has a name: a cold start. On most free hosting tiers it isn't a glitch, either. It's how the economics work, and it's worth understanding before you reach for a fix. ## What is a cold start? A cold start is the delay you pay when a request arrives at an application that isn't currently running. The container holding your app was stopped to free up resources, so before anyone can get a response, the platform has to bring it back to life. That wake-up is a stack of steps run back to back: schedule the container onto a host, pull or unpack the image, boot the runtime, run your startup code, open database connections, warm whatever caches you keep in memory. That last step is the one a shared cache changes, because [a cache outside the process survives the restart while an in-process one does not](/blog/cache-aside-write-through-write-behind). None of it is slow on its own. Stacked together, though, they turn a request that should take 50 milliseconds into one that takes several seconds. The next request lands on a container that's already running, so it's quick again, right up until the app goes idle and you're back where you started. That last step is worth pulling out: an in-process cache is empty again after every wake-up, while [a cache that lives outside the container](/blog/when-to-use-redis-cache) still has its entries, which is one of the quieter reasons teams move one out of application memory. The database step deserves a note, because it has a failure mode of its own. A container that wakes up opens a fresh connection pool, and the pool belonging to the instance it replaced isn't always closed by then. Scale up and down a few times in quick succession and those overlapping pools can exhaust the database's connection limit, which surfaces as [PostgreSQL's "too many clients already" error](/blog/postgres-too-many-clients-already) rather than as anything that looks like a cold start. ## Why free tiers put your app to sleep Keeping a container running costs the provider money whether anyone uses it or not. A free app with one visitor a week would otherwise sit on CPU and memory around the clock for nothing. So most free tiers take that capacity back: after a short stretch of inactivity, usually about 15 minutes, they spin the container down. The next visitor pays for waking it up. It's a reasonable trade for the provider. The problem is that the inactivity timer is usually blunt: it doesn't distinguish between an app nobody uses and an app that simply had a quiet 20 minutes overnight. Both get put to sleep, and both make their next real visitor wait. ## "Your free instance will spin down with inactivity, which can delay requests by 50 seconds or more" That sentence is Render's, shown in its own dashboard next to a free web service, as of writing. It is quoted here because it is the clearest statement any provider makes about the trade, and because the number in it is not marketing pessimism. Fifty seconds is the provider's own estimate of a worst case, and people do search for that exact line after reading it and wondering whether it is normal. It is normal, and the number decomposes into the steps listed above. Scheduling and image pull dominate on a first wake, the runtime boot is whatever your language costs, and then your own startup code runs: migrations checked, connection pools opened, config fetched, caches filled. A small Go binary can be serving in a second. A Rails or Spring app that opens a database connection and warms an ORM will use most of the fifty. The provider quotes the upper end because it has to cover the slowest app on the platform, not because it is being careful with you. Two things follow. The delay is paid by a visitor, not by you, so you will rarely see it yourself once you have been clicking around your own app. And it is a property of the plan rather than of your code, so optimising your startup shaves seconds off a number whose floor is set by the platform. ## What a cold start actually costs you A few seconds sounds harmless until you trace where those seconds land: * **First impressions.** The one moment you actually share the link, whether it's a client demo, a Show HN post, or a recruiter opening your portfolio, is exactly when the app is most likely to be cold. * **Webhooks that don't retry.** A payment provider or Git host fires a webhook, your sleeping app takes too long to wake, the sender times out, and the event is silently lost. * **\[Cron jobs\](/services/cron-jobs) and health checks.** A scheduled call hits a cold container, exceeds its timeout, and is logged as a failure that never actually had a chance to run. * **Uptime and SEO crawlers.** Monitoring tools and search bots record the slow first response, dragging down the numbers you're trying to improve. ## Cold starts vs. genuinely idle apps: a false tradeoff The usual framing is that you either pay for an always-on server or live with cold starts. But that bundles two separate questions into one. Should an app nobody touches keep burning resources? Reasonably, no. Should an app that's actively used ever go cold? Also no. A 15-minute timer can't tell those two apart, so it punishes both. The distinction that matters Reclaiming a container that has had zero traffic for weeks is good housekeeping. Sleeping a container that served a request 16 minutes ago is just shifting cost onto your next visitor. A platform can do the first without doing the second. ## How to keep an app warm ### 1\. Ping it yourself The classic workaround is an external scheduler that hits your app every few minutes so the inactivity timer never fires: bash ``` # A cron entry that pokes the app every 10 minutes */10 * * * * curl -fsS https://my-app.example.com/health > /dev/null ``` It works, but it's a band-aid. You're burning compute around the clock to fake activity, the keep-alive ping itself counts toward any request or bandwidth limits, and several providers explicitly discourage or block it. You've rebuilt always-on, just less reliably and against the grain of the platform. ### 2\. Pay for an always-on instance Upgrading to a paid plan removes the inactivity sleep entirely. The container keeps running on dedicated resources, which is the right call for anything in production. The catch is that it's overkill for the long tail of small but real projects that barely touch the CPU yet still shouldn't greet a visitor with an eight-second wait. ### 3\. Use a platform that doesn't sleep active apps The cleanest fix is to not make the tradeoff at all. On [Runsite Web Services](/services/web-services), free apps stay warm as long as they're getting traffic, so an active app never cold-starts. A container is only suspended after 14 full days without a single request, and the next visit wakes it back up with your code, environment variables, and storage intact. So any live demo, bot, or side project with even the occasional visitor never goes cold. Only the genuinely abandoned ones get reclaimed. The image it wakes up from is whatever your last deploy produced, which is a mechanism worth knowing in its own right: [what actually happens between git push and live traffic](/blog/git-push-to-deploy). Want a hard guarantee that an app never sleeps, even after weeks of total silence? Starter and above, [from €5/mo](/pricing), skip the inactivity window completely. Everything runs in the EU (Germany) with a signed [GDPR data processing agreement](/blog/what-is-a-data-processing-agreement-dpa) on every plan, so you're not trading responsiveness for data residency to get it. ## When cold starts actually matter Plenty of workloads don't care. A nightly batch job can swallow a few seconds of startup and nobody will ever notice, as long as the job runs outside the app; [a scheduler inside a container that has gone to sleep never fires at all](/blog/cron-job-multiple-instances). But anything a person is waiting on, anything another system calls with a timeout attached, anything you'll be judged on the first time someone clicks the link, that needs to stay warm. Staying warm and paying for idle capacity were never actually the same thing. You just need a platform that can tell a quiet app from a dead one. Related service ## Web Services on Runsite Deploy from a single git push and keep active apps warm — no cold starts, hosted entirely in the EU with a signed GDPR DPA on every plan. [Explore Web Services](/services/web-services) [Back to all articles](/blog) FAQ ## Frequently Asked Questions Common questions about this service. ### What does "your free instance will spin down with inactivity" mean? It is the notice Render shows in its dashboard beside a free web service, and the full sentence continues "which can delay requests by 50 seconds or more". It means the platform stops your container after a stretch with no traffic, usually around 15 minutes, and starts it again when the next request arrives. That restart is the cold start: the container has to be scheduled onto a host, the image unpacked, the runtime booted and your own startup code run before anything can be served. Fifty seconds is the upper end the provider quotes to cover the slowest applications on the platform; a small compiled binary often wakes in about a second, while a framework that opens database connections and warms an ORM on boot will use much more of it. The delay lands on whoever arrives first, not on you, and it is a property of the free plan rather than of your code, so tuning your own startup only moves part of the number. ### Do cold starts affect paid plans? As a rule, no. Paid plans run with dedicated resources and skip the inactivity sleep entirely, so the container stays running regardless of traffic. On Runsite the one exception is the €3 Nano entry plan, which suspends a service only after 14 consecutive days with no requests. Cold starts on free tiers come from the platform reclaiming idle capacity — paid instances aren't reclaimed. ### Is pinging my app a good way to keep it warm? It works, but it's a workaround. A keep-alive ping burns compute around the clock to simulate traffic, counts against request and bandwidth limits, and is discouraged by some providers. A platform that doesn't sleep active apps removes the need for it. ### How long until a Runsite app sleeps? A Runsite web service on the entry Nano plan (€3/mo) stays warm as long as it receives traffic — there are no cold starts on active apps. A container is only suspended after 14 consecutive days with zero requests, and the next request wakes it back up. Starter and above never sleep on inactivity. Keep reading ## Related articles [Deployment12 min readGit Push to Deploy: How Modern Web App Deployment Actually WorksWhat actually happens between git push and live traffic: build artifacts, health-gated releases, why a rollback isn't a rebuild, and the four things a deploy pipeline can't do for you.Aug 7, 2026Read](/blog/git-push-to-deploy)[Deployment15 min read8 European Heroku Alternatives in 2026 — and How to Check One Really Is EuropeanEight Heroku alternatives operated by European companies, checked on the column the lists leave out: which company you contract with, and where it is registered.Aug 7, 2026Read](/blog/european-heroku-alternative)[Deployment12 min readRender vs Railway: Pricing, Free Tiers, and the Question Neither AnswersEvery comparison argues per-second billing against fixed instances. That axis is real, and it is not the one that decides where your data lives.Aug 12, 2026Read](/blog/render-vs-railway) ## Your app deserves to be online €5 of credit on signup. Deploy in under a minute. No credit card needed. [Start deploying](https://dashboard.runsite.app/login)[View documentation](https://docs.runsite.app) --- Source: https://runsite.app/blog/cold-starts