Vercel: what is left to save

Vercel charges us for the minutes it spends building the site. I measured every build over four and a half days — 6,000 of them — and split the bill by what each build was for. (A second, account-wide read taken a couple of minutes later caught four more, which is why 6,004 appears further down; both readings are listed as they came back rather than rounded to agree.)

Source: Vercel deployments interface, every deployment created between 2026-10-07 07:02 and 2026-10-11 14:36 UTC (103.7 hours). Each build's cost comes from the time it actually spent building, priced at the rate on our own Vercel billing record ($0.0035 per processor-minute × 8 processors). A further 28 builds in the window failed outright or were blocked and sit in no group; they are the remaining ~$0.13/day of the $37.07/day figure from the 2026-10-09 billing day.

I checked this rather than taking it on trust

The two people doing those fixes estimated their own savings at roughly $14/day and roughly $11/day. I measured both independently from the build records and got $14.67 and $11.73 — they were right, slightly conservatively so. The two are not double-counted: they are separate groups of builds, split by whether the build finished or was killed.

Two separate instruments agree on the total, which is why I trust the split. Adding up every build's own running time gives 1,425 minutes of building a day. Working backwards instead from the billing record's processor-minutes for 2026-10-09 gives about 1,330. Those are two independent readings about 7% apart, over slightly different periods — close enough to confirm each other, and neither is derived from the other.

The site runs 45 scheduled background jobs — checking for new listings, sending lease notices, and so on. Two of them run every single minute, 1,440 times a day each. That sounds expensive and it was the obvious place to look.

It is not expensive. On our last complete Vercel invoice, everything the running site does — every scheduled job and every page a person loads — came to $20.89 for the whole month, against $260.68 for building the site. Building is 72% of the bill; running it is under 6%.

$20.89 a month is 69¢ a day, and that is a ceiling, not an estimate — it covers far more than the scheduled jobs. The jobs are only 8% of all the site's activity, so their true share is well below it.

One honest caveat. That invoice covers 14 August to 14 September, and the job list has grown since: 31 jobs in mid-August, 40 in mid-September, 45 today — including a second every-minute job added after the invoice closed. Scaling the ceiling up for that growth gives about $1/day. The conclusion survives either way: deleting all 45 jobs would recover around one day in fifteen of the target, and would risk missing real work.

Sources: vercel.json in the propflowai repo — 45 schedule entries, counted from the file (my brief said 46; corrected). Job counts at earlier dates read from the same file's history. Invoice line items from Vercel's invoices interface, invoice 2SKBK8W2-0010: building the site $260.68, running the site $14.01 + $5.97 + $0.91, total bill $363.05. Scheduled jobs were 143,894 of 1,736,153 total requests that month.

Our build is set to give up after 20 minutes. It has never had to. Across all 6,042 builds in the window the longest took 16.7 minutes, and a typical production build takes 4.6 minutes. Only two builds went over ten minutes.

So the limit wastes nothing. Worth knowing, though, that the single worst build came within 3.3 minutes of being killed by it — that is a reliability thing to keep an eye on, not money. That build was a test copy, not a production deploy.

Source: build start and finish times from the same deployments pull. The limit is timeout 1200 in vercel.json.

Our Vercel bill covers the whole account, not just the main site, so I checked whether anything else was quietly burning money. It is not. Of 6,042 builds across the account, 6,004 were the main site. One other project — the AppFolio browser helper — accounted for 38 builds and 22¢/day. The remaining 18 projects built nothing at all; 16 of them have not been touched in over a month, and 8 have never been deployed.

I checked this sweep for blindness. It did find the AppFolio helper's 38 builds, so it can see projects other than the main site — the zero for the other 18 is a real zero, not a broken query.

Two other projects also carry scheduled background jobs — the AppFolio helper two, the Camellia site one. Both have deployed within the last two weeks, so neither is abandoned, and per the figures above their jobs are worth pennies.

Nothing else creates builds: the main site has no deploy hooks set up, so builds come only from code pushes and from the deploy itself.

Source: Vercel projects interface (20 projects) and an account-wide deployments pull over the same window.

Every time we ship to production, Vercel starts a build on its own, our script kills it about 21 seconds later, and then the real deploy is created properly. That happened 346 times against 343 real deploys — one wasted starter for every real one. It costs 78¢/day.

Killing a build that was never going to ship anything adds no delay to the deploy, so this is in bounds. It is also under a dollar a day and it sits in the deploy wiring, which is a poor trade. It may already be covered by the second fix in flight, which is removing the same kind of waste on the other branches. That is a question for whoever owns that fix, not a new piece of work.

Source: all 346 are on the production branch, 1:1 with the 343 real deploys. Mechanism confirmed in scripts/vercel-ignore.sh, which skips automatic builds on that branch so the deploy can be created deliberately afterwards.

• The cost of each individual scheduled job. Vercel's usage interfaces all refused this access token — five different ones tried, all returned "not found". So I could not break the running-the-site cost down job by job. I did not need to: the whole-category ceiling above already answers whether it is worth touching, and it comes from a real invoice rather than an estimate.
• This month's running-the-site cost. The invoice for the current period has not been issued yet, so the 14 August – 14 September invoice is the most recent complete one. Reported as unread, not estimated.