🚢 #BuildInPublic for the RevenueCat Shipaton 2026. RentDera is my Shipaton entry, and I'm sharing the whole journey — the wins and the 5 AM disasters like this one. This is one chapter of that trail.
At 9 PM on September 10th, 2026, Render emailed me to say my production services had been suspended.
In between was the worst night of this project so far — and it was entirely my own doing. Three separate mistakes, each individually reasonable, stacked into an outage that took down a shared identity service, a product API, and a mail service at once.
The 30-second version (if you only read this far) Free tiers are metered. Render gives ~750 machine-hours/month across a workspace; a month is ~730 hours. Keeping one service awake 24/7 eats almost the entire budget. A keep-alive cron is a trap. Pinging services to stop them sleeping doesn't outsmart the platform — it just spends the free quota faster, and then everything gets suspended. On a serverless database, minconnections: 0 is mandatory. One idle connection held open keeps the database awake 24/7 and can nearly double your usage at zero traffic. Never bake a platform's URL into a mobile app. Use a domain you own, so you can move servers without shipping a new app build.
If you're new to this, don't worry — I explain every term below in plain language.
Jargon, in one line each: Free tier = the no-cost plan, with usage caps. · Cold start / spin-down = a sleeping server takes a few seconds to wake. · Cron job = a task on a timer. · Connection pool = a small set of reusable database connections. · Serverless / scale-to-zero database = a database that sleeps when idle and bills by the second. · Compute Unit (CU) = Neon's unit of database processing time. · Hostname / subdomain = the address in a URL, like auth.notils.com.
I'm a solo developer. The stack is deliberately cheap: Three Rust backend services — a shared identity service, a product API, and a transactional email service Postgres on Neon's free tier A React Native + Expo mobile app, in Play Store closed testing with 20 testers Everything on Render's free tier, in one workspace
Free tier everywhere. That was the point. There's no revenue yet, and 20 testers don't justify a hosting bill.
Render's free services spin down after ~15 minutes of inactivity. The next request pays a 30–60 second cold start.
For 20 testers, that's a genuine problem. A landlord opens the app, waits 40 seconds, and concludes the app is broken. So I did the obvious thing: a cron job pinging every service every 5 minutes to keep it awake.
Render's free allowance is 750 instance-hours per month, per workspace — shared across every free service in it.
Read those two numbers again. The free tier is sized so that one always-on service consumes the entire monthly allowance with 20 hours to spare. It is not sized for two. The spin-down isn't a defect you work around — it's the mechanism that makes the arithmetic work at all.
I had four services (production and staging for two of them), all pinned awake by my own cron:
Just under eight days to burn a month's allowance. Mine lasted about ten, because the cron didn't catch every service on every pass. Not much longer.
And when the allowance runs out, Render suspends every free service in the workspace. Not the greediest one. All of them. Staging and production together.
The lesson: before you defeat a platform's idle timeout, check what the idle timeout is paying for. If the free quota is smaller than a calendar month, sleeping is not optional — it's the business model.
Then Neon emailed me too. 100 compute-unit hours on the free plan, and I was at 80%.
This one took longer to find, because the culprit was four lines in a config struct I'd written weeks earlier and never looked at again: