How to Keep a Render Free Service From Sleeping: The Ping, the Cost, and the Robots.txt Trap

You keep a Render free web service from sleeping by sending it inbound traffic at least once every fifteen minutes, because Render spins down any free web service that goes fifteen minutes without receiving an HTTP request or a WebSocket message. The technique works. What most guides leave out is that it consumes your workspace's monthly free instance hours at roughly the same rate as simply running the service, and that one obvious URL to ping will not wake anything at all.

This article covers exactly what triggers the spin-down, the arithmetic that decides whether keeping a service awake is worth doing, the one endpoint that silently fails as a keep-alive target, and the trade-offs Render's own documentation is refreshingly direct about.

What triggers the spin-down, precisely

Render's documentation for its free tier is unusually specific. A free web service spins down when it goes fifteen minutes without receiving any inbound traffic, and inbound traffic means both HTTP requests and WebSocket messages from existing connections. It spins back up when it next receives an HTTP request or a new WebSocket connection, and that process takes about one minute. While the service is coming back, Render shows a loading page to connecting browsers rather than leaving them staring at a blank tab.

Two consequences follow that people discover the hard way. The first is that the filesystem is ephemeral, so any change written to local disk is lost every time the service spins down, restarts, or redeploys. An uploaded image or a local SQLite file does not survive the nap. The second is that Render reserves the right to restart a free web service at any time, which means even a service kept permanently awake is not a service that is permanently running. Free tier is free tier, and the documentation does not pretend otherwise.

The robots.txt trap

Here is the detail that breaks keep-alive setups quietly. While a free web service is spun down, Render intercepts requests to the path for robots.txt and returns a standard disallow-all response itself. Those requests never reach your service and never trigger a spin-up. While the service is awake, the same path routes through to your application normally, which is what makes the behaviour so confusing to debug.

The practical effect is that anyone who configures a keep-alive job or an uptime check against that path has built something that appears to work perfectly. The request returns a valid response every time, the check reports the service healthy, and the service sleeps anyway. If you are pinging Render to prevent spin-down, point the ping at a real route your application serves, ideally a lightweight health endpoint that returns a small body without touching the database. The same applies to any external monitoring you configure against a free service.

The arithmetic that decides it

Render grants seven hundred and fifty free instance hours per workspace per calendar month, shared across the workspace rather than allocated per service. Exhausting that pool suspends your free web services until the next month begins. A calendar month contains between seven hundred and twenty and seven hundred and forty four hours, which produces an uncomfortable result: keeping a single free web service awake around the clock consumes essentially the entire monthly allowance for the whole workspace.

That is the real cost of the ping, and it is not obvious from any tutorial. If you run one service and only need it responsive during business hours, a ping scheduled from eight in the morning to eight at night uses roughly three hundred and seventy hours and leaves room to spare. If you run three free services and keep all three awake continuously, you will exhaust the pool inside the first fortnight and every one of them will be suspended for the rest of the month. The honest verdict is that keep-alive pinging is a good fit for a service that needs to be responsive during predictable hours, and a poor fit for anything that needs to be up all the time. For that, Render's answer is a paid instance, and it is the correct answer.

When the cold start is acceptable and when it is not

A one minute spin-up is a different problem depending on who is waiting. For a portfolio project, a hackathon demo, or an internal tool used a few times a day by people who know what it is, the delay is a curiosity. Render even softens it by showing a loading page rather than a timeout, which sets the expectation for a human visitor.

It is unacceptable in one specific situation that catches people repeatedly: when the free service is an API called by another service rather than by a browser. Machines do not read loading pages. A client with a thirty second timeout calling a backend that takes sixty seconds to wake will simply fail, and the failure will look like an outage rather than a cold start. If your free Render service sits behind a frontend, a mobile app, a webhook receiver, or a scheduled job somewhere else, the spin-down is not a cosmetic delay, it is an intermittent outage with a schedule you can predict. That is the point at which keeping it awake stops being an optimisation and becomes a workaround for hosting the wrong thing on the wrong plan.

Common mistakes in keeping a Render service awake

Pinging the robots.txt path. Render answers that path itself while the service is spun down, so the request never reaches your application and never wakes it. The check goes green and the service sleeps anyway.

Ignoring the instance hours. Seven hundred and fifty hours per workspace per month is barely more than one service running continuously. Keeping several free services awake exhausts the pool and suspends all of them until the month resets.

Pinging an expensive endpoint. A keep-alive request that hits the homepage, runs database queries, and renders a full template does real work every fourteen minutes. Point it at a small health route that returns quickly and touches as little as possible.

Assuming awake means stable. Render can restart a free web service at any time, and the filesystem is ephemeral regardless. A service kept awake still loses anything written to local disk when it restarts.

Treating a machine client like a browser. The loading page during spin-up is for humans. An API consumer with a short timeout sees a failure, not a friendly wait, which turns a cold start into an outage for anything calling you programmatically.

FAQ

How long does a Render free service take to spin back up?

About one minute, according to Render's own documentation. Browsers connecting during that window see a Render loading page rather than an error, but programmatic clients with short timeouts will fail before the service is ready.

Does pinging a Render free service actually work?

Yes, as long as the ping reaches your application. Any HTTP request or new WebSocket connection resets the fifteen minute idle timer, but requests to the robots.txt path are answered by Render while the service is down and do not wake it.

How often should the keep-alive request run?

Anything under fifteen minutes prevents the spin-down, and every fourteen minutes is the common choice because it leaves a margin for a missed or delayed run without letting the idle timer expire.

Will keeping the service awake use up my free hours?

Yes. Free instance hours accrue whenever the service is running, so a permanently awake service consumes them continuously. Seven hundred and fifty hours per workspace per month is close to the length of a calendar month, so one always-on free service uses almost all of it.

Closing thought

Keeping a Render free service awake is a solved problem with an unadvertised price. The ping is trivial, the fifteen minute window is generous, and the whole technique falls apart if you aim it at the one path Render answers on your behalf. The question worth asking is not how to defeat the spin-down but whether the thing you are defending needs defending, because a service that genuinely cannot tolerate a one minute cold start has already outgrown the plan it is on.

Whichever way you go, the failure mode is the same: you find out from a user rather than from a dashboard. Odown checks the routes you choose from seventeen global locations, asserts on the response body rather than just the status code, and alerts through Slack, PagerDuty, or a webhook when a service that was answering in two hundred milliseconds starts taking a minute. If you are running anything on a free tier that other people depend on, website monitoring is the cheapest insurance available, and the same reasoning applies to platforms like Heroku where dynos sleep on a timer.