A $272 server bill — the cause was not visitors, it was deploys

Handing your sites to an AI is convenient. But an AI cannot see the bill. The invoice arrives at a human.

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

These are receipts, not estimates. And the important part is not the $272 — it is that nobody noticed while it was happening.

Finding the cause — it was not traffic

A spiking server bill usually means a traffic spike, so traffic was the first thing checked. It was not that. Data transfer had not used even 1% of the included allowance.

Broken down by line item, the answer appeared.

Line item	Charge	Share
Builds (running a deploy)	$20.90	61%
Function execution (scheduled jobs)	$8.51	25%
Transfer and the rest	$4.57	14%

Builds were six tenths of it. A build is the work of assembling code into an actual website. Every deploy costs money. A large site takes minutes to assemble, and those minutes are the bill.

I'll measure it again by line item.

thought a crowd showed up. it was us

The quietest site spent the most

Split by project, the surprise was that the culprit was not the complex site. It was the quiet one.

Site	Charge	Breakdown
the complex one	$18.37	jobs + builds + transfer, evenly
the quiet one	$14.57	99% builds
this site (appjip)	$1.04	a month of writing and many deploys

The quiet one served 7,820 requests in a month against an included allowance of ten million — effectively zero. And it ran 68 hours of builds.

Why: every time a scheduled job refreshed some numbers, it rebuilt the entire site. Several times a day. Re-erecting a building to change a few values. The site has many pages, so each rebuild was slow, and it added up.

So what was actually wrong

The code was not wrong and the site worked fine. The structure was the wrong choice.

Changing data was baked into the site → any change means rebuilding everything.
Had it been fetched at view time instead, changing values would require no rebuild at all.
The difference is invisible on screen. It only shows on the invoice.

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 exactly how May reached $272: passing a limit does nothing unless you also tell it to stop.

A limit gives you two choices: (a) notify only, or (b) pause the service when exceeded. (b) is certain but takes the site down. For anything other people use, (a) with a low limit is usually better. Ours went $200 → $50.

2. Read line items, not the total. A total tells you nothing about cause. Almost every provider shows what cost what. Only there did it become clear the culprit was builds, not traffic.

3. Count the things that run by themselves. Scheduled jobs, automatic redeploys — nobody presses a button, and they keep running after everyone forgets them. Pull up the list once a month and switch off what is not needed.

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 one.

Two questions worth adding: "How often will this redeploy?" and "Does a data change force a full rebuild?" Those two catch most of it.

Where it stands

$272 → $34. The quiet site's $14 of builds is still there; a structural change takes it near zero.
The limit is now $50, with notifications on.
This site costs $1.04 a month — writing and deploying repeatedly — because nothing here needs rebuilding when data changes.