Nobody warned me the hardest part wouldn't be the technical debugging. It would be trusting myself enough to act on what the data was already telling me.

Nobody warned me the hardest part wouldn't be the technical debugging. It would be trusting myself enough to act on what the data was already telling me.

The Fear Wasn't the System, It Was Me

My first solo shift, a real page came in around midnight: elevated error rates on a service I'd touched maybe twice. I found the likely cause within ten minutes — a downstream timeout — but then sat on it for another fifteen, re-checking my own work, afraid to page a senior engineer for something that might turn out to be nothing, and equally afraid to act alone on something that might turn out to be everything. The technical diagnosis was the easy part. The paralysis afterward wasn't.

What Finally Got Me Moving

What broke the freeze was reframing the query I'd already run, not as "proof I should escalate" but simply as the next fact to act on:

from traces
| where service == "downstream-billing"
| where duration > 10s
| summarize count() by bin(1m)
| sort by bin(1m) desc
| limit 10

Timeout count was climbing steadily, not a one-off blip. That's actionable regardless of my seniority or confidence level — the data didn't care how new I was. I paged a secondary, said exactly what I'd found and what I was uncertain about, and we fixed it together in fifteen minutes. The senior engineer's main feedback afterward wasn't about the diagnosis, which was right. It was: you had this ten minutes before you called me. That's fine to call early next time.

What I'd Tell a New Hire Now

The gap between finding the evidence and trusting the evidence enough to act on it is where new on-call engineers lose the most time, not in the technical investigation itself. Nobody tells you that explicitly because it sounds like a soft-skills problem, but it cost me fifteen real minutes on an active incident. I now tell every new on-call engineer on our team, explicitly, before their first shift: if the data supports a clear next step, take it or escalate it immediately, don't sit with it. Being wrong and asking early costs a few minutes of someone's sleep. Being right and sitting on it costs the incident.

  • The technical diagnosis is rarely the bottleneck for new on-call engineers — the confidence to act on it is.
  • A climbing trend is actionable evidence regardless of how senior or junior you are; the data doesn't grade on experience.
  • Escalating early with a clear finding is always cheaper than sitting on a correct diagnosis out of self-doubt.
  • Tell new on-call engineers explicitly, before their first shift, that hesitation is the real risk, not being wrong.