Why the bill is assembled rather than quoted
A Vercel Pro subscription is $20 per user per month, and that figure buys seats. Nearly everything your application does at runtime is metered separately on its own axis, each published on the pricing page in its own unit. None of it is concealed, but no single screen adds it up in advance, so the total is something you reconstruct afterwards rather than model beforehand. This checklist is that reconstruction, ordered by how much money each item typically moves.
1. Spend Management is a notification, not a brake
This is the item most often described incorrectly, so here it is in Vercel's own words. Spend management is configured by an Owner or Billing role under Team Settings, then Billing. The documentation is explicit: "Setting a spend amount does not automatically stop usage. If you want to pause all your projects at a certain amount, you must enable the option." Even with pausing on, Vercel notes that it "checks your metered resource usage" only "every few minutes", so "projects can keep serving traffic and accruing usage for several minutes after you cross the spend amount", and paused projects must each be resumed manually afterwards. Set the amount below the maximum you would actually tolerate, and enable pausing explicitly.
2. Build machines, where the platform picks your rate
Standard bills $0.014 per minute, Enhanced $0.028, Turbo $0.105, and the default Elastic tier $0.0035 per CPU minute across 4 to 30 vCPUs. Pin projects to Standard unless a measurement says otherwise, and check the team-level default separately from the project-level one.
3. Incremental static regeneration, billed in 8KB units
ISR writes start at $4 per million write units, and a write unit is 8KB of data written to the durable cache. That unit size is the part worth internalising: a large page is several units, and a large sitemap is hundreds. Vercel notes that reads and writes are priced regionally by your function region, that CDN cache reads are free while durable-storage reads and writes are not, and helpfully that "when revalidation runs and the content hasn't changed from the previous version, no ISR write units are incurred".
4. Image optimization, per thousand transformations
Image optimization starts at $0.05 per 1,000 transformations, with 5,000 a month included on Hobby. The cost tracks distinct source images and variants rather than page views, so a large catalogue with several breakpoints each is where this becomes material. If measurement shows no real gain in your loading metrics, the framework-level opt-out is a legitimate choice.
5 and 6. Two analytics products, two separate meters
Web Analytics is $3 per 100,000 events. Speed Insights is $10 per project per month, plus $0.65 per 10,000 events. Read that second one twice: the base charge is per project, so a team running many projects multiplies it by the number of projects rather than paying once. Both are per-project toggles, which means auditing them is a per-project job, and it is the single most common place teams find themselves paying for telemetry nobody has opened in months. We ran this audit on our own sixteen-project fleet in August 2026: both products were switched on for all sixteen projects, and nobody on the team remembered deliberately enabling a single one. Thirty-two toggles, zero decisions.
7. Fast Origin Transfer, per gigabyte from origin
Origin transfer starts at $0.06 per GB with 10GB a month included on Hobby. This is bytes leaving your origin rather than bytes leaving the CDN, so it is driven by cache misses rather than by visitors. Improving cache hit rates reduces it directly, which makes it one of the few line items where ordinary performance work and cost work are the same work.
8. Preview deployments bill like small production deployments
Every pull request preview consumes build minutes, and any regeneration or transfer it triggers meters normally. For a team with an active review culture this is a steady background cost that scales with diligence rather than with traffic. Limiting preview builds for documentation-only changes is the usual mitigation and costs nothing in review quality.
9. Function memory sizing, chosen once and inherited forever
Serverless function cost is a product of memory allocation and execution time, and the default sizing is set for the heaviest route rather than the typical one. Right-sizing after measuring actual usage is a one-time change with a permanent effect on every subsequent invocation.
10. Bot traffic is billed unless it is denied at the edge
Automated traffic consumes the same metered resources as human traffic. The distinction that matters for cost is where it is stopped: traffic rejected at the firewall layer never reaches the resources that bill, while traffic filtered inside application code has already consumed an invocation before your filter runs. If a meaningful share of your requests are automated, moving that rejection outward is the highest-leverage single change available.
The hour, in order
Enable spend management with pausing on. Pin build machines at team and project level. List projects and turn off both analytics products where nobody reads them. Check function memory against measured usage. Review revalidation intervals against how often content genuinely changes. Then look at your cache hit rate, because it moves origin transfer and ISR together. Most teams find the largest single number in items 1, 2 or 6, and all three are settings rather than engineering work.
Reader comments
No account needed. Share what worked, what did not, and what you would add.
Add a quick note with the form below. Short, specific tips help the next reader most.