The incident at 2am: why I actually enjoy on-call

On my CV, under the About section, there's a line: "I'm drawn to the unglamorous parts of engineering: the incident at 2am, the network that won't come up, the pipeline that keeps failing." People ask me if I actually mean that. I do.

Here's why, and what I think people misunderstand about it.

Incidents don't lie

Normal engineering work is ambiguous. A feature that ships looks like success. A refactor that goes smoothly feels like progress. But you're never sure how much of that was skill and how much was favourable conditions. Incidents cut through that. When something breaks at 2am and people are paging you, there's no hiding — either you can navigate the system under pressure or you can't.

I find that clarity motivating rather than stressful. The ambiguity disappears. The problem is real, the feedback is immediate, and the outcome matters. That's a good environment to learn in.

What you learn from a real incident

You learn what the system actually is — not what the documentation says it is. You find the undocumented dependency, the config that drifts, the assumption that was never tested under load. These discoveries are genuinely useful. They improve runbooks, they drive reliability investment, they change how you build the next thing.

You also learn about yourself. How do you think when you're tired and under pressure? Do you spiral into every possible cause, or do you form and test hypotheses systematically? Do you communicate clearly with the team, or do you go quiet and solo? These are things you can only discover in the moment.

An incident is the most honest performance review a system — and an engineer — can get.

The part people get wrong

When I say I enjoy on-call, people sometimes hear "I enjoy staying up until 3am." That's not it. I enjoy the diagnostic process. The moment you form a hypothesis, run a query, and the data confirms it — that's satisfying regardless of the hour.

What I don't enjoy is unnecessary incidents. The ones caused by a change that didn't go through review, by a runbook that was never updated, by an alert threshold that was set once and never revisited. Those are avoidable, and they're the ones that make on-call genuinely miserable. The goal isn't to have more incidents — it's to make each one count.

Why it matters for hiring

I mention this on my CV specifically because a lot of cloud and infrastructure roles involve operational work — incident response, change management, keeping production stable. Some engineers treat that as the boring part they have to get through between the interesting projects. I treat it as the main event.

If you're hiring for an SRE or cloud infrastructure role and you want someone who leans into the operational side rather than tolerating it, that's what I'm signalling. The 2am framing is deliberate.