⌘K
Pauline P. Narvas Spot on! Your assumption is exactly right. :D Since that Hero component with `revalidate` is shared across your `generateStaticParams` pages, each one of those 1,350+ pages effectively "inherits" its own ISR schedule. This means that after the 1-week window, a visit to any page will kick off a background regeneration. If your traffic hits all those pages, you're looking at a huge spike in serverless executions which is definitely why you're seeing those limits pop up! **A couple ways we can optimize this:** **Fetch client-side:** This is the most straightforward path. If you move the GitHub stars fetch to a client-side call in your Hero component, your pages stay purely static and you stop the ISR "cascade." **Create a dedicated API route:** You can wrap the fetch in a route like `/api/github-stars` and handle the caching there. This keeps the logic centralized: ``` export async function GET() { const stars = await fetch('https://api.github.com/repos/...'); return Response.json(data, { headers: { 'Cache-Control': 's-maxage=604800, stale-while-revalidate' } }); } ``` Hope that helps! Let us know how you get on!
Juan D. Martinez I was thinking of going client side or creating a dedicated landing page for this hero section. I'm not a big fan of client fetching on stuff that doesn't change often, but haven't thought of that API apporach you mentioned, guess I'll try that one instead. I appreciate the help @pawlean 🙌🏻
Pauline P. Narvas No worries, Juan! 
Come back with updates - excited to hear how you get on 
Robin Mate Correct. If that is a new strategy: very bad. Combined with the changed pricing policy, even worse. Continous work seems to become impossible.
Dzhnikolova Yes, totally agree! I was forced to update and the new way of deployment is super annoying! I lost changes, have to merge new branches all the time and from an easy flow, we now moved to much more complex way of deployment. Is there a way to switch back to the previous version of deployment?
