How to put on-call, incident and maintenance work on a resume

Put on-call experience inside the job where you did it, as one or two bullets. Name the service you were on call for, how the rotation worked, and what you changed because of what the pager showed you. The rotation alone says you were available. The change you made says you are good at the job.

This post is for engineers whose last role was mostly keeping systems running: on-call, incidents, upgrades, migrations and bug fixing.

Should you put on-call experience on your resume?

Yes, if you were on call for a production system. For backend, platform, DevOps and SRE roles it is direct evidence that you have run software in production, and hiring managers for those roles often ask about it. For frontend and mobile roles it matters less, so one line is enough:

- Secondary on-call for the web checkout; added the client-side error alerts the rotation now uses to catch broken releases

Keep it inside the employer entry. A separate "On-call" section or a line in your skills list separates the duty from the system, and the system is the interesting part.

Write the rotation as a fact, not as a sacrifice. "Primary on-call one week in five" is information. "Available 24/7" and "handled high-pressure outages around the clock" tell the reader about your hours, not your work.

Before:
- Participated in on-call rotation and handled production issues

After:
- Primary on-call one week in five for the payments API (Go, PostgreSQL); cut weekly pages from about 30 to 6 by deleting duplicate alerts and fixing the two retry bugs behind most of the rest

How do you write bullets about incidents and postmortems?

Most of what you did on call is not worth a bullet. Acknowledging pages, restarting pods and following a runbook are the job. What belongs on the resume is the work that changed the system afterward.

These are the reliability numbers an engineering reader will recognize. You can usually find them in your paging tool's reports, your incident tracker or your SLO dashboard:

• Pages per week or per shift, before and after you tuned the alerts.
• Alert noise: the share of pages that needed no action.
• Time to restore service for a class of incident. MTTR is a common abbreviation, but teams use it for recovery, repair, restore or resolve, so write the words out once.
• SLO attainment: for example, the checkout service meeting its 99.9% availability target for four quarters in a row.
• Repeat incidents: how often the same failure came back after a postmortem.

The first reader may be a recruiter rather than an engineer. Put the plain result in the bullet ("fewer pages", "faster recovery") next to the technical term, so both readers get something from it.

For a postmortem, the bullet is the fix that came out of it, not the meeting. If you led the response, say so and say how large the incident was. If you were one responder of several, describe your part.

Before:
- Led postmortems for production incidents

After:
- Incident commander for a 3-hour checkout outage caused by connection-pool exhaustion; wrote the postmortem and shipped the per-tenant pool limits that stopped it from recurring

Our senior site reliability engineer resume example has an on-call bullet of this kind under its current role at Streamio:

Streamio, Dublin, Ireland
Senior Site Reliability Engineer | 2020 – Present
- Automated incident response runbooks and on-call rotations, shortening mean time to recovery from 42 minutes to 21 minutes

Resume example

Senior Site Reliability Engineer Resume Example

An on-call result written next to deployment and infrastructure ownership under one role.

View the full example

It gives both values of the recovery time, so an interviewer can ask how it was measured. Expect the follow-up question too: which runbook steps were automated, and why that halved recovery time. Have that answer ready for any reliability number you use.

If you have no numbers at all, describe scope instead: the services you were on call for, who depends on them, and the runbooks or dashboards that exist because of you. Our post on writing bullets without metrics covers this in more detail.

How do you turn migrations, upgrades and bug fixing into achievements?

Write each one as a finished change to a named system. A ticket title describes the activity; the bullet should describe the state of the system after you were done.

Migrations. Say what you moved from and to, how much moved, the constraint you worked under, and whether the old system was shut down. A migration that is still half done is worth less than one that ended with the old system removed, so say which it is.

Dependency and framework upgrades. A major version upgrade across a large codebase is real work: breaking API changes, deprecated libraries to replace, tests to fix. Name the versions and the size. "Upgraded dependencies" says nothing. "Moved 14 services from Spring Boot 2.7 to 3.2 and Java 11 to 17" says a lot.

Bug backlogs. One bug fixed is a ticket. A backlog reduced, a class of bugs eliminated or a crash rate lowered is a result. Group the fixes by cause or by outcome, then write the group as one bullet.

Before:
- Fixed bugs reported by QA and customers
- Upgraded libraries and resolved security vulnerabilities

After:
- Took the open bug backlog for the billing service from about 140 tickets to 35 in two quarters, starting with the invoice rounding errors behind most support escalations
- Cleared all critical and high dependency vulnerabilities across 9 Node.js services and set up automated dependency update pull requests to keep them current

The mid-level Android developer resume example writes a legacy rewrite as a result: "Refactored legacy codebase to Kotlin, reducing crash rate by 45% and halving onboarding time for new devs." The work is a refactor, and the bullet is about what it changed. Your own version would be stronger with the crash rate before and after, for the same reason as the Streamio bullet.

Before and after rewrites for backend, DevOps and mobile

Backend. The original describes a duty. The rewrite names the service, the cause of the incidents and the end state.

Before:
- Responsible for maintaining the orders service and fixing production issues

After:
- Owned the orders service (Java, Kafka), including its on-call; traced a recurring duplicate-order incident to non-idempotent consumers and added idempotency keys, ending an incident that had occurred 11 times that year

DevOps and SRE. The original lists tools. The rewrite says what the tools now do and what that changed for the rotation.

Before:
- Managed monitoring with Prometheus, Grafana and PagerDuty

After:
- Rebuilt alerting around SLO burn rates for 25 services, replacing about 300 threshold alerts; the share of pages needing no action fell from about half to under 10%

Mobile. Mobile engineers are often not on a pager, but release health is the same kind of work. Crash-free rate, app hangs and hotfix releases are the reliability numbers.

Before:
- Worked on app stability and handled crash reports

After:
- Ran crash triage for the iOS app each release; fixed the three crashes behind most crash reports and raised the crash-free session rate from about 99.2% to 99.8%

How do you describe a role that was mostly maintenance?

Write it as ownership. "Kept the system running" becomes "owned the system", followed by what it does, who depends on it and what state you left it in.

Order the bullets by weight, not by time spent. Start with one line that says what you owned, then put your most significant design or feature work directly after it, even if it took 20% of your time. Some interviewers read a resume of only bug fixes as a sign that you have not built features, so include every piece of design or feature work you did, even small pieces.

Do not overstate. If you inherited a system, do not write "built". If you kept a legacy platform alive while another team replaced it, say that. It is a reasonable role and an interviewer will ask about it either way.

Halvard Freight, Hamburg, Germany
Backend Engineer | Apr 2021 – Present
- Own the legacy shipment-tracking platform (PHP, MySQL) used by 40 warehouse sites while a separate team builds its replacement
- Designed and built the carrier-event webhook service in Go that the new platform now also consumes
- Primary on-call one week in four; wrote runbooks for the eight most frequent alerts so new team members can take shifts in their first month
- Upgraded the platform from PHP 7.2 to 8.1 and MySQL 5.7 to 8.0 with no customer-facing downtime
- Reduced nightly batch failures from several a week to about one a month by adding retries and dead-letter handling to the import jobs

The first bullet states the replacement plainly. The second is the only feature in the role, placed where a skimming reader will see it.

Work for the on-call rotation can also be one line among feature work. The senior backend engineer resume example has "Designed the monitoring and alerting for 20+ services and wrote the incident runbooks used by on-call engineers." It shows production ownership without making the role about the pager.

What should you leave out?

• Activity counts. "Resolved 600+ tickets" and "responded to 150 incidents" measure volume, not skill. Use the counts to find patterns, then write the pattern.
• Hours and availability. Night pages, weekend shifts and "24/7" describe your schedule. If you want to show the scale of the rotation, give the rotation size and the services covered.
• Confidential incident details. Do not name affected customers or give revenue lost. Describe the failure and the fix in technical terms, and use a generic description ("the payments API") instead of an internal service name.
• Blame. "Fixed outages caused by the platform team" reads badly whoever was at fault.
• Incidents you only watched. Being in the incident channel is not responding. List the incidents where you did something specific.
• Every tool on the rotation. PagerDuty, Opsgenie, Datadog and Grafana belong in the skills section, or once in the bullet where they did something. Our post on where to list your tech stack covers this.