Instant Rollback vs Rebuild from Git for a bad production deploy with changed build settings

Netlify hosts sites as immutable atomic deploys built from a connected git repository. There is no user-managed backup restore for site files; recovery relies on deploy history and the source repository. Forms, Identity and Large Media are stored separately.

For a production revert after a bad release, two documented approaches exist. Instant Rollback republishes a previous successful deploy without rebuilding, which offers the fastest path to restore a known good artifact. Rebuild from Git fixes the source commit and triggers a new build, allowing code and configuration to be corrected before publishing.

The decision is unresolved when the bad deploy also changed build settings or environment variables. Instant Rollback restores prior artifacts but leaves the source and configuration divergent, while Rebuild from Git aligns source truth at the cost of build time. Verification of recovered data is limited to deploy logs, preview URLs and post-deploy checks, as file-level diff or checksum verification for published deploys is not provided.

Which approach preserves the intended build configuration when environment variables were altered in the bad release? How does plan-dependent deploy history retention affect the availability of Instant Rollback for older deploys? What signals confirm the published deploy matches the intended recovered state without file-level diff?