Tracking down a nasty Netlify bandwidth burner

Most days, my website sits there quietly, publishing writing, showing off my work, selling a few products, and generally behaving itself. But today, I got an email from Netlify telling me that, although my migrated website was only days old, I had already burned through 50% of my allocated monthly bandwidth.

From June 24, 2026, to June 25, my site had served 43,916 requests and used 5.4GB of bandwidth. That’s not “the internet’s melted” territory, but for a static website, it was enough to make me spit out my coffee. My site isn’t YouTube. It isn’t serving huge videos, large downloads, or anything that should be quietly shovelling gigabytes out the door overnight. So, I went digging.

Finding the culprit in Netlify Observability

Netlify Observability made the first part surprisingly straightforward. I looked at which paths used the most bandwidth, not just the most requests. That distinction matters. A page can be requested thousands of times and still be cheap if it’s small. Another URL can be requested far fewer times and still be expensive if every response is enormous.

The obvious offender was: /blog/feed

Over that 24-hour period, my blog feed used 2.34GB of bandwidth across about 2,700 requests. That’s a lot of bandwidth for what should be a small XML file.

The request count wasn’t especially shocking. Feeds get hit by RSS readers, search tools, bots, and all sorts of things that aren’t people sitting in front of browsers. But the bandwidth was the problem. Each request was carrying far more weight than it needed to.

Filtering by user agent category confirmed my suspicion. Most of the traffic wasn’t coming from ordinary browsers. It was crawlers, tools, and other automated clients. In other words, the feed wasn’t mainly being read by humans. It was being fetched repeatedly by machines.

That’s fine. Feeds are for machines as much as people. But that doesn’t mean they need to be massive.

What was wrong with the feed

My problem was self-inflicted: when I rebuilt the website recently, I thought it might be nice for people to read the full post in their RSS reader, not just an excerpt. That was burning through my bandwidth at an alarming rate, so I‘ve switched back to displaying summaries only. Before the fix, the feed weighed:

• 4,499,753 bytes raw
• 1,317,045 bytes gzipped

That’s about 1.3MB transferred for a single compressed feed request. One request like that isn’t much. Two thousand seven hundred requests are.

This is where my new static website caught me out. Because everything is prebuilt, it’s easy to assume everything is cheap. But a static file can still be expensive if it’s large and popular with bots.

What I changed

I changed the feed to use summaries instead of full post bodies. I also limited it to the latest 25 entries. That gives RSS readers, crawlers, and other tools enough information to understand what’s new without forcing them to download half my website every time they ask for the feed. After the change, the feed dropped to:

• 24,777 bytes raw
• 3,898 bytes gzipped

The raw feed went from about 4.5MB to about 25KB. The gzipped version went from about 1.3MB to under 4KB.

While I was there, I also looked at the search index. That wasn’t the main source of the bandwidth spike, but I had similar suspicions. It included larger text blobs than necessary. Before the change, the search index was:

• 4,182,622 bytes raw
• 1,126,871 bytes gzipped

I changed it to use shorter excerpts instead of bigger chunks of post content. After that, it became:

• 2,187,393 bytes raw
• 460,052 bytes gzipped

Still not tiny, but much better. More importantly, it’s now closer to what the feature actually needs.

Lessons learned

This was a useful reminder that small architectural decisions hang around. A feed template can become expensive when the archive has almost 20 years of content. A search index that seemed harmless quietly became heavier with every post. A few things I’ll keep in mind from now on:

• Bandwidth problems aren’t always caused by images, videos, or downloads.
• Static files still need watching when they grow over time.
• Feeds should include enough to be useful, not everything you’ve ever published.
• Automated traffic is normal, but it magnifies waste.
• Observability is only useful if you actually look at it.

The most useful part of this exercise wasn’t the fix itself but learning how to follow the trail from “that seems high” to a specific URL, a specific template, and a specific decision. Fingers crossed, I won’t be getting any more emails from Netlify any time soon.