A handful of hobby sites, no advertising, almost no visitors. The May 2026 invoice came to $272.16.
The actual invoices
| Month | Invoice | Note |
|---|---|---|
| April | $20.00 | base plan only |
| May | $272.16 | the blowout |
| June | $122.48 | coming down |
| July | $36.46 | |
| August | $49.71 | |
| Current | $34.09 | now |
Opening the $272 invoice
A total tells you nothing. So we opened that month line by line.
| Line item | Amount |
|---|---|
| Build Minutes | $219.74 |
| Build CPU Minutes | $43.49 |
| Function memory | $3.38 |
| Function CPU | $2.72 |
| Data transfer | $1.55 |
| Function invocations | $1.20 |
| Everything else | $0.06 |
Two build lines: $263.23. That is 96% of the invoice. Everything visitors could have caused came to under $10. Nobody showed up — we spent it ourselves.
I'll re-measure by line item.
thought a crowd showed up. it was us
First conclusion — and it was half wrong
Builds were the culprit, so the next question was why there were so many. Scheduled jobs were rebuilding sites whenever data changed. The conclusion: "we deploy too often".
That conclusion was published. The next day it turned out to be wrong.
The multiplication did not work out
We counted how many deploys actually happened and how long one takes.
- Deploys: 139 over 19 days
- Each build: 16 seconds
- Multiplied: about 37 minutes
The invoice said 68 hours. Thirty-seven minutes cannot become sixty-eight hours. Frequency was not the problem.
The arithmetic doesn't work. Looking again.
yesterday's conclusion was wrong. multiplying took five minutes
The real cause — one minute billed as thirty
Billing is not time alone. It is time × number of CPUs used. And the team default was pinned to the fastest machine — 30 cores.
The evidence was in the first line of every build log: "30 cores, 60 GB". Nobody read that line for four months.
What was fixed
- Switched the machine setting to automatic. Short builds now get a small machine. It dropped to 8 cores immediately: 145 won → 43 won per deploy.
- Cut the deploys too. Instead of rebuilding when numbers change, the data is published separately and read when the page opens. Updates land in 22 seconds with zero deploys.
- Lowered the spend limit from $200 to $50, with notifications on.
What this actually taught us
Two mistakes. First, we looked at the total. Until the line items were opened, traffic was the assumed cause.
Second, we stopped at a plausible cause. "Too many deploys" made sense, so it became the conclusion without being checked. Multiplying the numbers took five minutes, and skipping it cost a day of being wrong in public.
How to prepare, in order
1. Set a spend limit first. Most services have one, defaulted high or off. Ours sat at $200 — which is how May reached $272: passing a limit does nothing unless you also tell it to stop.
2. Read line items, not the total. One line was 96% of that invoice. The total would never have said so.
3. Check the unit price. Sometimes "how much per run" matters more than "how many runs". Changing one machine setting beat reducing frequency by threefold.
4. Say this out loud when delegating to an AI. An AI cannot see the bill. Ask only for "make it work" and you get the easiest implementation, which can also be the most expensive.
Where it stands
- $272 → $34, and next month should be lower — both the machine size and the deploy pattern were fixed.
- The limit is now $50, with notifications on.
- This site costs $1.04 a month, writing and deploying repeatedly.