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.
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. 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.
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.
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:
# A cron entry that pokes the app every 10 minutes
*/10 * * * * curl -fsS https://my-app.example.com/health > /dev/nullIt 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, 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.
Want a hard guarantee that an app never sleeps, even after weeks of total silence? Any paid plan from €5/mo skips the inactivity window completely. Everything runs in the EU (Frankfurt, Germany) with a signed GDPR 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. 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.