Bandwidth usage chart over time

Support
,
#1

Hi, I just received this email,

Your bandwidth usage on your team has reached 50% of the current allowance in your billing cycle from March 10 to April 10.

If bandwidth usage goes over the allowance before the end of the billing cycle, we’ll add an extra bandwidth pack for $20 , increasing your allowance by 100GB for the current billing cycle. You can also increase your total bandwidth allowance by upgrading your team to a higher plan.

You can check current usage details in the Netlify UI.

I am surprised because,

  • I’ve never received this notice before
  • I’m less than halfway through the current period
  • This period’s traffic is about the same as the previous period.
  • I recently set up code splitting and browser caching which should decrease traffic, not increase it

I don’t see any history of usage in the Netlify UI. I would like to see a usage chart of this month’s data, day-by-day, as well as totals for previous months. Please let me know how I can do this.

Thanks!

#2

Hi there,
thanks for getting in touch! what you are describing is indeed odd.

Can you check your bandwidth for me, please?

You can find it in the billing tab.

image
image2020×1084 140 KB

#4

Hi @perry,

Thank you for your reply. It was 59 GB when I first checked after receiving the email. Then less than 12 hours later it was 64 GB. After reverting my previous code changes, another 12 hours later, it is still 64 GB, so I am crossing my fingers that the issue is resolved.

If usage still looks okay after a day or so then I will also turn on asset optimization. That seems to be Netlify’s way of enabling browser caching.

I wanted to enable browser caching in a more non Netlify-specific way. I wonder what I misunderstand about Netlify’s caching and how bandwidth is calculated. Prior to making the code changes, I carefully read Netlify’s blog post on caching. I also read the linked Google article on ETags, it seems fairly straightforward.

The site, reveddit.com, is mostly javascript (formerly a single file, now several via route-based code splitting in React), so every time I do a build, most of the asset-data changes. I thought adding a hash to the filenames would not be a big deal since the lion’s share of data changes every time I push an update, and the index.html file is very small. By the way, the now-reverted hash was changing every build, but again I don’t see why that caused such an increase in bandwidth given the nature of the site.

After writing this post, I found this post from Chris where he writes,

it seems like you are using hashes in your assets which will make your cache-control headers pointless.

So I guess there is something that isn’t clicking for me. It seems like the OP of that post doesn’t fully understand it either.

It would be nice to be able to see prior months’ bandwidth usage, even if it’s just a basic list. Thanks again!

#5

Those billing-screen bandwidth numbers do not update in realtime at present, Robert, so not sure anything is resolved for about 24 hours. Our team is working to improve the nature of that billing data to be closer to real time!

Browser caching is always enabled, so that is a misreading of data that you need to enable optimization to enable it. This article which you reference describes our USUAL way of handling caching, without optimization enabled.

We can query past months’ bandwidth for you upon request, but I don’t think we have any plans to show data older than 60 days in our UI…

#6

Hi Chris, a live display of bandwidth usage sounds great. I’d like to view the whole history in aggregate by month. 60 days of daily aggregate would certainly bring more insight than the current display.

Regarding browser caching, I meant browser caching without the 304 revalidation. My understanding is asset optimization is required for that setting to kick in. As I wrote above, I tried doing this myself via netlify.toml along with cache-busting hashes and it seemed to cause a significant increase in bandwidth usage.

Now that I have reverted those changes, today I see my usage is 73 GB, a 9 GB increase over yesterday.

By the way, I like browser caching without revalidation because it’s faster. For example, if you visit the search page, then click on “add-ons” at the top, then refresh your browser, and then click back to about, there is a slight delay that does not occur when revalidation is disabled.

I’m still in the dark about why my usage increased so dramatically. Perhaps the usage data will shed some light. I will send a support request for this. Thanks!

1 Like
#7

I second the request for a bandwidth usage chart. It seems it’s available in the analytics product [1], but to me it seems more like a billing feature that should be included in the base product.

[1] Analytics: UI updates for better accuracy

#8

Bandwidth usage is at 92 GB now. I don’t know what is causing this so I put Cloudflare in front before I get cut off. Given the rate of ~10GB per day, I doubt I make it to April 10th but it’s worth a shot.

One thing I did not revert in my code is the code splitting. I wonder if it is problematic for Netlify’s caching if index.html has a main.js that dynamically loads other .js files. Other than that I am out of ideas.

#9

Hi, @bogdanspatial and @robert, we do have an open feature request for a more detailed breakdown of bandwidth usage in our UI. I’ve cross-linked this topic to that feature request and we’ll update you here if/when this feature becomes available.

Regarding the caching, @robert, the dynamic code splitting would not affect how our caching works. However, if the files contents or names change each deploy, then that would invalidate the locally cached version. That would happen independently of our cache invalidation. Also, if there are many unique visitors, caching is less effective as the cached content is only used for the reload of the pages and won’t apply to the first load by a new person/browser. Unique visitors will always require the uncached loading of the page and assets.

If there are other questions, please let us know.

2 Likes