I still remember my first on-call shift. It was a Friday night, I was three drinks in, and my phone started buzzing. Production database was down. My heart rate spiked. I had no idea what to do.
That’s when I realized — nobody teaches you this stuff. You learn to code. You learn algorithms. But nobody tells you what happens when everything breaks at 2 AM and you’re the one who has to fix it.
The Reality Check
On-call isn’t just “being available.” It’s a completely different mindset. You’re not writing new code — you’re diagnosing fires under pressure. Your brain works differently when you know users are affected and your CEO is getting alerts.
The first thing nobody tells you: the fix is usually simple. It’s finding the problem that’s hard. I’ve spent hours debugging only to discover a typo in a config file, or a disk that filled up because nobody set up alerting.
What I Learned the Hard Way
- Document everything during an incident. I can’t count how many times I’ve fixed something and then forgot what I did. Now I write runbooks as I go.
- Understand your stack’s failure modes. What happens when your cache goes down? When your database connection pool exhausts? Know this before you’re awake at 3 AM.
- Sleep deprivation makes you stupid. If you’ve been awake for 20 hours, don’t touch production. Escalate. It’s okay.
The Mental Game
Here’s the thing nobody talks about: on-call is stressful. Really stressful. There’s a constant background anxiety knowing you might get paged. Some developers love it. I didn’t at first.
What helped? Building confidence through practice. We did incident simulations every sprint. We’d deliberately break something and see how fast the team could diagnose it. It sounds crazy, but it works.
What I’d Do Differently
If I could go back to my first on-call rotation, I’d ask more questions during the day. I’d get familiar with the monitoring dashboards before I needed them at night. I’d have a cheat sheet of who to call for different types of issues.
Also, I’d set up better alerting thresholds. Nothing kills your sleep like getting paged for a non-critical issue. Tune your alerts. Make sure they actually mean something is wrong.
The Bottom Line
On-call taught me more about production systems than any tutorial or course ever did. It’s stressful, it’s waking up at weird hours, but it makes you a better developer. You start writing code that actually handles failure.
If you’re new to on-call: it’ll be scary. That’s normal. Build your confidence before you need it.