How to stop Render spinning down your free service

Someone clicks your link, waits, and gets a spinner for the better part of a minute. By the time the page loads they've already decided it's broken. Your Render service wasn't down — it was asleep.

Render's free web services spin down after fifteen minutes with no traffic. The next request wakes them, but waking isn't instant: the container has to cold-start, and the first visitor eats that delay.

It's the same trap Supabase projects fall into, just faster and quieter. Here's exactly when it happens, why the obvious fix has a catch, and what actually keeps a free app responsive.

Why Render spins free services down

A free web service that goes fifteen minutes without an inbound request is spun down to free up resources. Nothing is deleted — your code and config are intact — but the running process stops.

When the next request arrives, Render spins the service back up. That cold start can take up to a minute or more while the container boots and your app initialises. Every request in that window waits, and slow-loading links get abandoned.

15 min

of no traffic before a free service spins down

~1 min

cold start the next visitor waits through

750 hrs

free instance hours per month, per account

$7/mo

the paid tier that never spins down

Not sure whether your service is cold right now? One request settles it — a spun-down service answers slowly on the first hit, then normally after.

The obvious fix, and its catch

The usual move is a keep-warm ping: something that hits your URL every few minutes so the service never sits idle long enough to sleep. A GitHub Action or an external pinger both work.

The catch is the free tier's other limit. Free web services share 750 instance hours a month across your whole account, and a month is about 730 hours. Keep one service awake around the clock and you burn nearly the entire allowance on that alone.

If a fast first load actually matters, the honest answer is the $7/month starter tier, which never spins down. Keep-warm is a workaround for projects where the occasional slow start is fine and you just want to cut down how often it happens.

If you do go the ping route, write it so a failed request turns the run red instead of silently green — otherwise a broken service and a working one look identical. Hand this to your AI tool:

Set up a keep-warm ping for my Render free web service so it doesn't cold-start on the first visitor.

Requirements:
- Use a GitHub Actions workflow on a schedule that sends a GET request to my service URL every 10 minutes.
- Also allow workflow_dispatch so I can trigger it by hand.
- Fail the job (non-zero exit) if the response is not HTTP 200, so a service that's actually down shows up as a red run instead of a silent green one.
- Add a comment in the file warning me that (a) GitHub disables scheduled workflows after 60 days of no repo activity, and (b) keeping a free Render service awake around the clock uses roughly the whole 750-hour monthly free allowance, so a second always-on free service will get suspended.

Give me the full .github/workflows/keep-warm.yml and tell me where to put my service URL.

Knowing when it's actually down, not just cold

A keep-warm ping has the same blind spot as any keep-alive script: it can't report its own death. If GitHub disables the workflow after sixty idle days, or your service starts failing to boot, there's no run left to go red — and you find out from a user.

The reliable version is to watch the service from the outside. Point a monitor at the URL and the moment it stops answering — or starts taking thirty seconds to — you get an email, not a support message.

That's what Tell Me When Down does, and it watches the keep-warm job itself too, so a workflow GitHub quietly switched off shows up as a silent cron instead of a mystery.

On a different free host with the same problem? If your database is on Supabase, it pauses on a slower clock for the same reason — worth a read if that's in your stack.