cvharbor editorial

How to write on-call and incident response on a resume

On-call is where DevOps engineers do their most consequential work and their least legible. Nothing happened is the goal, incidents belong to whole teams, and the numbers live in a tracker nobody outside can see. Here is how to write it down without either underselling it or claiming the team’s work as yours.

Most resumes handle on-call with a single line: "Participated in on-call rotation." It is accurate and it communicates nothing. A reader cannot tell whether that meant a shared rotation with two pages a quarter or primary responsibility for a payments system at 3am. Those are different jobs and the resume treats them identically.

The reason this work is hard to write is structural, not a failure of effort. Successful on-call produces an absence of events. Incidents are resolved by several people at once. The metrics are in an internal tracker. Every instinct that makes for a good bullet elsewhere — a number, a clear owner, a visible outcome — is working against you here.

Describe the rotation before you describe the incidents

The context is what makes any incident story readable. Two lines of setup lets a reader calibrate everything that follows, and it is entirely factual so there is nothing to get wrong.

• The shape of the rotation: how many engineers, how often your shift came round, whether you were primary or secondary.
• What was in scope: which services, and whether they were customer-facing, revenue-carrying, or internal.
• The realistic page volume: roughly how often you were actually woken, not the theoretical worst case.
• Whether you were also the person who wrote the runbooks and alerts, or the person following someone else’s.

Separate what you did from what the team did

This is where most on-call bullets go wrong, and it is the thing an interviewer probes hardest. "Reduced MTTR by 40%" is almost never one person’s doing — it is usually better alerting, better runbooks, a platform change and four engineers responding differently. Claiming the aggregate as a personal result is the fastest way to lose credibility in a follow-up question.

The honest structure names the team outcome and then your specific contribution to it. It reads as stronger, not weaker, because it demonstrates you understand how the improvement actually happened.

Write one incident properly instead of five vaguely

A single incident described end to end does more than a list of categories. Pick one where your contribution was clear, and give it the four parts a reader needs: what broke, how it was found, what you did, and what changed afterwards so it could not happen the same way again.

1. The failure, in plain terms: what stopped working and who noticed.
2. The detection path: whether an alert caught it or a customer did. Both are informative; the second is more so if you then fixed the gap.
3. Your action during the incident: what you actually ran, changed, rolled back or escalated.
4. The follow-up: the postmortem action you owned and shipped. This is the part that separates responders from people who fix systems.

That fourth point carries most of the weight. Anyone on a rotation has handled incidents. The engineers worth hiring are the ones who came back afterwards and removed the class of failure. If you only have room for one on-call bullet, make it that one.

What to do when the numbers are not yours to share

Uptime figures, incident counts and customer impact are often internal, and sometimes contractually confidential. You do not need the absolute numbers. Relative and structural facts carry the same signal and are safe to write: that page volume halved, that a category of incident stopped recurring, that a service went from weekly pages to none in a quarter.

If even that is too specific for your employer, describe the mechanism alone. "Replaced the manual failover procedure with an automated one that had been the cause of the two longest outages that year" tells a reader plenty without publishing a single metric.

Where this belongs on the page

On-call belongs inside the role it happened in, not in a separate section. A standalone "On-Call Experience" heading detaches it from the systems and the scale that make it meaningful, and it reads as padding. Two lines under the relevant role — rotation shape, then your strongest incident-and-follow-up — is the right weight for most resumes.

Want to see whether your incident bullets read as your own work or the team’s? Check your resume