At some point every growing SaaS company hears that it needs SRE. Maybe a large customer asked about your uptime target, maybe an investor mentioned it, maybe an outage made the case on its own. Site reliability engineering is a real discipline with useful ideas, but the job title and the practices are not the same thing, and a 15-person startup rarely needs the former. This post explains what SRE is, how it relates to DevOps, where the two overlap, and what a small team should actually put in place first. It also takes an honest look at “AI SRE,” the newest version of the question.

What site reliability engineering is, and how Google started it

SRE started at Google, and Google’s own definition is short: “SRE is what happens when you ask a software engineer to design an operations team.” Instead of a separate operations group running software that developers throw over the wall, SRE treats running production as a software problem, solved with code, measurement and explicit tradeoffs.

Google’s free Site Reliability Engineering book introduced a handful of ideas that have spread far beyond Google. Four of them matter most.

SLIs and SLOs

A service level indicator (SLI) is a measurement of what users experience, such as the share of requests that succeed or the share served in under 300 milliseconds. A service level objective (SLO) is the target for that measurement over a window, for example 99.9% of checkout requests succeed over 30 days. An SLA is the contractual promise, with penalties, that you make to customers. It should be looser than your SLO, so you notice trouble before it costs you money.

The point of an SLO is to define “reliable enough.” Without one, every incident becomes a debate about whether it was bad, and every reliability project competes with features on gut feeling.

Error budgets

If your SLO is 99.9%, you are allowed 0.1% failure. That allowance is the error budget. Google describes it as a resource that development and operations spend together: while budget remains, ship features quickly; when it runs out, slow down and spend effort on reliability. An error budget policy writes that agreement down in advance, which turns a political argument into a rule everyone accepted while calm.

Toil

Google defines toil as work that is “manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows.” Restarting a stuck worker by hand, rotating a credential through the console, copying a database for a customer: if it comes back every week and a machine could do it, it is toil. Google caps operational work for its SRE teams at half their time, so the other half goes to engineering that removes the toil.

Blameless post-mortems

After an incident, SRE teams write a post-mortem that focuses on contributing causes, not on who made the mistake. We cover this in detail in our post on incident management for SaaS.

What DevOps is

DevOps is older as a term and broader as an idea. It is a set of cultural and technical practices for getting developers and operations working as one team, so software moves from commit to production quickly and safely. In practice that means continuous integration and delivery, infrastructure as code, automated testing, monitoring, and shared ownership of production. Our post on the principles of DevOps covers the basics.

DevOps describes what good looks like. It is deliberately not prescriptive about how to measure it or what to do when speed and stability conflict.

Site reliability engineering vs. DevOps: how they overlap

Google’s own framing is that the two are complementary. The SRE workbook puts it as “class SRE implements interface DevOps”: DevOps is the interface, a set of principles, and SRE is one concrete, opinionated implementation of it.

	DevOps	SRE
Core question	How do we ship faster and safer together?	How reliable should this be, and how do we keep it there?
Main tools	CI/CD, infrastructure as code, automation, shared ownership	SLOs, error budgets, toil reduction, incident practice
Measures	Delivery speed and stability	User-facing reliability against a target
When speed and stability conflict	Culture and judgment	The error budget decides
Typical home	Everyone, often with a platform or DevOps role	A specialist team, at larger companies

Both value automation, measurement and shared responsibility for production. The difference is emphasis. DevOps work is mostly about the path to production: pipelines, environments, infrastructure. SRE work is mostly about what happens once you are there: availability, latency, capacity and incidents.

What a small SaaS team needs first

For a startup without a dedicated operations team, the answer is almost always DevOps foundations first, with a few SRE practices borrowed early. Hiring an SRE team is something to consider much later, if ever.

The reason is order of operations. SRE practices assume you can measure, deploy and roll back reliably. If deploys are manual, environments drift, and there is no alerting beyond customers emailing support, an SLO is a number nobody can act on. Fix the delivery path first:

Automated, repeatable deploys with a tested rollback.
Infrastructure as code, so environments can be rebuilt and reviewed.
Monitoring and alerting on the things users notice: errors, latency, availability.
An on-call arrangement that does not depend on one person.

Then borrow the SRE ideas that cost little and pay off quickly:

One or two SLOs for the journeys that matter most, such as login and checkout. Start with loose targets and tighten them as you learn.
Alerts based on user impact, not on every CPU spike. Alert when the SLO is at risk.
Blameless post-mortems for any customer-visible incident.
A toil list. Write down the manual tasks that keep coming back and automate one a month.

Skip, for now, the full apparatus: formal error budget policies across many services, dedicated SRE headcount, and elaborate capacity planning. Revisit them when you have multiple teams shipping into the same production environment and reliability disputes start slowing you down. Our post on scaling your startup with DevOps and when to hire a full-time DevOps team cover the staffing side.

What about AI SRE?

“AI SRE” usually describes software that uses large language models and your observability data to investigate alerts: pulling logs, metrics and traces, correlating them with recent deploys, and proposing likely causes. It is a real and useful category. It is also easy to oversell.

What AI does well in operations today:

Watching continuously and noticing patterns across more signals than a tired human at 3am.
Gathering context fast: the recent deploy, the related alerts, the runbook, the last similar incident.
Drafting: timelines, status updates, post-mortem first drafts and summaries.
Routing: deciding who should see an alert and how urgently.

What it does not do reliably:

Find root causes on its own. In an August 2025 experiment by ClickHouse, five frontier models investigated injected faults in a demo application with full telemetry access, and the authors concluded that autonomous root cause analysis “is not there yet.” Models improve quickly, but the safe pattern is still to treat an AI finding as a hypothesis.
Make judgment calls. Rolling back, failing over or telling customers about an outage involves business context and accountability that belong to a person.
Replace the practices. An AI agent without SLOs, runbooks and clean alerts is investigating noise.

The honest framing is that AI takes over a large share of the watching and the first analysis, and humans still make the decisions and ship the fixes.

Frequently asked questions

What exactly does a site reliability engineer do?

A site reliability engineer runs production systems using software engineering. In practice that means defining SLIs and SLOs with product teams, using error budgets to balance features against stability, automating toil away, carrying the pager and leading incident response and blameless post-mortems. At Google, operational work is capped at half an SRE’s time so the rest goes to engineering that makes the system easier to run.

What is an SRE vs DevOps?

DevOps is a broad set of cultural and technical practices for shipping software quickly and safely as one team. SRE is a specific, opinionated way to implement those practices, built around reliability targets and error budgets. Google’s SRE workbook sums it up as “class SRE implements interface DevOps.”

Is AI replacing SRE?

Not today. AI tools are good at watching signals continuously, gathering context, drafting timelines and routing alerts, but in ClickHouse’s 2025 experiment frontier models could not yet find root causes on their own. Decisions such as rolling back, failing over or telling customers still need a person, so AI changes the SRE workload more than it removes the role.

How Webera approaches it

That split is how Webera works. Webera is a DevOps subscription for SaaS teams on AWS, run by senior engineers working with nine AI agents. Sentinel handles observability, including tracking SLOs and capacity trends. Dispatcher designs on-call schedules and routes incidents by severity. Conductor builds the CI/CD pipelines and rollback procedures that come first in the list above. The agents watch, route and do the first analysis around the clock; the engineers make the calls.

Every plan includes 24/7 monitoring and incident response, unlimited requests and all nine agents. Pro is $4,999 a month, Elite $9,999 and Platform $14,999, with a three-month minimum and then month to month. You own all the code.

If you want DevOps foundations and the useful parts of SRE without building a team for each, compare the plans. And if cost is the other thing keeping you up, read our AWS cost optimization playbook.

Site Reliability Engineering vs. DevOps: Which Does a SaaS Startup Need First?