Static implementation guide
Safe Rewrite Rollbacks
Recover from origin, routing, or cache failures without hiding stale behavior or losing track of production aliases.
Last updated 2026-08-30
Restore a known gateway state
If a rewrite release fails, roll the gateway back to a previously verified production deployment and confirm its domain alias. When caching itself is suspect, disable rewrite caching and redeploy so requests reach the origin directly while diagnosis continues. This sacrifices the optimization but preserves an understandable request path.
Do not silently introduce an automatic fallback that masks origin errors with unrelated stale content. A separate static status page can be considered as an explicit product decision, but it should be reviewed independently because it changes SEO responses and experiment results.
Recheck coupled configuration
After rollback, inspect both production aliases, the gateway origin variable, public site URLs, domain attachment, and protection rules. Fetch one guide and its generated assets through the public host, then verify canonical and robots behavior on both hosts.
Content releases also require cache coordination. Deploying only the origin can leave the gateway serving old HTML until its TTL expires. Wait for expiry, purge the documented cache tag when supported, or redeploy the gateway to create a new cache namespace, and record which option was used.