How to keep a Railway app awake
Your Railway app was fine an hour ago. Now the first request hangs, then loads. It didn't crash — if you've turned on app sleeping, it went idle, Railway put it to sleep, and your visitor is paying for the wake-up.
Railway's sleep behaviour trips people up because it's not on by default and it's not really a "free tier" anymore. Sorting out what's actually happening is the first step to stopping it.
What Railway actually does now
Railway retired its old always-on free tier. New accounts get a one-time trial credit, then move to a usage-based plan where you pay for the compute you use. That changes the incentive: you don't want a service burning resources while nobody's using it.
So Railway offers App Sleeping (also framed as serverless): opt in, and a service with no inbound traffic is put to sleep to stop the meter. The next request wakes it, and that first request eats the cold start.
- opt-in
- App Sleeping is off until you enable it
- ~10 min
- typical idle before an enabled service sleeps
- usage-based
- no perpetual free tier — you pay for compute
- cold start
- the first request after sleep waits to wake it
Keeping an enabled service awake
If you want app sleeping on to save money but hate the cold start on the pages that matter, the usual move is a keep-alive ping — hit a health URL every few minutes so the service never idles long enough to drop off.
Point the ping at a lightweight /health route, not a heavy page, and write it so a non-200 response marks the run as failed. Otherwise a keep-alive dutifully pinging a broken service looks exactly like one pinging a healthy one:
Write a GitHub Actions workflow that pings my Railway service so it doesn't sit idle long enough to sleep, and fails loudly if the service is actually down. Requirements: - Run on a schedule every few minutes, plus workflow_dispatch for manual runs. - GET a health URL I'll fill in. - Exit non-zero (mark the run FAILED, red) if the status isn't 200, so a real outage isn't a silent green check. - Add a top comment reminding me that: (a) this only matters if I've enabled App Sleeping / Serverless on the service, and (b) GitHub disables scheduled workflows after 60 days of no repo activity, so the ping can silently stop. Give me the full workflow file and tell me where to paste my URL.
Be honest with yourself about the trade, though: ping it around the clock and you've mostly cancelled out the savings that made you enable sleeping in the first place. Keep-alive earns its keep when only a few endpoints need to be instant and the rest can cold-start in peace.
Why the ping isn't enough on its own
A keep-alive has one fatal flaw: it can't tell you when it dies. GitHub disables scheduled workflows after 60 days of repo inactivity, an external pinger can lapse, and either way the pings just stop. Your service goes back to sleep, and the first you hear of it is a "your site is slow" message.
The durable fix is to watch the service from outside your stack, the way a user would. The same failure that sleeps a Railway app also shows up on Render and Neon; the cross-host playbook lives in how to keep a free backend awake.
Sleep to save money — just don't sleep blind.
Join Tell Me When Down free and we'll watch your Railway service from outside, around the clock. A cold start that turns into a real outage, or a keep-alive that quietly stopped — you get an email in minutes, not a message from a user.
spot something wrong or out of date? [email protected] — we'll fix it