DevOps is among the most measurable disciplines in technology — deployment frequency, lead time, failure rate, recovery time and cloud spend are all tracked as a matter of course. Which makes it striking how many DevOps CVs contain no numbers at all, listing tools instead. That gap is the single biggest opportunity available to you.
Speak in DORA metrics
The four DORA metrics are the shared vocabulary of the discipline, and hiring managers use them to compare candidates directly:
- Deployment frequency — how often you ship
- Lead time for change — commit to production
- Change-failure rate — what proportion of deploys cause a problem
- Mean time to recovery (MTTR) — how fast you recover when they do
The most persuasive DevOps bullet shape moves speed and stability together, because improving one at the cost of the other is easy and improving both is the actual job: "Raised deploy frequency from weekly to 40x/day while cutting change-failure rate from 18% to 4%."
Alongside DORA, two more families of number carry weight: reliability (uptime against SLO, incident volume, alert and page counts) and cost (monthly cloud spend reduced, in percentage and absolute terms).
Before and after: DevOps bullets
Weak: "Managed CI/CD pipelines and automated deployment processes."
Strong: "Rebuilt 30 Jenkins pipelines as reusable GitHub Actions workflows, cutting mean pipeline time from 22 to 6 minutes and lifting deploy frequency from weekly to 40x/day."
Why: managing pipelines is the role's baseline. The migration scope, the time saved and the deployment-frequency change tie the work to the metric the discipline is judged on.
Weak: "Responsible for cloud infrastructure and cost optimisation on AWS."
Strong: "Cut AWS spend 34% ($780k/yr) by rightsizing 200 over-provisioned instances, moving batch workloads to spot, and adding per-team cost alerting — with no SLO regression."
Why: cost bullets are only credible with a reliability caveat attached, because anyone can save money by degrading service. Naming three mechanisms shows the analysis; "no SLO regression" pre-empts the obvious challenge.
Weak: "Monitored systems and responded to incidents as part of the on-call rotation."
Strong: "Cut MTTR from 47 to 12 minutes by replacing 140 threshold alerts with 18 SLO-based ones and adding runbook links to every page, reducing after-hours pages ~70%."
Why: being on-call is participation, not achievement. The alert reduction demonstrates judgement about signal versus noise — and after-hours page volume is a number every hiring manager instantly understands.
A summary that positions you
DevOps engineer with 6 years running Kubernetes platforms for regulated fintech. Took deploy frequency from weekly to 40x/day while cutting change-failure rate from 18% to 4%, and reduced AWS spend 34% ($780k/yr) through rightsizing and spot adoption. Owns SLO definition and the blameless postmortem process.
Skills worth listing
Core: infrastructure as code, Kubernetes operations, CI/CD design, observability and alerting, incident response, cloud cost management, Linux and networking, scripting, secrets management.
Tools: Terraform, Kubernetes, Docker, AWS, Azure, GCP, GitHub Actions, Jenkins, ArgoCD, Helm, Prometheus, Grafana, Datadog, Ansible, Vault, Bash, Python.
List these compactly. A wall of forty tools is the characteristic DevOps CV mistake — it reads as exposure rather than depth, and it crowds out the numbers that would actually differentiate you.
What gets DevOps CVs rejected
- Tool lists with no metrics. The dominant failure, and unusually costly here because the metrics are so readily available.
- No incident stories, which suggests you have not carried production responsibility.
- "Automated processes" with no before/after timing.
- Cost savings with no reliability context, which reads as risk-taking rather than engineering.
DevOps or SRE?
They overlap but weight differently. DevOps centres on delivery — pipelines, infrastructure as code, developer experience — measured on how fast and safely teams ship. SRE centres on reliability of running systems, formalised through SLOs and error budgets, with more software engineering and more on-call. Loops reflect this: SRE includes more coding, DevOps more tooling and pipeline design. Position your CV for whichever you are applying to.
Next steps
See DevOps engineer CV examples with level-by-level positioning, or work through DevOps interview questions — including the live troubleshooting round that carries the most weight. You can also check your CV's ATS score free.
Keywords that decide whether you surface
Recruiters search their applicant database by product name, so the practical function of a tool on your CV is to place you in the result set. Name specifics rather than categories — "container orchestration" does not match a search for "Kubernetes".
- Cloud: AWS, GCP or Azure, with the specific services you actually operated — EKS, ECS, Lambda, RDS, CloudFront, GKE, Cloud Run, AKS.
- Orchestration and containers: Kubernetes, Docker, Helm, ArgoCD, Istio or Linkerd if you ran a mesh.
- Infrastructure as code: Terraform, Pulumi, CloudFormation, Ansible, Chef or Puppet.
- CI/CD: GitHub Actions, GitLab CI, Jenkins, CircleCI, Buildkite, Spinnaker.
- Observability: Prometheus, Grafana, Datadog, New Relic, OpenTelemetry, Loki, ELK, Splunk, PagerDuty.
- Practices: SRE, SLO and error budgets, incident response, blue-green and canary deploys, chaos engineering, GitOps, platform engineering, FinOps.
List only what you would be comfortable being questioned on for ten minutes. A padded tools section is a list of topics you have invited into your interview.
What changes by level
Junior and associate. Evidence that you have operated something real. A homelab or personal cluster genuinely counts here if it is described concretely — what you built, what broke, what you learned. Certifications carry more weight at this level than any other.
Mid-level. Ownership of pipelines, infrastructure or a platform component, plus on-call. This is where the DORA numbers start doing the heavy lifting, and where an incident you personally resolved becomes the strongest bullet available to you.
Senior and staff. Scope widens from systems to decisions and their consequences: the migration you designed, the platform other teams build on, the standard you set, the cost programme you ran. Reviewers are reading for judgment, which means bullets should carry a decision and its reasoning rather than only an outcome. "Chose managed Kubernetes over self-hosted despite the cost premium, because our on-call rotation was three people and control-plane maintenance was the largest source of out-of-hours pages" says more about seniority than any metric.
Two things that quietly weaken DevOps CVs
The certification wall. Six cloud certifications listed above your experience reads as compensation for thin operational history, not as strength. Put them in a compact block near the bottom unless you are early in your career.
Claiming the team's metrics as yours. Platform improvements are almost always collective. "Reduced MTTR from 4 hours to 20 minutes" invites an obvious question about what you specifically did. Name your contribution inside the team result: "As part of a three-person platform team, I owned the alerting rework that took MTTR from roughly 4 hours to 20 minutes." Precision here reads as senior, not modest.
Format
One page under about ten years, two beyond it. Single column, standard headings, contact details in the body rather than a document header — the same parsing rules apply to you as to everyone else, and the irony of an automation specialist submitting an unparseable document is not lost on reviewers.
Check yours with the free ATS checker, which shows the extracted fields as well as a score.