Hello Everybody! I’m using Vercel for my project JournalEntriesHub and now I’m getting tat I have high usage
Hi Qusai,
I’d first check which Vercel metric is high before deciding whether you need to upgrade.
Google Search Console and Vercel usage are measuring different things. GSC is mostly about Google search/crawl visibility, while Vercel usage can include requests from real users, bots, crawlers, assets, API routes, images, middleware, and preview/production traffic depending on the metric.
In the Vercel dashboard, go to:
Team / Account → Usage
Then check which line is growing the most, for example:
Edge Requests
Fast Data Transfer
Function Invocations
Function Duration
Image Optimization
Web Analytics Events
That tells you where to look next.
For a Next.js site, common causes of unexpectedly high usage are:
- bots or crawlers hitting many pages
- API routes being called on every page load
- middleware running for static assets because the matcher is too broad
- large images or files being served repeatedly
- pages refreshing/polling too often
- preview deployments being crawled or shared
I’d also open the project’s Firewall page and check the top paths, hosts, countries, and user agents. If most traffic is from strange user agents or one path is being hammered, it may be bot traffic rather than real visitors.
A quick code check for middleware is useful too. If you have middleware.ts, make sure it is not matching everything unnecessarily:
export const config = {
matcher: ["/((?!_next/static|_next/image|favicon.ico|robots.txt|sitemap.xml).*)"],
}
If the high metric is Function Invocations, I’d check your API routes and server actions. If it is Fast Data Transfer, I’d check large images/assets. If it is Edge Requests, I’d check bots, crawlers, and middleware.
Vercel’s usage guide is useful for finding the exact metric breakdown:
Can you share which usage metric is high, without sharing any private account or billing details?
Dear Ryu
Edge Requests 1,055,672 / 1,000,000
Fast Origin Transfer 8.03 GB / 10 GB
Incremental Static Regeneration 1,043,180 / 1,000,000
these are the metrics that are high!
I have added huge number of pages recently so that can be the reason! I just want to make sure that it’s not a code or a practice problem
here is my firewall in the image seems like I’m having a bot party!
GSC said I got 359 clicks in the last 28 days! I don’t know if the bots are ruining my usage or if that’s normal
Hi Qusai,
Thanks, that screenshot is actually very useful. This does not look like 359 real Google visitors causing the usage.
In the last day, your Firewall shows about 77k allowed requests, and the top AS name is Tencent-related with 44.7k requests. Bot Protection is also inactive and you have 0 custom rules, so right now most of that crawler/scraper traffic is being allowed through to the site.
So yes, adding many pages can explain higher usage, but the bigger issue seems to be bots discovering and crawling those pages.
I’d do two things before deciding that Pro is the solution:
In the Firewall, I’d start with a rule in Log mode for the obvious suspicious traffic, then change it to Challenge, Deny, or rate limit after you confirm it is not Google/Bing or a service you want.
For example, something like:
If:
AS Name contains Tencent
OR IP is one of the repeated top IPs
OR requests are repeatedly hitting /contact, /founder, /about, /glossary
Then:
Log first
After a short test, if it is clearly unwanted scraping, change the action to Challenge, Deny, or a rate limit. I would not block all bots globally if SEO matters, because you still want legitimate crawlers like Googlebot to reach your public pages.
Your Incremental Static Regeneration number is also high, so check whether your new pages are using a short revalidate, like:
export const revalidate = 60
If these are glossary/content pages that do not change every minute, increase that a lot:
export const revalidate = 86400 // 1 day
or make them fully static / on-demand revalidated if they only change when you publish content.
Also, if your routes are dynamic, make sure bots cannot generate unlimited unknown pages. If you know all valid slugs, use generateStaticParams() and consider:
export const dynamicParams = false
That way random bot URLs return 404 instead of causing new dynamic/ISR work.
So my read is: upgrading to Pro may give you more room, but I would not upgrade just to absorb bot traffic. First reduce the bot requests and make sure your ISR pages are not revalidating too often. After that, if real traffic plus legitimate search crawling still exceeds the Hobby limits, then Pro makes more sense.
**Thank you Ryu I followed your suggestions and I’ll wait for the results
what I did:
1. “Static-Locked” the Site** I audited my pages and added export const dynamic = 'force-static'; to everything that didn’t need real-time updates. I also added export const dynamicParams = false; to my dynamic routes so bots couldn’t force the server to generate 404 pages. Finally, I moved my data-processing math (sorting/filtering JSON) outside of my React components so it runs once at build time, not on every request.
2. Enabled Bot Protection I turned on Bot Protection in the Vercel Firewall. I set it to Log first to confirm the scrapers, then enabled AI Bot blocking.
Hi Qusai,
Nice, those are exactly the kinds of changes I’d make first.
One thing I’d watch carefully after adding:
export const dynamic = "force-static"
export const dynamicParams = false
is that every dynamic route still has all valid slugs included at build time. If a real page was not returned by generateStaticParams(), dynamicParams = false can make it return 404, which is good for random bot URLs but bad if a legitimate page was missed.
So I’d test a sample of your important pages after the next deploy:
curl -I https://www.journalentrieshub.com/some-known-valid-page
curl -I https://www.journalentrieshub.com/some-random-fake-page
A known valid page should return 200, and a fake/random slug should return 404.
For the bot side, starting Bot Protection in Log mode was a good call. After a few hours, compare:
Allowed requests
Blocked / challenged requests
Top AS names
Top paths
ISR usage
If the Tencent/unknown scraper traffic is still mostly allowed, I’d add a narrow custom rule or rate limit for that traffic rather than relying only on AI Bot blocking. The important thing is to avoid blocking Googlebot/Bingbot if SEO matters.
Also, don’t worry if Edge Requests do not instantly drop to normal. Bots still have to hit the edge before they can be logged/challenged/blocked. The more important sign is that Fast Origin Transfer and ISR usage should drop, because unwanted traffic should stop reaching expensive rendering/revalidation paths.
I’d give it 24 hours after the deploy and firewall changes, then compare the usage graph by metric. If ISR falls hard but Edge Requests stay high, that means your code fix worked and you’re mostly dealing with crawler volume.
24 hours have passed
and here are the differences in usage
24th of June (before fixing)
Edge Requests 80,072
Fast Origin Transfer 533mb
Incremental Static Regeneration 63,523
25th of June (After fixing)
Edge Requests 16,223
Fast Origin Transfer 133mb
Incremental Static Regeneration 19,726
I like what I see!