What Is SRE? Site Reliability Engineering Explained

You do not need a team of ten to practice site reliability engineering. The term comes from Google, where Ben Treynor Sloss coined it in 2003 to describe what happens when you ask software engineers to run production systems instead of hiring traditional operations staff. But the core ideas (set reliability targets, measure them, automate the repetitive work) apply to a two-person startup just as well as they apply to a company running millions of servers.

SRE is sometimes confused with DevOps. The short version: DevOps is a philosophy (break down silos, ship continuously, share responsibility). SRE is a prescriptive way to implement that philosophy. Google summarizes the relationship as "class SRE implements DevOps." Where DevOps says what to aim for, SRE provides specific tools: error budgets, SLOs, a 50% cap on manual operational work (what SRE calls "toil"), and blameless postmortems after incidents.

Error budgets and the trade-off they enforce

An SRE team sets an SLO for each service, say 99.9% availability over a rolling 30-day window. The gap between that target and 100% is the error budget: roughly 43 minutes of allowed downtime per month. As long as the budget has room, the team ships features freely. When incidents eat through the budget, feature work pauses and engineering effort shifts to reliability fixes. This turns the usual tension between "ship faster" and "keep things stable" into a measurable, data-driven decision instead of a recurring argument.

Monitoring as the foundation

None of this works without reliable monitoring data. The Google SRE book defines four golden signals every service should track: latency, traffic, errors, and saturation. You cannot set an SLO if you are not measuring uptime. You cannot calculate an error budget if you are not catching failures. Uptime monitoring and cron job monitoring cover the detection side: is the service responding, and are scheduled tasks completing on time? Multi-channel alerts handle the notification side, getting the right person paged through Slack, SMS, or PagerDuty before the error budget takes a bigger hit. Incident management captures the timeline so the postmortem has real data to work from, not guesswork.

A full SRE practice also involves distributed tracing, log aggregation, capacity planning, and deployment automation. Monitoring and alerting are one piece, but they are the piece everything else depends on.

Related terms: SLO, SLI, SLA, MTTR, runbook, incident management