A status checker meant to watch a site was waking that site’s database every 10 minutes. The database is a serverless one, so it only costs compute while it is awake and goes to sleep when nothing has connected for a while.
In October a second project used up its free allowance of 100 compute-unit hours for the month. The organization was on a paid plan by the time we audited the scheduled jobs on 10/19.
Why a poll costs money
On a serverless database every poll wakes the compute and bills hours.
What kept it awake
The database was capped at 0.25 compute units, with a 300-second suspend timeout. Any job that opens a connection keeps the compute awake and billing. Two scheduled jobs did exactly that.
The first was a status checker on a personal test machine, running every 10 minutes. It loaded a public homepage, and that page queried the database on every load. So the thing built to watch the site was also the traffic that kept the database awake. The checker was broken as well: it compared against an old server IP.
The second was a ledger sync timer on the server, on a 15-minute cycle. That is 96 runs a day, and each run woke the database for at least five minutes. Our own back-of-envelope figure, not a measurement, is at least 8 awake hours a day from the sync alone, or roughly 2 compute-unit hours a day at 0.25 units.
What we turned off
On 10/19 at about 13:18 ET the status checker was switched off. At about 13:37 ET the sync timer was disabled. These two shutdowns are the primary fix, and both happened the same afternoon. The direction for the sync is to run it only on demand, when someone opens the review page, with an “updating in background” note while it works.
That part is not built yet. Until it ships, the accounting pages do not update on their own, and a manual run is the workaround. The plan for the status check is a route that does not touch the database at all, running on the venture’s own server instead of a personal machine.
Letting it sleep
The other half of the answer is to hit the database less, so it can sleep more. Public pages (the home page, the events list and each event page) now come from a cache instead of querying the database on every visit. A visit served from the cache does not wake it.
The cache clears when an event is edited or a ticket sells. A small follow-up fix covered free registrations. The change went through an outside review before it was merged.
We have no settled figure for what this does to database transactions per visit, so we are not claiming a number. The cache is the secondary change. The shutdowns above are the separate, primary fix.
What the follow-ups look like
We filed three dated follow-ups: a day-1 usage check on 10/20, a day-3 check on 10/22, and a switch back to the free plan on 11/1.
What to take from it
Monitoring and sync jobs that touch a serverless database are not free, because each one wakes it and keeps it billing. Count them as load before you add them, and point health checks at a route that never reaches the database.
Two jobs, a 10-minute checker and a 15-minute sync, are off as of 10/19. The day-1 and day-3 usage checks are filed.
AI Skills
Use this lesson with the AI assistant you already use
A second project at a partner venture used up its free 100 compute-unit hours in October, and an audit on 2026-10-19 found two scheduled jobs were connecting to its serverless database all day. The database was capped at 0.25 compute units with a 300-second suspend timeout, so each connection kept it awake for at least five minutes.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
The prompt works in any AI assistant as it is. We are also building a /dxdev skill for visual reports and saved memory.
It is not released yet: see what you can use today.
dxdev LESSON · paste into your AI coding agent
LESSON: Count Monitoring And Sync Jobs As Load On A Serverless Database Because Each Connection Wakes It And Keeps It Billing
SOURCE: dxdev.com/blog/monitoring-kept-the-database-awake
WHAT HAPPENED: A status checker on a personal test machine loaded a public homepage every 10 minutes, and that page queried the database on every load, so each check woke it. A ledger sync timer on the server ran on a 15-minute cycle, which is 96 runs a day. Our own rough estimate, not a measurement, was at least 8 awake hours a day from the sync alone, or about 2 compute-unit hours a day. On 2026-10-19 the status checker was switched off at about 13:18 ET and the sync timer was disabled at about 13:37 ET. The sync is meant to move to on-demand runs when someone opens the review page, but that is not built yet, so a manual run is the workaround. Public pages were also put behind a cache that clears on edits and ticket sales, though its effect on database transactions is not measured yet. Three dated follow-up checks were filed, since falling compute hours are the only proof the database is sleeping.
THE RULE: Treat every monitoring or sync job that connects to a serverless database as load, because each connection wakes it and keeps it billing for the full suspend timeout. Point health checks at a route that never reaches the database, and confirm the effect by watching usage fall.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. List every scheduled job, monitor, and timer that opens a connection to the database, and compare each one's interval against the suspend timeout to see whether the database can ever sleep.
2. Confirm that each health check hits a route that does not query the database, by reading the handler code rather than trusting a ticket's description.
3. Schedule dated usage reviews after any change and verify that compute hours actually dropped, rather than assuming the fix worked.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.
