Build1 publisher3 min readPublished
A keep-alive cron burned a month of Render free hours in ten days
A cron built to defeat Render's 15-minute spin-down spent the workspace's shared machine-hour budget in about ten days, and the suspension that followed took production and staging down together.
The Engineer · Build desk
What happened
- Render emailed the developer at 9 PM on September 10, 2026 to say his production services were suspended, and a shared identity service, a product API and a transactional email service went down together.
- The free allowance is 750 instance-hours a month across an entire workspace, shared by every free service in it, while a calendar month runs about 730 hours.
- A cron job pinging every service every five minutes kept all four free instances, production and staging for two services, awake around the clock.
- Neon then emailed to say he had reached 80 percent of the free plan's 100 compute-unit hours, and the cause was a pool setting holding one connection open against a database that sleeps when idle.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure Because suspension applies to the whole workspace, the staging copy dies with production, and there is no surviving environment in which to test the fix that brings the app back.
- constraint The plan can fund one always-on service and no more, so a product that needs two services answering fast has to buy compute or accept the cold start on both.
- decision Pool defaults have to be re-read against the database's billing model, because the setting that costs nothing on a rented box is a full-time compute bill when the database sleeps.
- cost A client with the platform hostname compiled in can only be pointed at new servers by shipping another build, so recovery runs through the app store instead of through DNS.
Render's free services sleep after about 15 minutes of inactivity, and the first request after that pays 30 to 60 seconds of cold start [5]. For 20 testers in a closed track that is a product problem, and the post describes a landlord waiting 40 seconds and deciding the app is broken [6]. Pinging the service every five minutes removes the wait, and every wake-up it buys is metered against the workspace's instance-hour allowance [2].
One service held awake for a whole calendar month takes 97.3 percent of that allowance [1]. Four of them, production and staging for two services, cost 96 instance-hours a day, and 750 divided by 96 is about 7.8 days [8]. The suspension email arrived at roughly day ten, because the cron missed some services on some passes [9]. Spread 750 hours across ten days and the average is 75 instance-hours a day, so the cron was landing about 78 percent of the wake-ups it was aiming for [2].
The allowance is counted per workspace and the penalty is applied the same way. When the hours run out, Render suspends every free service in the workspace, staging alongside production [10]. The post's rule for this is short: "before you defeat a platform's idle timeout, check what the idle timeout is paying for" [11].
Neon's meter ran on its own. The culprit was one line in a connection pool struct written weeks earlier and not looked at since: `min_connections: 1`, sitting next to `max_connections: 10` and a 600-second idle timeout [13]. That setting keeps one connection open so the first request after a quiet period skips the TCP handshake and TLS negotiation, and on a rented Postgres box it costs nothing [14]. On a database that scales to zero, the open connection is what keeps the compute awake, and the post reports it can nearly double usage at no traffic [15]. The value that works there is 0 [16].
Those numbers transfer only if your platform counts machine-hours across a workspace rather than a service, suspends at the workspace level, and holds everything you run. The setup here is three Rust backend services with staging copies, Postgres on Neon's free plan, and a React Native and Expo app in Play Store closed testing, all free tier in one workspace [17]. The published text does not say what happens when a paid service shares the workspace with free ones.
Item four on the post's list is about the client: never bake a platform's URL into a mobile app, and use a domain you own so servers can move without a new build [18]. Version 1.2.0 went to the Play Store at 5 AM on September 11, eight hours after the suspension email [19][3].
What to watch
- Whether Render's free plan keeps the 750-hour allowance scoped to the workspace or moves metering to the individual service.
- Whether the developer publishes Neon compute-unit usage after switching the pool to min_connections: 0.
- Whether a later Play Store build moves the app off the platform hostname onto a domain the developer controls.