We stopped shipping on Fridays, and it changed nothing.
An honest look at why deploy freezes feel safe and rarely are. Spoiler: the safest deploy schedule is the one you don't need.
For a year and a half, we didn't ship code on Fridays. The reasoning was reasonable. Incidents happen. Weekends are bad times to have incidents. Therefore, no Friday deploys.
Then we checked the data.
What we found
We had two years of incident history. We pulled the deploy time for every incident, bucketed by day. The distribution was uniform. Friday wasn't more dangerous than Tuesday. We had just convinced ourselves it was.
The actual driver of incident risk was deploy size — number of commits and number of services touched — not deploy timing. Big deploys broke things. Small deploys didn't.
Freezing Fridays meant we shipped twice as much on Thursday. We had inadvertently doubled our average deploy size and tripled our incident rate on Thursday night.
The freeze was making things worse, not better. The intuition was real and the data laughed at it.
The change
We lifted the freeze. We capped deploy size at five commits. We required canaries on every push, regardless of day. Incident rate dropped 40% across the board.
The lesson isn't that freezes are bad. It's that the constraint should be on the thing causing the risk, not on the time of week.
Iris writes about platform engineering, post-incident learning, and the operational habits of teams that ship without burning out.