When checkout latency creeps up at dinner time, a site reliability engineer is the person who can say how much reliability the service has left to spend this month, which dashboard proves it, and whether the next release should wait. SREs treat keeping production healthy as an engineering problem. They measure what users experience, write software to remove repetitive operations work, and lead the response when things fail.
Here you will find a site reliability engineer job description you can copy and edit, along with what changes between levels, how to test the skills that count, the ad mistakes specific to this title, and a guide to choosing contract or permanent hiring. Since SRE is often used loosely, the page also explains where it stops and DevOps begins.
Site reliability engineer job description template
Swap the bracketed items for your own services and tooling. Be especially exact about on-call, because that one line decides whether experienced SREs apply.
About the role
[Company] is hiring a Site Reliability Engineer to keep [product or platform] dependable as it grows. You will define how we measure reliability, improve observability across our services, take part in incident response and build automation that reduces manual operations work. You will join [team name], report to [manager title] and be based in [city / remote].
Responsibilities
- Define SLIs and SLOs with product and engineering teams for [critical user journeys], and publish them where everyone can see them.
- Track error budgets, and use an agreed policy to decide when reliability work takes priority over new features.
- Build and maintain observability using Prometheus, Grafana and OpenTelemetry across metrics, logs and traces.
- Replace noisy threshold alerts with symptom-based alerts tied to SLO burn rate.
- Join the on-call rota, and act as incident commander or responder during major incidents.
- Run blameless postmortems, and follow corrective actions through to completion.
- Measure toil, then write tools in [Python / Go] that remove the largest sources of it.
- Forecast capacity for [Kubernetes clusters, databases and queues] and plan load tests ahead of expected peaks.
- Review the design of new services for failure modes, timeouts, retries and graceful degradation.
Requirements
- [X] years in SRE, production engineering or a software role with real operational ownership.
- Working fluency with SLIs, SLOs and error budgets, and experience applying them to a live service.
- Coding ability in [Python / Go / Java], good enough to ship and maintain internal tools.
- Strong troubleshooting across Linux, networking, containers and Kubernetes.
- Hands-on use of Prometheus, Grafana or a comparable observability stack.
- Direct experience of on-call and of leading or supporting production incidents.
- Clear written communication, since postmortems and status updates are part of the work.
Nice to have
- Experience instrumenting services with OpenTelemetry from scratch.
- Chaos engineering or structured game day practice.
- Database reliability experience, such as failover, replication and connection management.
- Multi-region traffic management on [AWS / Azure / Google Cloud].
What we offer
- [Pay range], including [on-call allowance or time off in lieu].
- A rota of [rota size] engineers with [primary and secondary cover details].
- [Work arrangement] and [learning budget].
How the site reliability engineer role changes by level
Junior SRE
True junior SRE posts are rare, because the job relies on having seen systems fail. Where they exist, the person shadows on-call, improves dashboards, automates small tasks and fixes alert noise under supervision. Look for software or systems fundamentals and curiosity about how things break.
Mid-level SRE
At this level the engineer takes primary on-call, owns SLOs for several services and runs postmortems. They should be able to find a problem across layers without help, from a slow query to a saturated connection pool. Requirements should ask for real incidents, described in detail.
Senior SRE
A senior shapes reliability practice across teams. They negotiate SLOs with product leaders, design capacity plans, push back on risky launches using error budget data and mentor the rota. Their output is often less code and more changed behaviour among other engineers.
Staff or principal SRE
Only larger organisations need this level. The person sets multi-year reliability direction, leads the hardest cross-service failures and designs for regional resilience. If you have a handful of services and one cluster, advertising at this level will produce a poor fit on both sides.
Site reliability engineer skills that matter most, and how to check them
- SLO design. Ask the candidate to choose an SLI for a payments API. Strong answers measure success and latency close to the user, explain why CPU usage is a poor indicator, and describe what the team does once the budget runs out.
- Incident reasoning. Run a live scenario: error rates rise after no deployment at all. Watch whether they establish impact first, form a hypothesis, check recent dependency or traffic changes, and mitigate before hunting for the root cause.
- Alert quality. Ask how they would treat a rota that gets paged all night for issues that clear themselves. Good candidates review each alert for whether it needs a human, then delete or demote the rest.
- Software engineering. Ask for a tool they wrote that removed toil, then read a little of the code together. SRE without coding quickly turns into plain operations under a new title.
- Postmortem writing. Request an anonymised postmortem or have them write one from a short timeline. Check for contributing factors, specific actions and an absence of blame on individuals.
Asking someone to narrate their worst outage is the most reliable single prompt for this role. Follow up on what they would do differently, and be wary if every story ends with someone else at fault.
Common site reliability engineer job description mistakes
- Renaming an operations team as SRE. If the work is watching dashboards and restarting services, real SREs will spot that during the first call. Fix: protect time for engineering in the ad, or use an operations title.
- Listing no SLO or error budget work. A post that mentions uptime but never says how it is measured suggests the practice does not exist. Fix: say where you are on that journey, even if the honest answer is that you are starting from nothing.
- Vague on-call terms. Rota size and compensation are the first things applicants look for. Fix: state how many engineers share the rota and how night work is recognised.
- Asking for a DevOps engineer under another name. A list of pipeline tools and Terraform modules describes delivery work, with reliability as an afterthought. Fix: lead with SLOs, incidents and observability, and mention CI/CD only as context.
- Celebrating firefighters. Wording that praises firefighting attracts people who enjoy outages and discourages those who prevent them. Fix: describe the reduction of incidents and toil as the goal.
Contract, contract-to-hire or permanent: which suits a site reliability engineer
Contract SREs are useful for bounded improvement work: setting up OpenTelemetry and dashboards across services, introducing a first set of SLOs, cleaning up alerting or preparing for a known traffic event. Agree beforehand whether the contractor will carry the pager, because that decision affects both the scope and how much context they need.
Contract-to-hire is a sensible way to test how someone behaves in a real incident on your systems. Reliability work depends heavily on trust between the SRE and product engineers, and that relationship only shows up over a period of working together.
Permanent hiring fits best for most SRE roles. The value comes from long familiarity with how your services fail, and a rota is hard to sustain with short-term cover. Zilo AI supports each option and can hire site reliability engineers in India on contract, contract-to-hire or permanent terms. Companies building a broader infrastructure group can browse other roles on the IT talent hub.
Frequently asked questions
What should a site reliability engineer job description include?
Cover the services the person will be responsible for, your current SLO maturity, the observability stack, the on-call arrangement and the balance between operations and engineering. Applicants read that balance closely, so state it in plain language.
What is the difference between SRE and DevOps?
DevOps is mainly concerned with how change moves into production, while SRE is concerned with how the service behaves for users afterwards. SREs have numeric reliability targets and the authority to slow releases when those targets are at risk. The two share tools such as Kubernetes and Terraform.
What do SLI, SLO and error budget mean?
An SLI is a measurement of service behaviour, such as the share of successful requests. An SLO is the target set for that measurement. The error budget is the amount of unreliability the SLO allows, and teams spend it on releases and experiments.
Does an SRE need to be a software engineer?
They need real coding ability, even if they came from a systems background. Without it they cannot automate away toil, and the role slides back into manual operations. Test it directly in the interview rather than trusting the CV.
When does a company need its first SRE?
Usually when outages begin to affect revenue or customer trust, and developers are spending a growing share of their week on production issues. Before that point, a good DevOps engineer with basic monitoring is often enough.
Prefer to skip the sourcing and meet screened candidates instead? Zilo AI can take on the search. Talk to us about your services, your rota and the reliability targets you are working towards.