Skills / Software-engineering

Site Reliability Engineering

SRE is what you get when you treat operations as if it's a software problem.

Site Reliability Engineering (SRE) is Google's prescriptive framework for applying software engineering principles to operations — quantifying reliability targets, governing feature velocity with error budgets, and eliminating toil through automation. Developed by Ben Treynor Sloss at Google in 2003 and codified in two O'Reilly books, SRE gives engineering teams the formulas, templates, and decision rules to move from firefighting to systematic reliability management. It's built for SREs, DevOps engineers, and engineering leaders who want concrete answers, not philosophy.

By Ben Treynor Sloss  ·  Free

Use this skill See it in action

Specimen 01 · Live diagnosisSite Reliability Engineering

Input

“We keep having this fight between our dev and ops teams. Dev wants to ship fast, ops says we're too unstable to ship. Nobody has data. I think we…”

Diagnosis

I'm your SRE practice guide, built on Google's Site Reliability Engineering methodology.

Full transcript ↓

Calibrated referenceagent-skills.ai

The gap

Run production like a software engineer — measure reliability, manage it with math

SRE is built on a tightly interlocking set of quantitative frameworks. The Service Level Framework defines SLIs (measurable user-facing indicators like latency < 200ms), SLOs (target thresholds like 99.9% availability), and SLAs (contractual commitments). Error budgets — calculated as 1 minus the SLO target — translate reliability targets into a concrete allowance for downtime and risk, which governs release velocity: when the budget is depleted, new releases stop until reliability is restored. The 50% Toil Ceiling mandates that no SRE spend more than half their time on manual, automatable operational work; the remainder must go to engineering that eliminates future toil. Blameless Postmortems follow a canonical five-section template (timeline, root causes, contributing factors, impact, action items with owners and deadlines). Production Readiness Reviews (PRRs) gate service launches with a checklist covering monitoring, alerting, runbooks, rollback, and SLO definitions. The Four Golden Signals — latency, traffic, errors, and saturation — provide a universal monitoring framework applicable to any service.

The problem

Engineering teams operating without SLOs are stuck in a subjective tug-of-war: dev teams push for faster releases, ops teams push back on reliability grounds, and neither side has data to win the argument. Incidents get reviewed in blame-laden retrospectives that produce no systemic change. On-call engineers burn out responding to noisy, non-actionable alerts at 3am. SRE exists specifically to replace this dysfunction with quantified targets, mathematical decision rules, and structured processes that remove the subjectivity.

The solution

Leave every conversation with a concrete artifact — a calculated error budget and release-gating policy, a completed postmortem with action item owners, or a PRR checklist with clear pass/fail gates — not a list of best-practice suggestions.

You bring

Your service's user-facing behaviors and what 'working correctly' means to your users
Current incident history, on-call load, and any existing monitoring or alerting setup
Business context: your release velocity goals, customer SLA commitments, and acceptable downtime windows
A specific trigger: postmortem to write, SLO to set, PRR to complete, or on-call rotation to redesign

You get

A complete SLO document with SLI definitions, target thresholds, error budget math, and a formal error budget policy with release-gating rules
A completed blameless postmortem using the canonical SRE template: timeline, root causes, contributing factors, impact quantification, and action items with owners and due dates
A customized Production Readiness Review checklist gated to your service type, with pass/fail criteria for monitoring, runbooks, rollback, and alerting
A toil percentage calculation and concrete automation recommendations to get below the 50% ceiling

In action

Watch the methodology work.

Three specimens from a single real session: the same situation, unaided and calibrated, the full transcript, and the skill answering live in the channel where the work happens.

Fig.01  —  The same situation, two ways

Specimens A · B

Specimen AVague

Unaided

“Your team has had four production incidents in six weeks. Postmortems are ad-hoc emails that trail off without action items. Dev and ops are in a weekly standoff — dev wants to ship the new billing module, ops says the system is too unstable. Nobody has data. Your on-call engineer got paged 23 times last Thursday night, most of them for alerts that resolved themselves.”

×Vague — nothing concrete to act on.

Specimen BCalibrated

With Site Reliability Engineering

“Your service has a published SLO of 99.9% with a 43.8-minute monthly error budget that both dev and ops have signed off on. The last postmortem produced six action items — four are closed, two are in-flight with owners and due dates. Your on-call alert volume dropped from 23 pages per shift to four after you eliminated six noise alerts identified in the on-call health audit. The billing module shipped last week because the error budget had margin to absorb the risk.”

◦Specific, grounded, and ends with one clear next step.

Fig.02  —  A real session, unedited

In-app · assistant

Site Reliability EngineeringClaude

Site Reliability Engineering

I'm your SRE practice guide, built on Google's Site Reliability Engineering methodology. I can help you define SLOs and error budgets, write blameless postmortems, generate PRR checklists, audit your team's toil, or redesign your on-call rotation — using the same frameworks from the SRE Book. What are you working on?

We keep having this fight between our dev and ops teams. Dev wants to ship fast, ops says we're too unstable to ship. Nobody has data. I think we need SLOs but I have no idea where to start.

This is exactly the problem error budgets were designed to solve — they replace a subjective reliability debate with a mathematical one. Here's the framing: you define an SLO (say, 99.9% availability), and that gives you an error budget of 0.1% downtime per month — about 43 minutes. As long as you haven't burned that budget, dev ships freely. When the budget is depleted, releases pause until reliability recovers. Neither side is making a judgment call anymore; the budget decides.

Before we can set the SLO, I need to understand your service. Three questions: (1) What does your service do, and who are your users? (2) What does 'working correctly' look like from a user's perspective — what would they notice if it broke? (3) Do you have any existing uptime data or incident history I can work from?

It's a B2B SaaS platform — invoice processing for about 200 enterprise customers. Working correctly means: invoices submitted get processed within 5 minutes, and the API is responsive. We've had maybe 6 hours of downtime in the last 90 days across three incidents.

Good — that gives me enough to define your SLIs and calculate a starting SLO. Based on what you've described, your two primary SLIs should be:

Availability SLI: Percentage of API requests that return a successful response (2xx or expected 4xx), measured over 5-minute windows2. Processing Latency SLI: Percentage of submitted invoices that complete processing within 5 minutes

For your SLO: 6 hours of downtime over 90 days is 99.72% availability. That's your current baseline — your SLO should be aspirational but achievable. A starting target of 99.9% (43.8 minutes/month error budget) is appropriate for B2B SaaS with enterprise customers. You'd want to move toward 99.95% once you stabilize.

Here's your error budget math at 99.9%:- Monthly budget: 43.8 minutes of allowable downtime- Weekly budget: 10.1 minutes- Your three incidents consumed roughly 360 minutes in 90 days — about 4x what a 99.9% SLO permits

This means you don't have a shipping-too-fast problem yet — you have a reliability baseline problem. The error budget policy I'd recommend for you: no release freeze based on budget yet, but any single incident > 20 minutes triggers a mandatory postmortem with action items resolved before the next major release. Does that framing make sense to socialize with both teams?

Yes — that's exactly what we needed. Numbers that both sides can agree on. Can you help me write up the SLO document so I can present it?

Absolutely. Here's your SLO document draft:

---Invoice Processing Platform — SLO Document v1.0

Service: B2B Invoice Processing APIOwner: [Your team]Effective Date: [Date]Review Cadence: Quarterly

SLI Definitions:- Availability SLI: (Successful API requests) / (Total API requests), measured per 5-minute window. Excludes planned maintenance windows declared 48h in advance.- Processing Latency SLI: (Invoices processed within 5 minutes of submission) / (Total invoices submitted)

SLO Targets:- Availability: 99.9% over rolling 30 days- Processing Latency: 95% of invoices processed within 5 minutes, 99% within 15 minutes

Error Budget:- Availability: 43.8 minutes/month- Budget burn rate tracked weekly; dashboarded for both dev and ops leads

Error Budget Policy:- Budget < 50% remaining: Engineering team notified; reliability work added to next sprint- Budget exhausted: No production releases until budget recovers to 25%; incident postmortem required- Any single incident > 20 minutes: Mandatory postmortem with action items resolved before next major release

SLA Commitment to Customers: [To be determined with legal/sales — recommend 99.5% as contractual floor until baseline improves]

---

Want me to also generate the postmortem template for one of your three incidents? That would give you the action items to actually close the gap.

This is incredibly useful. Yes, let's do the postmortem next — the worst incident was a database failover that took about 4 hours.

Reply to Site Reliability Engineering…

What the skill is doing

01SLI/SLO Framework Design

02Error Budget Calculation & Policy Drafting

03Blameless Postmortem Facilitation

Fig.03  —  The same skill, in the channel you already use

WhatsApp · live

9:41

SRSite Reliability Engineeringtyping…

Messages are end-to-end encrypted. No one outside of this chat can read them.

Today

We keep having this fight between our dev and ops teams. Dev wants to ship fast, ops says we're too unstable to ship. Nobody has data. I think we need…9:14✓✓

I'm your SRE practice guide, built on Google's Site Reliability Engineering methodology.9:14

Message

The same skill, where the work happens.

No new app to learn. The methodology runs over the WhatsApp Business API, so the answer lands as a reply in the thread you’re already in — same rigour, zero context-switch.

◦Reads the situation, names the pattern, returns one concrete next move.

◦Delivered in seconds, inside a conversation that already exists.

Specimen · WhatsApp Business API · live

Capabilities

What it does, specifically.

Each capability is a distinct move drawn straight from the source methodology — not a generic assistant guessing.

CapabilityC-01

SLI/SLO Framework Design

Guides you through identifying the right Service Level Indicators for your service — the specific, measurable signals that reflect real user experience — then sets SLO targets with explicit error budget implications. You'll leave with a complete SLO document ready to socialize with stakeholders.

◦ MethodBased on the SRE Book's SLI/SLO specification process: SLIs must measure what users actually experience (request latency, availability, correctness, throughput), not internal system metrics.

CapabilityC-02

Error Budget Calculation & Policy Drafting

Calculates your error budget from your SLO target (error budget = 1 − SLO), converts it into concrete time windows (how many minutes per month you can afford to be down), and drafts a formal error budget policy that specifies what happens when the budget is exhausted — typically a feature release freeze until the budget recovers.

◦ MethodApplies the SRE error budget model directly: at 99.9% SLO, the monthly error budget is 43.8 minutes; at 99.99%, it's 4.38 minutes. The policy operationalizes the budget as a release-velocity governor with explicit trigger thresholds.

CapabilityC-03

Blameless Postmortem Facilitation

Walks through Google's canonical postmortem template section by section: reconstructing the incident timeline, identifying root causes and contributing factors (not individual blame), quantifying user and business impact, and generating action items with owners and deadlines that will actually get closed.

◦ MethodFollows the SRE Book's postmortem philosophy: blameless means attributing failures to system and process gaps, not human error. The five-section canonical template (timeline, root causes, contributing factors, impact, action items) is applied in sequence.

CapabilityC-04

Toil Audit & 50% Ceiling Assessment

Helps you categorize your team's current work into toil (manual, repetitive, automatable, tactical) versus engineering (reduces future toil, scales with the service), calculate your current toil percentage, and identify the highest-leverage automation targets to get below the SRE-mandated 50% ceiling.

◦ MethodThe SRE Book defines toil with five specific criteria: manual, repetitive, automatable, tactical, and lacks enduring value. The 50% toil ceiling is a firm SRE mandate — teams spending more than half their time on toil are operationally unhealthy.

CapabilityC-05

Production Readiness Review (PRR) Generation

Generates a customized PRR checklist for your service type, covering the ten standard SRE readiness domains: monitoring and alerting, SLO definition, capacity planning, on-call runbooks, rollback and failover procedures, dependency analysis, data integrity, security review, traffic management, and launch communication.

◦ MethodBased on Google's Production Readiness Review process, which gates services to SRE support. The PRR establishes a formal contract: SRE takes operational responsibility only when the service meets readiness criteria across all domains.

CapabilityC-06

Four Golden Signals Monitoring Strategy

Applies Google's four golden signals — latency (how long requests take), traffic (how much demand the system handles), errors (the rate of failed requests), and saturation (how full the system is) — to design a monitoring approach that covers the full surface area of user-visible failure without alert sprawl.

◦ MethodThe four golden signals are defined in the SRE Book Chapter 6 as the minimal sufficient monitoring framework for any service. Alerts should be symptom-based (user-visible impact) rather than cause-based (internal system states) to reduce noise.

CapabilityC-07

On-Call Health & Alert Quality Evaluation

Evaluates your on-call rotation against SRE best practices: alert volume per shift, actionability rate (what percentage of pages require a human response vs. are noise), escalation path clarity, and runbook coverage. Produces a health score and a prioritized list of changes to make on-call sustainable.

◦ MethodGoogle's SRE target is fewer than two incidents requiring active engagement per on-call shift. Alerts should be 100% actionable — every page must have a documented response action. Pages without runbooks are treated as toil and slated for automation or elimination.

Tested

Graded before it shipped.

Every skill is scored against independent scenarios for methodology fidelity before it goes live — not vibes, a rubric.

What it produces

OutputD-01

SLO Document & Error Budget Policy

A complete, ready-to-socialize document defining your SLIs, SLO targets (with rationale), error budget in minutes per month, and a formal policy specifying release-gating triggers and budget recovery procedures.

OutputD-02

Blameless Postmortem Report

A structured postmortem using the canonical five-section SRE template: incident timeline, identified root causes, contributing factors, quantified impact (user-minutes affected, revenue at risk), and action items with owners and due dates.

OutputD-03

Production Readiness Review Checklist

A gated PRR checklist customized to your service type, with pass/fail criteria across ten readiness domains and a clear summary of which gates are satisfied, which are blocked, and what must be completed before SRE handoff.

OutputD-04

Toil Audit Report

A categorized inventory of your team's current work, a calculated toil percentage, and a prioritized automation backlog ranked by hours-of-toil-eliminated per engineering-week-invested.

OutputD-05

On-Call Health Scorecard

A structured assessment of your on-call rotation across five dimensions — alert volume, actionability rate, escalation clarity, runbook coverage, and incident frequency — with a composite health score and a remediation priority list.

The source

Grounded in the original work.

Every answer traces back to a real source and the practitioner who wrote it — not a secondhand summary. Here is the source of record.

Source authorA-01

Ben Treynor Sloss

Ben Treynor Sloss coined the term 'Site Reliability Engineering' at Google in 2003 and built the original SRE team. As Google's VP of Engineering, he oversaw reliability for the world's largest internet infrastructure. He co-edited the canonical O'Reilly SRE Book (2016) and The Site Reliability Workbook (2018), which together define the industry-standard framework adopted by Amazon, Microsoft, Netflix, and hundreds of scaling tech companies.

Status · Inspired by Ben Treynor Sloss’s work — not yet claimed. Are you Ben Treynor Sloss?

Primary sourceS-01

Site Reliability Engineering: How Google Runs Production Systems

by Ben Treynor Sloss

VP of Engineering, Google; founder of SRE discipline (2003); co-editor of O'Reilly SRE Book (2016) and The Site Reliability Workbook (2018).

Read the original ↗

Citationsre.google

In the build queue

Be first to run it.

Site Reliability Engineering is being built right now. Leave your email and we’ll tell you the moment it goes live.

Notify meEmail

At launchWe've had three production incidents in the last 60 days and I need to set SLOs so we can have a data-driven conversation about release velocity vs. reliability. Our service is [describe your service]. Can we start by defining our SLIs and calculating an appropriate error budget?