Usage limits: the metrics that actually caused a real production incident

Each of these is billed (and capped, on free/Hobby tiers) independently, and — critically — most of them compound with two separate, multiplying factors: how often you deploy, and how much real traffic hits pages that aren't served purely from a static, long-lived cache.

A production app (this very curriculum's own) merged to main ten times in a single day, once per feature shipped. Each merge triggered a new production deployment — and because the app renders lesson pages via ISR (lesson 4), every single deploy invalidated the ISR cache for every one of 500+ lesson pages at once. The next visitor to each page after each deploy triggered a fresh render (Fluid Active CPU) and a fresh ISR write — ten times that day, across every page, compounding into real, visible overage on Fluid Active CPU, ISR Writes, and Fast Origin Transfer all at once.

Independently of the traffic-driven overage above, 347 total deployments had accumulated over the project's 25-day life — every single deployment (production and preview) is retained indefinitely by default, and each one's build output counts toward Deployment Storage. A project that deploys frequently, with nobody ever pruning old deployments, can genuinely exceed storage limits on its own, with zero relationship to how much actual traffic the site receives.

For the storage problem: bulk-delete old, unaliased deployments via the CLI, keeping only the newest N plus anything still actively pointed-at by a domain — this is a one-time cleanup, not a recurring task, since the actual root cause (no automatic pruning of old deployments) is a platform default, not a bug in the app.

For the traffic/compute problem: stop merging to main after every single small change — batch several changes into one production deploy instead (once per session, or every few features), directly reducing how many times the ISR-invalidation storm described above actually happens. This is a real, deliberate trade-off: slower time-to-production for any one individual change, in exchange for a dramatically smaller number of full-site regeneration storms per week.

This incident is a genuine example of something that's individually, mechanically simple (ISR invalidates on deploy; deployments accumulate storage) becoming a real production issue only once you see how the pieces interact under real operational habits — a team's normal "commit and deploy often" instinct, which is harmless for a simple static site, becomes expensive specifically because of how ISR and deployment retention both scale with deploy frequency. Understanding each mechanism individually (as the earlier lessons in this domain do) isn't the same as understanding how they compound — which is exactly the gap a real incident, rather than a feature description, makes visible.