ENGINEERING
Soak, then ship: our production release policy
Staging has to stay healthy for a fixed window before anything reaches production. The window is the feature.
Staging has to stay healthy for a fixed window before anything reaches production. The window is the feature.
Agents merge faster than humans can watch. Continuous deploy to production under those conditions is not confidence, it is a dare. So production is gated on time rather than on attention.
A change lands in staging and has to hold healthy for a configured number of hours — four by default — before it becomes eligible for production. Health is error rate, latency, and any failing check the environment declares. A regression during the soak resets the clock and notifies the owning seat.
DEFAULT
Four hours catches most of what we see. Teams shipping payment or auth changes raise it to twenty-four; nobody has asked to lower it below two.
If production health drops below the declared threshold within thirty minutes of a release, the previous build comes back automatically and the release is marked failed. Nine of the last ten rollbacks were automatic. The tenth was a human being faster than the check, which we count as a win for the human.
This blog has no staging environment at all. A template change goes straight to production, which is exactly the posture this post argues against. The mitigation is a local server that renders the real templates against the real database, and a signed preview link for drafts — weaker than a soak window, and named as a gap rather than dressed up as a design.