The unit is 8KB, and that changes the intuition
Vercel prices incremental static regeneration writes from $4 per million write units, and defines a write unit as 8KB of data written to the durable ISR cache. Because the unit is small, a single page regeneration is rarely one unit, a substantial HTML page is several, and a large generated file such as a sitemap can be hundreds. Teams reasoning in pages consistently underestimate this, because the meter counts kilobytes and their mental model counts documents.
What is actually billed, and what is free
Vercel documents a two-level cache. The CDN cache in the requested region serves most traffic and its reads are explicitly free, but it is ephemeral, kept "on a best-effort basis, typically for minutes to hours". Behind it sits the durable ISR cache in your function region, and it is reads and writes against that durable layer which cost money. There is one genuinely useful piece of good news in the same documentation: "When revalidation runs and the content hasn't changed from the previous version, no ISR write units are incurred." A regeneration that produces identical output is not billed as a write.
The cause of unexpected writes that Vercel names explicitly
That last rule has a sharp edge, and the documentation states the diagnosis plainly. If you are seeing writes you cannot explain, "the content has changed between revalidations", and the debugging steps given are to check that you are not using new Date() in the ISR output, not using Math.random(), and that no other non-deterministic code is included in the output. This is the highest-value paragraph in the whole topic: a timestamp rendered into a page footer makes every single revalidation produce different bytes, which converts a free no-op into a billed write on every page, forever. Check for this before optimising anything else.
Lengthen intervals, or stop using intervals
Vercel's own two recommendations are to set a longer time-based revalidation interval for content that rarely changes, and to use on-demand revalidation instead of short intervals where you have events that signal an update. The second is strictly better whenever it is available: a page that regenerates because something actually changed is billing for real work, while a page regenerating every sixty seconds because nobody revisited the number is billing for a guess.
Prebuild what is genuinely static
A page rendered at build time is served from the deployment rather than regenerated into the durable cache, and Vercel notes separately that build output is not billed as ISR. For a large corpus of pages whose content changes rarely, generating them at build time shifts the cost from a recurring meter onto build minutes billed once per deploy at the rates covered in the build machine guide. The trade is a longer build, and on the cheaper machine tiers that trade is usually favourable, which is the counter-intuitive conclusion worth stating plainly: a slower build that pre-renders everything can be cheaper than a fast build that regenerates forever.
Find the pages doing this to you
Vercel exposes a Write Utilization metric on the ISR Observability page for teams with Observability+, described as showing the number of requests served per ISR write. That ratio is the diagnostic you want: a page regenerating frequently while serving few requests per regeneration is paying for freshness nobody is consuming. Sort by it, and the worst offenders are usually a small handful of routes rather than a systemic problem.
Set the function region deliberately
Because ISR reads and writes are priced regionally against your project's function region, that setting is a cost decision as well as a latency one. Vercel advises setting the default function region close to your data sources to reduce latency on cache misses and revalidation. Check what yours is set to; on projects that have been migrated or cloned it is frequently inherited rather than chosen.
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.