A high Vercel bill on a Next.js site usually isn't caused by real visitors. It comes from a handful of usage meters: pages that render on the server for every request, image optimisation churning out dozens of variants, short ISR timers rewriting the cache, and bots crawling URLs that aren't cached. Vercel Pro is $20 a month with $20 of usage credit, so everything above that is on-demand usage, and most of it can be cut by fixing caching, images and bot traffic without changing host. Only move Next.js to Cloudflare if the bill is still high after that and your site is mostly content.
I build and deploy Next.js sites on Vercel or Cloudflare. This is the order I'd work through when a Vercel bill keeps creeping up month after month.
$20
Vercel Pro per month, including $20 of usage credit
$200
Default on-demand budget for new teams before alerts
32
Cached variants one hero image can create
$4
Pro rate per 1M ISR writes, 10x the read rate
What actually drives a Vercel bill on a Next.js site?
A Vercel bill is driven by separate on-demand meters (function invocations, compute, image transformations, ISR reads and writes, and data transfer) that start charging once the $20 Pro credit runs out. They're what turn a $20 plan into an invoice ten times that size.
Vercel Pro is $20 a month and includes $20 of usage credit. After that, you pay as you go. These are the meters that matter for a typical marketing site or SaaS front end, with Vercel's starting Pro rates (some vary by region):
| Cost driver | Vercel meter | Starting Pro rate | What usually causes it |
|---|---|---|---|
| Function calls | Function Invocations | $0.60 per 1M | Pages rendered on every request, API routes, middleware |
| Function compute | Fluid Active CPU, Provisioned Memory | $0.128 per CPU hour, $0.0106 per GB-hour | Slow data fetching, heavy server work, no caching |
| Image optimisation | Image transformations | $0.05 per 1,000 | Too many widths, formats and quality levels; huge source images |
| ISR revalidation | ISR reads and writes | $0.40 per 1M reads, $4 per 1M writes | revalidate timers of a few seconds across thousands of pages |
| Bandwidth | Fast Data Transfer, Fast Origin Transfer | Origin transfer from $0.06 per GB | Videos and large files served from /public, uncompressed assets |
| Bot traffic | All of the above | Same rates | AI crawlers and scrapers hitting dynamic and image URLs |
One line in Vercel's pricing FAQ is worth reading twice: if a response is cached, the function doesn't run, so you aren't charged for an invocation or compute time. Nearly every fix below comes back to that.
How do I find out what is costing me money?
Open the Usage tab in the Vercel dashboard, sort by cost, and trace the top meter back to the routes, functions or image URLs behind it. Don't guess. Spend twenty minutes in the dashboard before you touch any code.
- 1
Open Usage and sort by cost
In the Vercel dashboard, open the Usage tab for your team and see which meter and which project account for most of the spend.
- 2
Find the paths behind it
Use Observability to see which routes, functions or image URLs get the most requests. Bots and one or two pages are often most of it.
- 3
Check it day by day
Look at the usage charts in the dashboard day by day. A single spike suggests a bot or attack; a steady climb suggests a code or caching problem.
- 4
Set a hard limit today
Turn on Spend Management with an amount you can live with and enable pausing, so next month can't surprise you while you fix things.
A note on that last step. New Vercel teams get a default on-demand budget of $200 with email, web and SMS alerts. But the Spend Management docs say plainly that a spend amount on its own doesn't stop usage. You also need Pause Production Deployments turned on. Pausing takes your site offline, so set the amount high enough that it only trips when usage has genuinely run away.
How do I reduce my Vercel bill?
Cache pages that don't need to be dynamic, block the bots you don't want, limit image variants, replace short ISR timers with on-demand revalidation, and narrow your middleware. How much each one saves depends on where your spend sits. The table shows the order I'd typically work through them, not a measured ranking, so treat it as a starting point:
| Rank | Fix | Meters it cuts | Effort |
|---|---|---|---|
| 1 | Cache pages that don't need to be dynamic | Invocations, CPU, memory | Low to medium |
| 2 | Block or rate-limit unwanted bots | Everything downstream | Low |
| 3 | Limit image widths, formats and quality | Image transformations, cache writes | Low |
| 4 | Swap short ISR timers for on-demand revalidation | ISR writes, compute | Medium |
| 5 | Narrow middleware and move heavy media off Vercel | Invocations, bandwidth | Low |
One agency's published case study reports a 35% cut in a client's Vercel bill from code-level changes like these, without changing host. Yours will depend on where the money is going.
1. Stop pages rendering on every request
This is the usual culprit. In the Next.js App Router, a page turns dynamic when it reads cookies() or headers(), uses searchParams, makes a fetch with cache: 'no-store', or has an export const dynamic = 'force-dynamic' that someone added to make a bug go away. From then on, every visit runs a function.
Make marketing pages, blog posts and pricing pages static or cached, and keep dynamic rendering for logged-in screens. If you want personalisation like a geo banner or an A/B test, put it in a small client component so the whole page doesn't need the server. next build marks each route as static or dynamic when it runs. Any marketing route showing as dynamic deserves a hard look.
Fluid compute helps too. Vercel says its in-function concurrency has cut costs by up to 85% for some teams. Older projects don't always have it on, so check.
2. Block or rate-limit the bots you don't want
Crawlers don't stay on your popular pages. They hit every URL, every image size and every query string variation, and a lot of those requests miss the cache. Vercel's firewall has an AI Bots managed ruleset and a Bot Protection ruleset, and Vercel adds new AI bots to its managed list as they show up. One trap: the Block AI Bots template defaults to logging only. It blocks nothing until you set it to Deny.
Don't block everything, though. Some AI crawlers send you visitors and citations, and shutting them all out can cost you visibility in ChatGPT and Google AI Overviews. My free AI Crawler Checker shows which of 14 AI crawlers your robots.txt currently allows. Robots.txt only stops bots that choose to obey it, so back it up with Vercel firewall rules. For aggressive scrapers, a rate-limit rule costs from $0.50 per million allowed requests.
3. Cut image transformations
Next.js image optimisation is good for Core Web Vitals, but every combination of width, format and quality is a separate billed transformation. Vercel's own guide shows that one hero image in 2 formats, 2 qualities and 8 widths can create up to 32 cache entries. The same guide suggests:
- Trim
deviceSizesandimageSizesto the widths your layout actually uses, and set accuratesizeson each<Image>. - Allow one quality level and one modern format unless you have a reason to need more.
- Raise
minimumCacheTTLso cached variants aren't regenerated as often. - Set
unoptimizedon logos, icons, GIFs and files under 10 KB. Do it per image, not site-wide, because switching it off everywhere can hurt LCP. - Lock down
remotePatternsso nobody can use your optimiser for images on other domains.
If you're not sure how your images affect LCP, paste your PageSpeed Insights report into my free Page Speed Fix Planner before you change image settings.
Resize huge originals before upload as well, so a 4,000-pixel designer export isn't the source for every variant. I built Under1MB, a free in-browser image compressor, for exactly this kind of pre-compression.
4. Swap short ISR timers for on-demand revalidation
On Vercel Pro, ISR writes cost ten times as much as reads: $4 against $0.40 per million. Put revalidate: 10 on a few thousand product or blog pages, let bots crawl all of them, and you get constant regeneration. Each regeneration is a function run on top.
Set long timers instead (hours, or a day) and call revalidateTag or revalidatePath from a CMS webhook when content actually changes. Editors still see updates within seconds, and you stop paying to rebuild pages nobody touched.
5. Narrow middleware and move heavy media off Vercel
Next.js middleware (called proxy in Next.js 16) runs before every request it matches. If its matcher covers _next/static, images and fonts, every asset request turns into compute. Limit it to the routes that need it.
For bandwidth, product videos and big PDFs served from /public add up fast. Host video on a proper video service and keep only lightweight assets in the repo.
Is Vercel's Flat Rate CDN worth turning on?
Only if most of your bill is CDN requests and data transfer rather than functions, images or ISR. If that's your situation, look at Flat Rate CDN before you think about moving.
Vercel Pro already includes a base tier of CDN requests and data transfer, and paid tiers add more capacity for a fixed monthly fee. Check Vercel's docs for the current tier prices, allowances and what happens when you go over your tier, because those decide whether it beats on-demand pricing for your traffic.
The catch: Flat Rate CDN covers CDN requests and data transfer, not function compute, image transformations or ISR. If those are your problem, it won't help and you're back to the fixes above.
When is moving Next.js from Vercel to Cloudflare worth it?
When the bill stays high after you've fixed caching, bots, images and ISR, and the site is mostly content with a lot of traffic. If the bill is already close to Vercel's $20 base, a migration won't pay back.
Next.js runs on Cloudflare Workers with the OpenNext adapter. Cloudflare charges mainly for requests and CPU time rather than data transfer (check current Workers pricing), which is why sites with lots of traffic and little server work often come out cheaper there. I compare the two properly in Vercel vs Cloudflare for Next.js. The short version:
| Situation | Stay on Vercel | Move to Cloudflare |
|---|---|---|
| Bill is near the $20 base after the fixes | Yes, a migration won't pay back | No |
| Bill is mostly CDN requests and bandwidth | Try Flat Rate CDN first | Worth pricing out |
| Mostly static or content site with high traffic | Fine if costs are stable | Often cheaper |
| Heavy use of ISR, Vercel image optimisation, preview workflows | Easier and lower risk | Needs testing and replacements |
| Node-only libraries or long-running server tasks | Better fit | Check compatibility first |
| Team relies on Vercel previews and its dashboard | Keeps the workflow | Expect some workflow changes |
My rule is simple: fix the code first, then decide. If you move a site that renders every page on demand, you've just taken the same waste to a cheaper host. And the migration isn't free. Someone has to test every route, replace Vercel image optimisation with a Cloudflare loader, check redirects and watch Google Search Console after the switch. It makes sense when the bill is high for structural reasons, not because of bugs.
What should I ask a developer before they touch it?
Ask which Vercel meter is driving the bill and how they confirmed it, before they change any code or hosts. Their answers will tell you whether they've actually read your usage breakdown:
- Which meter is behind most of the bill, and how did you confirm it?
- Which routes are dynamic now, and which will be static or cached after your changes?
- How will content editors see updates if we lengthen the revalidation times?
- Which bots will you block, and which AI crawlers will you keep allowed?
- What will you check after the change so Core Web Vitals and rankings don't slip?
- If we move host, how do DNS, redirects and rollback work?
If someone's only answer is to switch hosts and they haven't opened your Usage tab, get a second opinion.
How do I stop the bill creeping back up?
Keep a spend cap with pausing on, and check the Usage tab every month. Bills creep back as the site changes: someone adds a dynamic page, an image-heavy section, or a new crawler finds you. The cap stops the shock, but you still have to fix whatever caused it.
The cheapest protection is a monthly look at the Usage tab, done alongside dependency updates and a Core Web Vitals check. That's the job of a maintenance retainer, and I cover what one usually includes and costs in Next.js website maintenance cost.
If your Vercel bill has jumped and you want someone to find the cause, fix it and keep an eye on it each month, have a look at my Next.js and React websites service and my hosting, migration and maintenance retainers, or book a 20-minute call. Send a screenshot of your Usage tab before we talk and I'll tell you on the call which of these fixes applies to you.
