---
title: "The Monitoring I Already Had Was Keeping the Database Awake and Billing"
canonical: https://dxdev.com/everyday-ai/the-alarm-that-kept-the-database-awake/
datePublished: 2026-10-19
---
The database went down and I did not know. That was the worst part. It was completely down, and the only reason I found out was an email from the company that hosts it, warning me about the problem. They told me before my own setup did.

On 10/16/26 the host paused the database because it had passed a free-plan limit. The cause was one of our automatic jobs, which had been saving the same information over and over until the plan's monthly allowance ran out. If you want the technical version of that day, it is in [this write-up](/blog/free-plan-cap-hit-by-a-sync-that-rewrote-itself/).

## The obvious fix

What was needed was better monitoring, so I would not have to hear about an outage from the hosting company.

It had to be smart monitoring, too, the kind that is not going to chew up any of my resources.

## What I had not thought about

A few days later we audited the scheduled jobs for a second database, on a different project. That one had used up its free allowance for the month as well.

Two things were doing it. One was a status checker that visited a page every 10 minutes to make sure the site was up. The other was a sync that ran every 15 minutes to keep the accounting pages current.

Both reached the database each time they ran.

## Why that matters

I did not realize that the database sleeping was an issue. It was not on my mind as a limit at all. I am used to working on dedicated servers, where an idle machine that gets checked on all the time costs nothing extra, so I never thought about how often I asked.

This kind of database works differently. It only costs money while it is awake, and it goes to sleep when nothing has connected for a while. Every check wakes it up, and it stays awake for at least five minutes afterward. Our own rough estimate, not a measurement, is at least 8 awake hours a day from the 15-minute sync alone. The monitoring I already had was part of what kept it awake and billing.

That was one more surprise for me. The habit I brought from always-on servers simply did not carry over.

## What we did

On the afternoon of 10/19/26 we turned off the status checker at about 1:18 pm and the sync at about 1:37 pm. The plan for the sync is to run it only when someone opens the page that needs it, and to say "updating in background" while it works. That part is not built yet. Until it is, the accounting pages do not update on their own, and a person runs the sync by hand when it is needed.

For the status check, the plan is a check that never asks the database anything at all.

We filed three dated follow-ups: usage checks on 10/20/26 and 10/22/26, and a switch back to the free plan on 11/1/26. Falling usage is the only proof the database is finally sleeping. We have not measured the result yet, so I am not going to claim a saving.

## What a person still decides

A computer will run a check on a timer forever. It will not ask whether the timer is worth it. That question is still a person's: how often do I need to know, and what does each look cost?

## What to take from it

Before you add a check, a sync or a reminder, ask what it costs each time it runs. If you are used to services that cost the same whether you use them or not, do not assume the new one works that way. The technical details of this second story are in [this write-up](/blog/monitoring-kept-the-database-awake/).

The checker ran every 10 minutes and the sync every 15, and both woke the database each time. Both were off by about 1:37 pm on 10/19/26, and the dated usage checks we filed will tell us whether the database finally sleeps.