Vercel paused my Hobby project: find what burned the usage and fix it

Your Vercel site is down because the Hobby team went over a usage limit like ISR Writes, Fast Origin Transfer, or Active CPU. How to find the route that caused it, cut the usage, and ask to be unpaused.

What you are seeing

Every site on your Hobby team stops serving and Vercel emails or shows a notice that the team was paused for exceeding usage.
The Usage page shows a metric far past the Hobby amount, for example ISR Writes, ISR Reads, Fast Origin Transfer, or Fluid Active CPU.
You can push the fix to GitHub, but nothing deploys while the team is paused.
Traffic did not obviously change, so it is not clear what used it all up.

Why it happens

Hobby includes fixed amounts, for example 4 hours of Active CPU, 10 GB of Fast Origin Transfer, and 1,000,000 function invocations a month, per Vercel's fair use guidelines. Going far past them pauses the team instead of billing you.
ISR pages revalidate on a short timer (say every 60 seconds) for content that changes rarely, or a webhook calls revalidatePath or revalidateTag on a broad tag that covers many pages.
Pages render a timestamp, random number, or generated ID, so every regeneration counts as a new ISR Write even when the content is the same.
Large data is passed as props into prerendered pages, so every view reads megabytes from the cache and inflates ISR Reads and Fast Origin Transfer.
Middleware with a catch-all matcher, uncached API routes, or bots and AI crawlers hitting every page multiply function invocations and CPU.

How to fix it

1. Find the driver

Open your team's Usage tab and find the one product that is far over (ISR Writes, Fast Origin Transfer, Active CPU) and the one project behind it. Then open that project's Observability tab, narrow to the window where the number jumped, and note the route. Check whether the jump lines up with a deploy: then it is a code change, not traffic.

2. Cut ISR revalidation

// app/blog/[slug]/page.tsx: revalidate once a day instead of every minute
export const revalidate = 86400;

// on-demand: invalidate only the tag that changed, not a site-wide tag
revalidateTag(`post-${id}`);   // not revalidateTag('posts')

// never render new Date() or random IDs into cached output

3. Shrink prerendered pages

Move big JSON out of page props into static files under public/ or a cached API route, and only pass what the first screen needs. One project in Vercel's community cut a page from 1,152 KB to 116 KB this way.

4. Narrow middleware and cache API responses

// middleware.ts: run only where you need it
export const config = { matcher: ['/dashboard/:path*', '/account/:path*'] };

// API route: let the CDN cache repeat answers
return Response.json(data, { headers: { 'Cache-Control': 's-maxage=300, stale-while-revalidate=600' } });

5. Ask to be unpaused

Commit the fix, then post in the Vercel Community (or contact support) with the metric that went over, the cause you found, and what you changed, with numbers. Vercel staff have unpaused teams that showed the fix, and warned that repeat overages can get the account blocked. If the site sells anything or shows ads, note that Vercel's fair use rules require a Pro plan for commercial use.

How to know it is fixed

After the team is unpaused and the fix deploys, the metric's daily line on the Usage page drops to a level that fits the Hobby amount over a month, and Observability shows the route you fixed with far fewer revalidations or invocations. Sources: Vercel fair use guidelines, Vercel: How to reduce ISR revalidation costs, and Vercel Academy: Read the Usage page.