A client rang me on a Monday morning last year. Not a message. A phone call. That's never good. He'd deployed a Next.js marketing site on Vercel's Pro plan the previous Thursday, ran a product launch over the weekend, and woke up to a $340 invoice sitting in his inbox. The site had done brilliantly. Traffic spiked. And Vercel had quietly metered every gigabyte of data leaving their network. He had no spending cap set. No alert configured. Nothing.
That call is the reason I now spend twenty minutes on Vercel billing hygiene with every client before we deploy anything production-grade.
Here's what you need to understand about how Vercel charges for bandwidth, why it catches people off guard, and what to actually do about it.
---
What "Egress" Actually Means on Vercel
Egress is data transferred out of Vercel's network to the end user. Every image, every JavaScript bundle, every API response, every font file. If it leaves their edge and hits a browser, it counts.
On the Hobby plan you get 100GB of bandwidth per month, included. On Pro it's 1TB. Sounds like a lot. But here's the thing: if you're serving large images, doing server-side rendering on pages with heavy JSON payloads, or your app hits a sudden traffic spike, you can blow past 1TB faster than you'd think. Vercel charges $0.15 per GB of overage on Pro as of this writing (always check their current pricing page because this moves).
So 500GB over your limit is $75. Not catastrophic. But a viral moment, a botched image optimisation setup, or a scraper hammering your API routes? That can be thousands.
Why It Catches People Off Guard
The thing is, local development gives you zero indication. You build fast, deploy fast, it all feels fine. Vercel's dashboard shows bandwidth usage but it doesn't scream at you. If you haven't proactively set up a billing alert, you find out when the invoice arrives.
---
The Configs Most Likely to Wreck Your Bill
I've audited a lot of deployments at Seahawk. There are four culprits I see over and over.
1. Unoptimised Images Bypassing next/image
next/image is genuinely good at what it does. It resizes, converts to WebP, and caches. But I've seen projects where developers were pulling images straight from an <img> tag pointing at full-resolution files in an S3 bucket, proxied through a Vercel API route. Every request was pulling a 4MB JPEG through Vercel's network instead of a 200KB WebP from a CDN edge. Multiply that by 50,000 page views and do the maths.
Always use next/image with a proper remotePatterns config. If the image source is external, make sure it's hitting the CDN cache and not making a round trip through your serverless functions.
2. API Routes That Return Fat Payloads
Back in 2021 I built an e-commerce product catalogue for a UK retailer. Their API route was fetching a product listing from their database and returning the entire product object, including fields the front end never used. Description, internal SKU notes, variant metadata, the lot. Each response was around 80KB instead of the 12KB it needed to be.
Trim your API responses. Return only the fields the client actually consumes. If you're using something like Prisma, use select to limit what you pull. If you're using a third-party API, transform and slim the payload before sending it downstream.
3. ISR With Short Revalidation Windows on High-Traffic Routes
Incremental Static Regeneration is brilliant in theory. In practice, if you set revalidate: 30 on a page that gets 10,000 hits per minute, you're still caching correctly. But if you set it to revalidate: 1 because you wanted near-real-time updates and forgot to change it... you're basically doing SSR with extra steps and paying for the egress on every near-miss cache response.
Be deliberate about your revalidation windows. Most content does not need to revalidate every second.
4. Serverless Functions With No Caching Headers
This one is subtle. If your serverless function response doesn't include a Cache-Control header (or Vercel's s-maxage / stale-while-revalidate combo), the response is not cached at the edge. Every request hits the function and travels the full round trip. You lose the CDN benefit entirely and pay egress on every single response.
`` Cache-Control: s-maxage=3600, stale-while-revalidate=86400 ``
That header alone has saved clients real money. Seriously. Vercel's own caching docs explain the header behaviour in detail. Read them once properly.
---
How to Set Up Billing Alerts (Before You Need Them)
This should be step one before any production deploy. Not step seven.
- Go to your Vercel team settings.
- Under Billing , find Spend Management.
- Set a spend limit (hard cap, where Vercel stops serving requests after the limit) or a notification threshold (soft alert, emails you when you hit a number).
- I'd recommend setting a notification at 50% of what you'd consider painful, and a hard limit at about 120% of your expected monthly bill.
The hard cap is a two-edged thing. If you hit it, your site goes down. So think carefully. For a marketing site? Fine, cap it hard. For a SaaS with paying users? Set generous notifications and watch the dashboard instead.
---
Offloading the Heavy Stuff Elsewhere
Vercel is not a CDN for static assets. I mean, it has a CDN, but you're paying per gigabyte out of it. For high-volume static assets, put them somewhere cheaper.
I've been routing large media files through Cloudflare R2 for about eighteen months now. R2 has zero egress fees. You pay for storage and operations, not for the data going out. For image-heavy sites this is a serious saving. A client of mine runs a photography portfolio platform and was paying around $180/month in Vercel egress. We moved all the full-res images and gallery assets to R2, kept the thumbnails going through next/image, and the Vercel bill dropped to under $40.
Alternatives worth knowing:
- Cloudflare Pages for static deployments where you don't need Vercel's edge features. Generous free tier, no egress fees.
- AWS CloudFront in front of S3 if you're already in the AWS ecosystem. Transfer costs are lower than Vercel's overage rates at scale.
- BunnyCDN is cheap and fast for pure asset delivery. I've used it on a few high-traffic WordPress-to-Next.js migrations where the asset volume was large.
The point is: Vercel is the right place to run your Next.js application logic. It's not always the right place to serve your gigabytes of media.
---
Monitoring Usage in Real Time
Don't just check your dashboard at the end of the month. That's how my client ended up on the phone to me on a Monday.
A few things I actually use:
- Vercel Analytics gives you page-level data and is useful for spotting which routes are generating the most traffic (and therefore the most egress).
- Axiom integrates cleanly with Vercel's log drains and lets you query request size over time. I started using it in late 2022 and it's been useful on bigger projects for correlating traffic spikes with egress jumps.
- Set up a simple cron (Vercel has native cron support now) that hits their API and posts to a Slack channel when bandwidth crosses a threshold. I built a lightweight version of this for Seahawk's own infrastructure. Takes two hours, saves a lot of anxiety.
The Vercel REST API exposes deployment and usage data. It's not the most elegant API in the world but it does what you need for basic alerting.
---
The Architecture Decision Nobody Talks About
Here's something I don't see discussed enough: sometimes Vercel is the wrong default.
If your project is a static marketing site with no real dynamic functionality, you don't need Vercel. Cloudflare Pages or Netlify's free tier will do the job with zero egress concerns. You're not "wasting" Vercel, you're just not in the right tool for the workload.
Conversely, if you're building a proper Next.js app with edge middleware, server components, and API routes doing real work, Vercel is worth paying for. The DX is genuinely excellent and the edge network is fast. Just architect it properly from the start.
The mistake I made early in my career (around 2016, before Vercel was even a thing, back when I was figuring out deployment on Heroku and Netlify) was treating the deployment platform as a free afterthought. The platform choice shapes your cost profile as much as your database choice does. Take it seriously.
---
FAQ
Does the Hobby plan get egress charges if I go over 100GB?
No. On the Hobby plan Vercel doesn't charge overage; they throttle or suspend the deployment once you hit the limit. It's not great either way, but you won't get a surprise bill. The surprise bills happen on Pro and Enterprise where usage is metered above the included amount.
Is Vercel's image optimisation counted in egress?
Yes. Optimised images served through next/image still count as egress. The saving is in file size: you're serving a 180KB WebP instead of a 3MB JPEG, so the egress per image is much lower. The optimisation itself is what reduces the cost, not some special exemption.
Can I use a custom CDN in front of Vercel to reduce egress?
You can put Cloudflare's proxy in front of your Vercel deployment. Cloudflare caches responses at its edge, which means requests that hit Cloudflare's cache don't reach Vercel at all. This can significantly reduce both egress and function invocations. There are some caveats with preview deployments and header handling, but for production this is a common and legitimate approach. Cloudflare's documentation on proxying covers the setup.
What's the biggest single cause of unexpected Vercel bills?
In my experience: image handling. Either full-resolution images being served without optimisation, or image optimisation routes being called on every request without proper caching. Sort your image pipeline first, everything else second.
Does Vercel notify you automatically if usage spikes?
Not by default. You have to configure it. There's no out-of-the-box alert that says "you've used 80% of your bandwidth." That's the gap. Set your spend management thresholds the same day you set up your production deployment. Not later.
---
Vercel is a great platform. I use it, Seahawk uses it, and I'll keep recommending it for the right projects. But it's a metered service running on real infrastructure, and the pricing reflects that. The developers who get hurt by surprise bills are almost always the ones who treated it like a free CDN and never looked at the billing settings. Five minutes of configuration when you deploy will save you a very uncomfortable Monday morning phone call.