Seuil analysisRetention is not only a storage setting. It decides how much executable release history remains available when production goes wrong.
What Vercel announced on October 9
Vercel is extending Deployment Storage and Functions Storage billing to all Pro teams at $0.10 per GB-month. The company says each team will receive its actual billing start date by email, so October 23 is not a universal billing date.
The same announcement moves the retention window to 30 days. Deployments older than 30 days will start deleting on October 23 unless the team opts out in retention settings. Policies already set to 30 days or less remain unchanged.
Vercel also says new Pro teams now default to 30 days and can configure a longer period. Existing teams should review the Usage page and their current policies for Production, Pre-Production, Canceled and Errored deployments before accepting the default.
Vercel deployment retention now affects incident response
A shorter history reduces the number of old releases available for inspection or direct rollback. Vercel's Instant Rollback points production domains to an existing deployment without rebuilding it, so the retained deployment is the recovery asset.
Imagine a checkout regression appears after a configuration change that went unnoticed for five weeks. A 30-day policy may preserve the code in Git, but not the ready deployment with its original build output. Rebuilding is not equivalent when dependencies, environment settings or external services have changed.
Vercel warns that even an instant rollback can restore older environment configuration and cron settings while databases, APIs and CMS content remain current. Retention protects one part of recovery. It does not make the whole system travel back in time.
Keep history according to the evidence it carries
Different deployment classes answer different questions. Production history supports recovery, previews preserve review context, and failed builds can explain a recurring release problem. One duration for every class is simple, but it may save the wrong evidence.
For example, an agency may need a preview long enough to resolve an approval dispute, while a product team may value production rollback points more than canceled builds. The decision should follow the release process, not a fear of deleting anything.
| Deployment class | Useful for | Risk when history is too short |
|---|---|---|
| Production | Rollback and incident comparison | A known-good executable release is no longer available |
| Pre-Production | Review, approval and branch investigation | The evidence behind a product decision disappears |
| Errored | Diagnosing repeated build failures | Teams lose the earlier failure context |
| Canceled | Rare workflow or audit questions | Low-value history may consume storage without aiding recovery |
Storage cost is only one side of the decision
Teams can reduce storage by shortening retention, excluding unnecessary build files, moving large assets to Vercel Blob and reducing function bundle size. Those are Vercel's recommended optimization paths.
The counterweight is the cost of losing a useful recovery point. If a team retains every branch preview forever, it pays for history it may never use. If it deletes production too aggressively, the first slow-moving regression can turn a quick alias change into a rebuild and investigation.
Review the Usage page before changing policy, then connect the choice to the same release ownership used in a website maintenance retainer. Storage belongs in operations, not in a forgotten billing tab.
Vercel documentation leaves one recovery detail unclear
Vercel's current pages do not describe deletion recovery in exactly the same way. The new-team announcement says deleted deployments cannot be restored or used for rollback. The retention documentation describes a 30-day recovery window for successfully built deployments marked for deletion.
That mismatch matters if a team plans to recover after deletion. Treat deletion as the loss of an immediately usable rollback point, and confirm the behavior in the current account and documentation before relying on any recovery window.
Vercel's retention documentation also lists exceptions that protect recent deployments, active aliases and some branch previews. These safeguards reduce accidental loss, but they should not replace an explicit policy for the releases the team knows it may need.
What Pro teams should do before October 23
Teams using Next.js can also compare their delivery responsibilities with the Next.js agency buying guide. The practical next step is to give retention and rollback one owner in the same operating plan that covers releases, incidents and maintenance.
- Find the billing start date in the team email instead of assuming October 23.
- Review current Production, Pre-Production, Canceled and Errored policies.
- Identify the oldest production release that still has rollback value.
- Check aliases, environment configuration, cron changes and external data dependencies.
- Compare Deployment Storage and Functions Storage usage with the evidence retained.
- Remove unnecessary build files or oversized bundles before deleting useful history.
- Test the rollback runbook with a retained deployment.
- Assign policy ownership and record the next review date.