What does a DevOps engineer do? A real day in the life

Job descriptions describe the role in abstractions — "bridge development and operations," "drive a culture of automation." Useful, maybe, but they tell you nothing about what the hours actually contain. Here is the job at the level of tasks.

New to cloud? CAMPUX is a free, build-first course. Start here →

A DevOps engineer builds and maintains the automated pipelines that test, package, and deploy software; writes infrastructure as code; monitors production systems; and responds when something breaks. On a typical day that means reviewing pipeline runs, tuning alerts, automating a manual task, and — when an incident hits — diagnosing it and rolling back safely. The rest of this note walks through those tasks in the order they tend to arrive, and ends with a real incident, start to finish.

The short answer

Strip away the philosophy and the work sorts into three buckets by rhythm. There is the daily layer — the steady maintenance of the machinery that ships code and watches production. There is the weekly and monthly layer — the slower work of capacity, cost, patching, and looking back at what went wrong. And there is the emergency layer, which ignores your calendar entirely: an alert fires, and everything else waits. Most people picture the job as that third bucket, all firefighting. In a healthy team it is mostly the first two, precisely because the first two keep the third quiet.

A typical day, task by task

The morning usually starts with a scan of what happened while you were asleep. Overnight builds, scheduled jobs, the nightly deploy to staging — did they pass, and if not, why? A red pipeline is not automatically a fire; often it is a flaky test or an expired credential. The task is to tell the difference quickly and either fix the cause or flag it so nobody wastes an hour on a phantom.

Then comes review. Somewhere a teammate has opened a change to the infrastructure — a new rule on a load balancer, a bumped instance size, a fresh Terraform module. Reviewing infrastructure as code is its own discipline: you are reading a diff and picturing the blast radius. Will this replace a resource that holds live traffic? Does it widen a firewall more than intended? Catching that in review costs a comment; catching it in production costs an incident.

The middle of the day is where the small, unglamorous automation lives. A deploy still needs someone to click a button; a certificate renewal is done by hand every ninety days; a report gets assembled manually every Friday. Each is minor on its own. Left alone, they pile into a tax the team pays forever. So you take one — just one — and write the script or pipeline step that removes it. This is the quiet compounding work that makes the role what it is.

Alert tuning threads through all of it. An alert that pages at three in the morning for a blip nobody needed to act on is worse than no alert, because it teaches people to ignore the pager. An alert that never fires when it should is worse still. So you adjust thresholds, add context to the message, route it to the right channel, or delete it. A good monitoring setup is not built once; it is gardened.

The unglamorous automation is the job. The firefighting is what happens when nobody did it.

Weekly and monthly work

Zoom out from the day and a slower set of tasks appears, the kind that never feels urgent until suddenly it is.

• Capacity and scaling. Is traffic trending toward the ceiling of what the current setup handles? Do the autoscaling rules still match reality, or were they tuned for last quarter's load? A launch or a seasonal spike is a bad time to discover the answer.
• Cost. Cloud bills drift upward on their own. Part of the week goes to spotting the oversized database nobody downsized, the storage that was never cleaned up, the test environment left running over a weekend. Trimming waste here is real money, and it is often the most visible thing a DevOps engineer does to the people who sign the checks.
• Patching and updates. Base images, dependencies, and runtimes all age into security holes. Rolling updates through staging and into production on a schedule — rather than in a panic after a disclosure — is steady, necessary work.
• The retrospective. After an incident, and often just on a cadence, the team sits down and asks what happened and what would stop it happening again. The output is not blame; it is a list of concrete changes — a new alert, a fixed runbook, an automated guardrail. Done honestly, this is where a team actually gets more reliable over time.

When the pager goes off: incident response

Now the part everyone pictures. Most teams that own production run an on-call rotation — you carry the pager for a week at a time, every few weeks — and when an alert fires, the ordinary day stops. Here is a concrete one, the kind that happens often enough to be routine.

It is 9:40 on a Tuesday. An alert fires: the checkout service's error rate has crossed five percent, up from its usual near-zero. Thirty seconds earlier, the deploy pipeline had pushed a new version of that service to production. The two facts sitting next to each other are the whole story, and the response is a short, practiced sequence:

1. Confirm it is real. Open the dashboard the alert points to. Errors are climbing in one region and matching the failed requests in the logs — not a monitoring glitch, an actual customer-facing failure. Clock is running.
2. Find the most likely cause fast. You do not need the root cause yet; you need the trigger. The error rate went vertical the moment the new build went live. Correlation this tight, this immediate, points at the deploy. That is enough to act.
3. Stop the bleeding — roll back. Rather than debug the broken version in production while customers fail to check out, you trigger the rollback: the pipeline redeploys the previous known-good build. This is exactly why deploys are automated and versioned — the undo button only exists because someone built it on a calm afternoon.
4. Verify recovery. Within a couple of minutes the error rate falls back to baseline on the dashboard. The alert clears. Customers can check out again. The incident is contained, even though you still do not know precisely what the bad build did.
5. Then diagnose in daylight. With production safe, you pull the broken build apart without pressure. It turns out a configuration value pointed at a database connection setting that did not exist in production. A test that would have caught it was passing against a mock. That finding goes into the retrospective, and the fix is a new pipeline check plus a corrected test — so this exact failure cannot ship again.

Notice what made the loud twenty minutes survivable: the alert existed and was tuned to fire on the right signal, the deploy was versioned so a rollback was one command, and there was a runbook mapping the steps. None of that was built during the incident. It was built during all the ordinary days described above. The incident just spent the savings.

Daily vs weekly vs emergency

The same responsibilities, sorted by when they tend to land:

The skills all this requires

Read back over the tasks and the skill list writes itself, which is a better way to learn than a curriculum handed down cold. You need to be comfortable at the command line and in scripts, because automation is just code you write to stop repeating yourself — much of it is the same everyday work in the Azure CLI cheat sheet. You need enough version control to review changes and untangle history without fear; the difference between git merge and git rebase is the kind of thing you reach for weekly. You need to read infrastructure as code well enough to see what a diff will do before it does it. And you need to think in terms of signals and failure — what to measure, what should page a human, and what the safe move is when it does.

None of that is a gift you are born with. It is a set of habits you build one task at a time, which is exactly how the job itself is done. If you want the wider picture of the role rather than the task list, the companion piece on what a DevOps engineer is covers the definition and the career, and what DevOps actually means covers the culture the tasks sit inside.

Common questions