Which of my projects is burning the bandwidth?

On Vercel#

Dashboard: account or team → Usage. Change the grouping to per-project. Set the period to the current cycle first — comparing partial cycles is how people misdiagnose this.

CLI, since February 2026:

vercel usage --from 2026-08-01 --to 2026-08-31 --breakdown daily --format json

Daily granularity is the useful part. A project that has been steady all month and spiked on the 14th is a different problem from one that has climbed steadily, and the daily view separates them immediately.

On Hobby: Vercel restricts usage data on the Hobby tier, so both the API and any third-party tool will show less than you want. Not something anyone can work around.

On Netlify#

The team dashboard shows bandwidth per site. The account-level endpoint gives you the total for scripting:

curl -fsS "https://api.netlify.com/api/v1/accounts/$ACCOUNT_ID/bandwidth" \
  -H "Authorization: Bearer $NETLIFY_TOKEN"

Full script in Netlify bandwidth alerts.

The ratio that actually tells you something#

Finding the biggest project is the easy half. The useful question is whether its bandwidth is proportionate.

Compare bandwidth against page views from your analytics:

• Roughly proportionate → real traffic. This is a capacity conversation.
• Bandwidth far above page views → something non-human is consuming it. Bots, crawlers, scrapers, or an attack.
• A small project with large bandwidth → almost always the second case, and usually image optimization.

That gap between bytes served and humans served is the diagnosis. It is also the number nobody looks at, because it lives in two different tools.

Once you have found it#

• Disproportionate to traffic → why is my bill so high, section 1 and 2.
• Need it stopped now → the runbook.
• Proportionate but growing → caching, then a plan conversation.

Questions people actually ask