A site reliability engineer is a software engineer whose product is uptime. You write code, but the code you care about most is the code that keeps other people's services alive, measured, and boring. The path up this ladder is less about knowing more tools and more about owning bigger promises.
The old operations model had one team shipping features and another team getting paged when those features fell over. Site reliability flips that. You treat operations as a software problem, so when you find yourself restarting the same stuck worker by hand every Tuesday, your job is to make that restart unnecessary, not to get faster at it. The tool that holds this together is the error budget. Your team agrees on a service level objective, say how often checkout requests must succeed, and the gap between perfect and that target is budget the product team is allowed to spend on risky releases. When the budget runs out, launches pause and reliability work jumps the queue. Holding that line with a product manager who has a deadline is the part of the job nobody puts in the posting. You'll also hear the word toil a lot. It means manual, repetitive work that grows as the service grows, and a good SRE team caps how much of the week goes to it. The rest goes to automation, better alerts, capacity planning and fixing the root causes that the last incident review turned up.
You join the on-call rotation as a shadow first, then as secondary. Most of your week goes to runbook fixes, cleaning up noisy alerts, writing small Terraform changes and learning where the logs actually live. You're judged on whether you follow the incident process calmly, write down what you did, and close the tickets you pick up without being chased.
You're primary on call for a set of services and you own their dashboards, alerts and service level objectives. You lead smaller incidents yourself, write the postmortem, and turn its action items into real fixes. People judge you on whether your services page less over time, whether your automation removes toil instead of hiding it, and whether developers come to you before a risky migration instead of after.
You're the incident commander when things get messy across several teams, and you're the one who says a launch isn't ready. Your work shifts toward design reviews, capacity planning for big traffic events, and building the shared platform pieces like deploy pipelines, observability stacks and chaos testing that other teams use. You're judged on the outages that didn't happen because you caught the risk in a design doc.
Here the ladder forks. The staff track sets reliability standards for the whole company, picks the tracing and alerting approach everyone will live with, and untangles the failures nobody else can explain. The manager track hires, runs the on-call health of several teams, negotiates error budgets with product leaders, and protects engineers from burning out. Both are judged on how reliable the company is without them in the room.
These are the things hiring managers and promotion committees look for as proof you've grown, roughly in the order you'll need them.
19% of openings are fully remote.
$107,900 – $164,000
Typical range in the 31 of the newest 60 postings that list pay.
They overlap a lot, and some companies use the titles interchangeably. The honest difference is focus. DevOps roles usually center on build and deploy pipelines and getting code shipped. SRE roles center on how the service behaves once it's live: service level objectives, error budgets, incident response and paging. If a posting talks mostly about CI/CD, it's a DevOps job whatever the title says. If it talks about SLOs and on-call, it's reliability work.
It depends almost entirely on the team. A healthy team has a rotation big enough that your week on call comes around rarely, alerts that only fire when a human needs to act, and time off after a rough night. An unhealthy one pages you for disk warnings in the middle of the night and never fixes the cause. Ask in the interview how many pages the last rotation got and what happened to the noisy ones. The answer tells you more than the job description.
You need to be a real one. Most SRE teams expect you to write and review production code in Go or Python, not just shell scripts. You won't spend your days on product features, but you will build tools, controllers, exporters and automation that other engineers depend on. People who come from systems administration usually find the coding bar is the biggest jump.
Two things come up again and again. The first is on-call fatigue on teams that treat SRE as a place to dump pages instead of a place to fix them. The second is being the person who says no to a launch, over and over, to people who outrank you. If you dislike conflict or need clear, finished projects to feel good about your week, reliability work can feel like shoveling snow while it's still falling.