Sreya Sukhavasi is a Software Engineer at Nordstrom who loves turning challenges into learning stories.
She writes about software engineering, career growth, and the early steps of building confidence in tech. Through her writing, she hopes to help more women see that they’re capable of far more than they think – one line of code (and courage) at a time.
When I first heard I’d soon be on-call, I’ll admit my stomach dropped a little.
The idea of being the person responsible for responding to live incidents, while systems and users depend on you, can feel overwhelming, especially early in your career.
But that moment also marked a turning point. It pushed me to move from theory to action, from observation to ownership.
Here’s how I prepared for my first on-call experience, what I learned, and how you can too, both mentally and technically.
Learn by Shadowing, Not Just Watching
My first step was shadowing experienced teammates during their on-call rotations. I didn’t just observe what they did; I asked why they did it.
When a service alert popped up, I paid attention to how they prioritized issues, communicated with others, and stayed calm under pressure. Every incident had a story behind it, and I started connecting those stories to our system design and codebase.
This phase helped me understand that on-call isn’t about knowing everything. It’s about knowing where to look, how to think clearly, and who to collaborate with.
If you’re new, don’t wait for a formal shadowing program. Ask to pair up with someone who’s comfortable letting you listen in during their shift. Even an hour or two can teach you a lot.
Move from Passive to Active Learning
After a few shadow sessions, I started to step in during smaller incidents with guidance, of course.
There’s a big difference between reading about an alert and actually handling one. During one of my early experiences, a service unexpectedly slowed down. My first instinct was panic, but then training kicked in: check logs, identify patterns, communicate updates, escalate when needed.
That moment taught me something crucial: real confidence doesn’t come from being perfectly prepared. It comes from showing up, making decisions, and learning from feedback.
So if you’re preparing for your first shift, volunteer to take small ownership pieces. Maybe it’s triaging alerts or updating the incident channel. Each real step builds trust both with your team and with yourself.
Prepare Mentally Before Technically
Being on-call is as much a mental exercise as a technical one.
Before my first shift, I had this running thought: What if something breaks and I don’t know how to fix it?
My mentor gave me advice that stuck – “You’re not expected to know everything, just to take the right next step.”
That mindset shift changed everything. Instead of worrying about every possible scenario, I focused on learning how to stay calm, document clearly, and ask for help efficiently.
A few practical things that helped me:
- Keep a personal checklist of what to verify first when an alert hits, who to contact, and where to find runbooks.
- Communicate early and often. Silence during an incident often creates more anxiety for others than the incident itself.
- Rest before your shift. On-call requires alertness and patience, not just technical skill.
Build a Support System
Your first on-call experience shouldn’t feel isolating. I was lucky to have teammates who checked in before and after my shifts, offering feedback and encouragement.
If your team doesn’t have a formal system for this, initiate one. Ask a senior engineer to be your go-to contact during your first week. After your shift, do a quick debrief to discuss what went well and what you’d improve next time.
You’ll be surprised how open people are to sharing their own early experiences. Almost everyone has a story of a night they were woken up by an alert that turned out to be a false alarm, and those stories remind you that mistakes are part of the process.
Keep Reflecting and Refining
After my first few on-call rotations, I started journaling short notes on what I learned, what patterns I noticed, and where I needed more clarity.
For example, I realized that certain alerts repeated frequently. Instead of just reacting, I brought it up in our team’s retrospective, and we improved our monitoring rules.
That small initiative made me feel more proactive and helped me see how on-call isn’t just about fixing problems, it’s about making systems (and people) stronger over time.
Final Thoughts
If you’re nervous about your first on-call, know this: every experienced engineer you admire has been exactly where you are. They’ve felt that same uncertainty before picking up the pager.
The difference between fear and confidence is practice and community.
Don’t aim for perfection on day one. Aim to learn, to communicate clearly, and to trust yourself when things get tricky. Each shift will teach you more than any tutorial or handbook ever could.
And when you’ve handled your first incident and see the system stabilize again, you’ll realize something powerful: you didn’t just survive your first on-call; you grew through it.
So, to every woman stepping into that first shift: take a deep breath, trust your preparation, and remember you’re more ready than you think.
