No deploys after Wednesday.
That is the entire rule. Five words. We adopted it fourteen months ago, and weekend incidents dropped to near zero within the first quarter. Not because the rule is clever. Because it is a boundary, and boundaries are cheaper than dashboards.
Before the rule, our deploy calendar looked like everyone else's. Engineers shipped when the work was ready. Sometimes that meant Thursday afternoon. Sometimes Friday at 4 PM, right before someone closed a laptop and drove home.
The pattern was predictable in hindsight: a Friday deploy would pass its checks, look fine for an hour, then start misbehaving under real weekend traffic patterns. By Saturday morning, someone's phone was buzzing. The on-call engineer, who had no context on the change, would spend hours reading commit messages trying to understand what shifted.
We tracked it. Over six months, more than 70 percent of our weekend pages traced back to changes deployed Thursday or Friday. The remaining 30 percent were genuine infrastructure surprises — things that would have happened regardless. The signal was loud: most of our weekend pain was self-inflicted.
The instinct is to draw the line at Thursday close-of-business. We tried that first. It didn't work, for a human reason: "end of Thursday" is fuzzy. Someone in one time zone finishes at 5 PM, someone else pushes a small fix at 6:30 PM their time because it's "basically still Thursday." Within two weeks, the boundary had drifted to Friday noon.
Wednesday gave us a full business day of soak time before the weekend. If something broke Thursday morning, the person who wrote the change was still in their regular working rhythm, with full context. They could respond, investigate, and fix without touching anyone's weekend.
The gap also created a natural observation window. A change that survived Wednesday evening traffic and all of Thursday's load had earned a basic level of confidence. Not proof — confidence. That distinction matters.
The objection was obvious: you're cutting two days of deploy capacity from every week. Won't velocity drop?
We measured it. Deploys per week did not decline. They shifted. Engineers who used to spread work across five days started landing changes earlier in the week. Monday and Tuesday became the high-volume deploy days. Wednesday morning became the last-call window, giving those changes the rest of Wednesday plus Thursday to prove themselves.
What changed was the shape of the week, not its throughput. Work expanded to fill the old five-day window because there was no reason not to. Once the window narrowed, people planned around it. Batching improved. Deploy sizes got smaller because engineers wanted to land incremental pieces early rather than risk a large change getting stuck until Monday.
The rule only works if it is a real rule, not a guideline. Guidelines erode. Rules hold.
We enforce it socially, not with tooling. There is no automated gate that prevents a Thursday deploy. Anyone with deploy access can push any day they want. But the team agreed, as a group, that the rule applies to everyone — founders, urgent feature requests from customers, "it's a one-line change."
That last exception is the one that kills every deploy policy. One-line changes feel safe. They are not. A one-line change on a Friday afternoon is still a change the on-call engineer has to understand at 2 AM if something correlates.
We have broken the rule twice in fourteen months, both for security patches that could not wait. Each time, the person deploying wrote a short note explaining why, and the on-call engineer was briefed in real time. Breaking the rule felt expensive. That's exactly how it should feel.
The obvious win is fewer weekend incidents. The second-order effects surprised us.
On-call shifts became less dreaded. Engineers stopped negotiating to avoid weekend rotation. The person on call knew the system they were watching had been stable since Wednesday. Their job shifted from "brace for impact" to "monitor a steady state." That is a different emotional experience.
Thursday and Friday became better days for deep work. No one was firefighting a deploy gone wrong. No one was watching graphs nervously. Engineers used those days for design, code review, and the kind of thinking that gets crowded out when every day is a potential deploy day.
We did not buy a new tool. We did not build a canary system. We did not hire a platform team. We changed the calendar.
The cheapest reliability win is often a constraint, not a capability. A rule that prevents you from creating problems will always outperform a system designed to detect them after the fact.
If your weekend incident rate is high, look at your deploy log before you look at your monitoring stack. The fix might be five words long.
Be the first to comment.
0 comments
Loading comments...