The 30-Minute Timer That Took Down My Entire App

One morning, login on my app just stopped. Not slow, not flaky. Every single sign-in came back with Internal Server Error. Everyone, everywhere, locked out at once.

VoiceMeet Pro is live on the Play Store, with real users in eight countries and real money moving through it. So a dead login screen is not a look-at-it-after-coffee problem. You feel it in your stomach before you’ve even opened a terminal.

I want to walk through what actually happened, because the cause is the most 2026 kind of bug there is. Nothing crashed. Nothing threw an error on its way down. Something just ran, politely and on schedule, until it had quietly spent everything.

A database built to disappear

My app runs on Neon, a serverless Postgres. The whole pitch of serverless is that the database is allowed to sleep. When nothing is querying it, it scales to zero: the compute shuts off and it costs you nothing. The moment a query arrives, it wakes back up. You don’t pay for a server sitting idle. You pay for the compute you actually use, measured in compute-hours, and the free tier gives you a fixed budget of those each month.

Read that again, because the whole trap is hidden in it. The economics only work if the database spends most of its life asleep. A serverless database that never sleeps is just an expensive database with extra steps.

Mine never slept.

The background job that never stopped

One of VoiceMeet Pro’s features stamps recordings onto a blockchain, so there’s tamper-proof evidence a recording existed at a given moment. Good feature. It shipped with a background job whose only purpose was to wake up every so often and upgrade any pending proofs. Upgrading meant running a query against the database.

That job was set to fire every 30 minutes. Around the clock. Forever.

So a database designed to sleep most of the day was getting poked awake 48 times a day, every single day. At 4 a.m., with not a single human using the app, the job dutifully woke the database, ran its query, and held the compute open. Then again 30 minutes later. And again. It wasn’t a bug in the way we usually mean the word. It did exactly what it was told. What it was told was quietly ruinous.

  What a serverless DB is supposed to do        What mine actually did

   asleep:  ▁▁▁▁▁▁▁▁▁▁▁▁  (free)               ▇▁▇▁▇▁▇▁▇▁▇▁  (every 30 min)
   wakes on real traffic only                   48 wake-ups a day, nobody watching
   ─────────────────────────────                  ───────────────────────────────────
   compute budget lasts the month               budget drained → DB refuses
                                                connections → login down for all

Each wake-up nibbled at the monthly compute budget. Nobody was watching that number, because why would you. One morning it finished the budget off entirely. The database stopped accepting connections, and the very first thing every user hits, the login query, had nowhere to go. Internal Server Error, for the entire planet, because a timer wouldn’t let a sleepy database sleep.

The part that stung

I had flagged it. Earlier, I’d noticed my Neon usage looked far too high for an app my size, said so out loud, and asked for it to be looked into. The answer at the time never connected that warning to this job. The drain was sitting right there, on a 30-minute timer, hammering the exact resource I’d pointed at. It took the whole app going dark for anyone to finally join those two dots.

The fix, once we found it, was almost insulting:

// before — wakes the serverless DB 48x a day, forever
setInterval(() => upgradeAllPending(), 30 * 60 * 1000);

// after — these proofs take hours to confirm anyway, 4x a day is plenty
setInterval(() => upgradeAllPending(), 6 * 60 * 60 * 1000);

One number. Thirty minutes became six hours. Forty-eight wake-ups a day became four. The database went back to sleeping for most of its life, the compute budget went back to lasting the month, and the outage that felt like a catastrophe turned out to be a rounding error in a config file.

Why this kind of bug is going to get more common

This is worth naming, because it’s only going to get more common. We’re all moving onto infrastructure that bills by the second and scales to zero, and we’re handing more of the wiring to tools and AI that will happily set a timer or spin up a background job without ever feeling the invoice that follows.

The old failures were loud. The server crashed, the page threw a 500, you got paged. The new ones are quiet. Something runs perfectly, on schedule, doing exactly what it was told, and the only evidence is a usage graph nobody thought to watch.

A crash tells you where it hurts. A drain tells you nothing, until the bill does it for you, or in my case, the login screen.

So now I watch the boring number. Compute-hours. Wake-ups. The graph that has nothing to do with whether the code works and everything to do with whether the thing can survive a quiet Tuesday at 4 a.m. The code was never the problem here. The code did its job, perfectly, 48 times a day. That was the problem.

Written by Harsimrat Singh, the solo builder behind VoiceMeet Pro, a voice-meeting app shipped and maintained with AI, live on the Play Store. Field notes on what building on serverless actually feels like in 2026.