How to keep a free backend awake

Free hosting has a catch nobody puts on the pricing page: leave a project idle and the host puts it to sleep. The next visitor gets a spinner, a cold start, or a blank page — and decides your app is broken.

Supabase pauses. Render and Railway spin down. Neon scales to zero. The wording differs, the mechanism is the same: no traffic for a while, so the host stops your process to reclaim the resources. This is the map to keeping a free backend responsive — and the trap most guides skip.

Why free tiers sleep in the first place

Idle apps still cost the host money to keep running. Free tiers make that math work by only spending resources when someone's actually using your app. Go quiet long enough and the process is suspended; the next request wakes it, paying a cold-start delay to do so.

Nothing is deleted — your code, data, and config survive. What you lose is the first visitor's patience while the container boots back up. Each host draws that line at a different point:

~15 min

Render free service spins down after idle

~10 min

Railway sleeps an idle service (when enabled)

5 min

Neon scales a free branch to zero

7 days

Supabase pauses a free project with no activity

The keep-alive everyone reaches for

The standard fix is a keep-alive: something that hits your app every few minutes so it never sits idle long enough to sleep. A scheduled GitHub Action, a cron job, or an external pinger all do the job.

It works — with two catches worth knowing before you lean on it. First, on hosts that meter usage by the hour (Render's 750 free instance hours a month, for one), keeping a service awake around the clock burns nearly the whole allowance on nothing but pings. Second, and worse:

If you do run one, write it so a failed ping turns the run red instead of silently green — otherwise a broken service and a healthy one look identical in your Actions tab. This prompt does that:

Write me a GitHub Actions workflow that keeps my free backend awake by pinging its health URL, and make it fail loudly if the service is actually down.

Requirements:
- Run on a schedule every 10 minutes, plus workflow_dispatch so I can trigger it by hand.
- Send a GET request to a URL I'll fill in (a lightweight health endpoint, not the homepage).
- Treat the run as FAILED (non-zero exit) if the response status is not 200, so a service that's actually broken shows up as a red run instead of a silent green one.
- Add a comment at the top warning me that GitHub disables scheduled workflows after 60 days with no repo activity, so the keep-alive can quietly stop and I won't be told.

Give me the full .github/workflows/keep-alive.yml and tell me exactly where to paste my URL.

Your host, specifically

The rule's the same everywhere; the numbers and the fix aren't. Here's the deep-dive for each of the common free hosts:

Supabase pauses a free project after a week of inactivity, and waking it isn't instant. Render spins a free web service down after fifteen idle minutes and cold-starts the next request. Railway sleeps a service when you've enabled app sleeping — and its free allowance runs on a different clock again. Neon scales a branch to zero after five idle minutes, which is great for your bill and rough on first-query latency.

The honest fix: watch it from outside

Every keep-alive shares the same blind spot — it runs inside the same world it's trying to protect, so when it dies, so does your only warning. The reliable version is a monitor that lives outside your stack and watches the app the way a user would.

Point one at your URL and the moment the app stops answering — asleep, crashed, or cold-starting for thirty seconds — you get an email, not a support ticket. It also watches the keep-alive job itself, so a workflow GitHub quietly switched off shows up as a silent cron instead of a mystery outage.