The free tier's spin-down behavior, and the cold start it causes
A free web service on Render isn't simply slower than a paid one — it's not running at all, most of the time, and understanding exactly when and why it wakes back up is the difference between a confusing first impression and a predictable, explainable one.
Beginner
2 min read
What actually happens to a free web service after 15 minutes of inactivity
No requests for 15 minutes → Render STOPS the service entirely,
freeing up the compute resources
Next request arrives → Render starts the service fresh —
a real "cold start," not a cache miss
A free-tier web service on Render isn't throttled or rate-limited while idle — it's actually, fully stopped, with the compute resources reclaimed entirely. This is a genuinely different mechanism than Vercel's own cold-start behavior (a Serverless Function cold start, its own domain's lessons 5 and 12 cover this) — Render's free-tier spin-down is specifically an idle-service behavior for a continuously-running process, not a per-invocation concern for a function that was always designed to start and stop constantly.
Why the very first request after idle time can take tens of seconds
Starting a stopped service from scratch means the full container boot, language runtime startup, and application initialization sequence all happen synchronously before that first request can even be handled — this is a real, visible delay, not a bug, and it's specifically why a demo or a side project on Render's free tier can feel broken ("it's just loading forever...") to anyone hitting it after it's been idle, when in fact it's working exactly as the free tier is designed to.
Why this trade-off exists at all: it's what makes the free tier free
Render's free tier exists specifically because an idle service genuinely consumes zero compute resources once stopped — this is a real, deliberate cost-control mechanism, not an arbitrary inconvenience, and it's the same underlying economic logic Railway's own usage-based billing domain covers from a different angle: paying (or, here, not paying) for compute actually consumed, rather than for capacity reserved whether used or not.
The practical mitigations, and their real limits
- Upgrade to a paid plan: the service never spins down at all
- An external "keep-alive" ping every 10 minutes: technically
works, but burns the exact free compute the tier exists to
limit, and many teams consider it against the tier's intent
A paid plan is the actual, intended fix for anything where the cold start genuinely matters (a real user-facing app, not a personal side project). Pinging the service periodically to prevent it from ever going idle technically works, but defeats the entire economic purpose of a free tier and is the kind of workaround worth being honest with yourself about rather than treating as a genuine, sustainable solution.