The 11-hour image that cost us $6,500

TL;DR

One evening in November 2025, a single ~60 MB image on one customer page made our bandwidth bill jump 36× overnight. Vercel emailed us within minutes. We read the email about 11 hours later. By the time a firewall rule stopped it, the night had cost us about $6,500 — roughly $3,500 on Vercel and $3,000 on AWS. The customer whose page caused it was paying us $28 a month. That's about 19 years of their subscription, gone in one night.

This is the story of that night, why it got so expensive so fast, and what we changed so it can't happen the same way again.

What happened

Super turns Notion pages into websites. Customers put whatever they want into Notion — including images straight from a camera or a design tool.

On 13 November 2025, a customer published two campaign pages with a huge image (~60 MB) on them. The pages got traffic, as campaign pages do.

Normally that would be harmless: images go through the /_next/image route, which resizes them to sensible dimensions before they reach the visitor. This time it didn't. The route served the image at full size — so every page view meant pushing tens of megabytes through the CDN.

Requests didn't spike. Nothing looked like an attack. The number that exploded was Fast Data Transfer — the bytes leaving the edge — and that's exactly the line you pay for.

Timeline (CET)

• 13 Nov, 20:06 — Vercel's observability service sends an anomaly email: spend is way above normal.
• 13 Nov, ~20:30 — The email is seen… and not given proper attention. It looks like one of many automated notifications.
• Overnight — The image keeps being served at full size. The meter keeps running.
• 14 Nov, ~06:00 — Investigation starts. The dashboard shows ~36× the usual spend.
• 14 Nov, ~07:02 — The customer's site is blocked via the Vercel Firewall. The customer is contacted and asked to replace the image.
• 14 Nov, ~07:10 — Spend back to normal.

Total duration: ~11 hours. Total extra cost: ~$6,500.

Why it was so expensive

Three things lined up:

1. Bandwidth is the expensive part of a CDN. Requests are cheap; bytes aren't. One oversized asset multiplies the bytes of every single page view.
2. The safety net had a hole. The image optimizer is supposed to make the original file size irrelevant. When it passed the original through, nothing else capped it.
3. The alert worked — the humans didn't. Vercel told us about the problem within minutes. The fix took about an hour once someone looked. Almost all of the $6,500 was spent in the gap between those two moments.

The post mortem put it bluntly: "E-mail from Vercel was ignored — the main cause of the major problem."

What we changed

• Alerts that can't be ignored. Spend and anomaly alerts no longer live only in an inbox. Vercel usage is now pulled into our own monitoring (Datadog), with an anomaly monitor that pages the team, and every alert gets logged as an incident with a short write-up.
• Firewall and rate limiting on the edge. The Vercel Firewall turned out to be our fastest kill switch, so we made it a first-class tool: rate-limiting rules on the website project and a documented procedure for blocking a single domain or route in seconds.
• Images are resized before they are stored. We changed our image pipeline so every image is resized first and only then uploaded, uploads stay under 10 MB, and source files over 10 MB are not processed at all. A 60 MB original can no longer end up on the edge at full size. We also keep an eye on the few sites that use the most bandwidth.
• A rule of thumb for the team: if an alert mentions money, it gets looked at now, not in the morning.

A month later the new setup got its first real test: a 5–10 minute Fast Data Transfer spike on another site was caught and handled with no visible billing impact.

Lessons

• Usage-based pricing turns bugs into invoices. On a fixed server, this would have been a slow website. On a CDN, it was $600 an hour.
• Your cost alerts are production alerts. Treat them with the same urgency as downtime.
• Know your kill switch before you need it. Blocking one domain at the edge took minutes — once we decided to do it.
• Don't trust a single layer. An optimizer that "always" resizes images is great until the one time it doesn't. Caps and rate limits behind it are cheap insurance.

How to protect your own site

If you run anything on usage-billed hosting (Vercel, Netlify, AWS, Cloudflare and the like), set these up before you need them:

1. Set a hard spend limit, not just a notification. On Vercel: Settings → Billing → Spend Management — set a monthly amount and decide what happens when it's reached (notify only vs. pause production deployments). Pausing your site is painful; a five-figure invoice is worse. On AWS: AWS Budgets + Cost Anomaly Detection.
2. Turn on Vercel anomaly detection. Vercel can watch your usage and alert you when edge requests, Fast Data Transfer or function invocations suddenly jump above their normal level. Enable the anomaly alerts for your team and send them to a webhook (Slack, n8n, your on-call tool), not just to email: the webhook payload also carries more detail than the email. This is exactly the alert that told us about our problem within minutes.
3. Send cost alerts where people actually look. Not just email. Route them to Slack, SMS or your on-call tool, and make sure more than one person gets them. Our $6,500 was mostly the gap between "alert sent" and "alert read".
4. Turn on the firewall and add a rate limit. On Vercel: Project → Firewall — add a rate-limiting rule (e.g. per IP on your page and image routes), enable bot protection, and know where the Attack Challenge Mode switch is. A sane per-IP limit costs real visitors nothing and caps a runaway bot or scraper.
5. Know your kill switch. Write down, in one place, how to block a single domain, path or IP in under a minute. Practice it once.
6. Cap what your image optimizer will accept. Allow only the image sources you expect (remotePatterns in Next.js), keep the generated sizes reasonable, and don't let a giant original slip through unresized.
7. Optimize media before it goes live. A hero image doesn't need to be 60 MB. Compress and resize before upload; for video, use a proper streaming service instead of a raw MP4 file.
8. Watch bandwidth, not just requests. Our request graph looked normal the whole night. The line that exploded was data transfer. Put it on your dashboard and alert on it.
9. Review your top consumers monthly. Look at which domains, pages or files use the most bandwidth. Usually it's a handful — and usually one of them surprises you.

Takeaway for Super users

You don't need to do anything. But if you've ever wondered why we sometimes ask you to swap a giant image for a smaller one — now you know. Optimize your images before uploading them to Notion: your pages load faster and everybody wins.

Takeaway for NON-Super users

⚡

Don't want to deal with problems like this? Try Super and leave it to us.

Try Super for free