What Changed When We Finally Put a Real On-Call Rotation in Place

For our first year, "on-call" meant the founder who happened to still have Slack open. We were a seven-person engineering team, we deployed straight from main, and we wore our lack of process like it was proof we were moving fast. That mostly worked when we had a handful of customers and every problem came from someone we knew by first name. It stopped working once we started signing bigger accounts with actual uptime expectations.

The turning point was not a spectacular outage. It was a boring, embarrassing Friday-night connection leak that degraded one enterprise tenant for roughly four hours. Nobody noticed internally. Their ops lead emailed support more than once before we responded the next morning, and Monday's renewal call turned into a conversation about whether we were ready to support them at all. That was the moment we stopped debating whether formal on-call would slow us down.

We started small: three senior engineers on rotation, shadow weeks for newer folks, a short incident template, and runbooks for the things that actually woke us up. Six months later, median time to acknowledge was under 10 minutes and MTTR was comfortably below half an hour. The surprise was that shipping got easier, not harder. Once people trusted that incidents would be noticed and owned, deploys stopped feeling like a bet with customer trust.