Buyer's Guide · Vendor Evaluation

How to choose an SRE consultancy.
12 questions that expose the difference.

Every staffing firm relabelled its ops bench "SRE" somewhere around 2021. The result: identical-looking proposals hiding completely different products. These 12 questions, asked in the first call, separate a reliability practice from a resume forward. For each one, we've written what a good answer sounds like, including the answers that should count against us.

Use this as a live checklist. A serious consultancy will enjoy these questions; a bench-rental firm will try to reroute you to a slide deck. (If you first want the discipline itself explained, start with What is SRE? and come back.)

The reliability practice (questions 1–4)

  1. "What's the first thing you'd do in our environment?"
    Good answer: define SLOs with you, from user-visible behaviour, before touching any tooling. Bad answer: anything that starts with installing their preferred stack. Reliability is a target, not a toolchain.
  2. "How do you decide what pages a human at 3 a.m.?"
    Good answer: burn-rate alerts against error budgets; symptoms, not causes; every page actionable. If they can't explain why "CPU above 80%" is a bad page, they haven't restructured an alert system before. Our alert fatigue teardown shows what that restructuring looks like.
  3. "Walk me through a real incident you ran."
    Good answer: a specific story with a timeline, a wrong first hypothesis, the fix, and what changed afterwards. Listen for the phrase "blameless post-mortem" used like they mean it. Vague heroics ("we once saved a client's Black Friday") without mechanics is marketing.
  4. "What does your error-budget policy actually change?"
    Good answer: it gates releases. When the budget is spent, feature deploys pause and reliability work takes priority, with leadership pre-committed to that trade. An error budget that never blocks anything is a dashboard, not a policy.

The people (questions 5–8)

  1. "Who exactly will work on our account, and have they carried a pager?"
    Good answer: named seniors with production scar tissue, and honesty about the senior-to-mid ratio on billed hours. The team on the proposal and the team in your Slack should be the same people.
  2. "Will you join our on-call rotation?"
    Good answer for managed engagements: yes, with written response times. Good answer for bootstraps: we'll design it, run simulations with your engineers, then hand it over. A consultancy that would never join the rotation it designs is telling you something.
  3. "How do you transfer knowledge so we don't need you forever?"
    Good answer: runbooks, architecture docs and pairing sessions in scope from week one, and a definition of done that includes your team operating the system alone. Ask them directly: "what percentage of clients still need you for daily operations after a year?"
  4. "What happens when we disagree with your recommendation?"
    Good answer: they document the trade-offs, state their recommendation plainly, and build what you decide. You're hiring judgment, not obedience, but also not a vendor who sulks or bills you extra for your own decision.

The commercials (questions 9–12)

  1. "What exists when the engagement ends?"
    Good answer: a written list. SLOs live, alerts restructured, runbooks in your repo, dashboards your team owns, on-call rotation staffed by your engineers. If the deliverable is "improved reliability posture", ask what artefact proves it.
  2. "How is the engagement priced, and what moves the number?"
    Good answer: fixed scope with milestones for bootstraps, monthly with SLAs for managed reliability, and a plain explanation of what drives the price. Open-ended hourly for a large reliability program means you're carrying all the estimation risk. Our 2026 rates guide maps the market ranges.
  3. "Which tools do you require us to adopt?"
    Good answer: none. They should work with your existing observability stack and recommend changes only when a tool change pays for its own migration. A hard dependency on their proprietary platform is lock-in wearing an SRE costume.
  4. "What are your exit terms?"
    Good answer: you can end the engagement at a milestone boundary, everything they built lives in your accounts and repos from day one, and offboarding includes a handover session. If any credential, pipeline or document lives only in their systems, that's a hostage situation on a timer.

Scoring what you hear

You don't need a weighted spreadsheet. After the call, three gut checks predict the engagement:

  • Did they talk about your users or their tools? SRE starts from user-visible reliability. Everything else is implementation detail.
  • Did they say "it depends" at least once, and then actually explain what it depends on? Certainty about an environment they haven't seen is a sales reflex, not engineering.
  • Would you page this person at 3 a.m.? If the answer is no, the rest doesn't matter.

If you're evaluating for a SaaS product specifically, the multi-tenant wrinkles (customer-facing SLOs, noisy-neighbour incidents, per-customer breach detection) are covered in SRE for SaaS.

Yes, this checklist is also a pitch: we wrote it because we like being interviewed this way. Bring all 12 questions to a free 30-minute review and grade our answers live.

Related: SRE consulting services · What is SRE? · SRE for SaaS · DevOps consulting rates 2026

Interview us with this list.

Free 30-minute SRE review with a senior engineer who has carried the pager. Ask the hard questions; we'll answer them the way this page promised.

last updated: 2026-07-07

SRE services Book the Review →

Frequently asked questions

What is the biggest red flag when hiring an SRE consultancy?

A proposal that starts with tooling instead of SLOs. If the first deliverable is 'we will install our observability stack' rather than 'we will define what reliability means for your users and measure against it', you are buying tools, not reliability. The second-biggest red flag: nobody on the proposed team has carried a pager.

Should an SRE consultancy join our on-call rotation?

For a managed-reliability engagement, yes, with defined response times and escalation paths. For a bootstrap engagement, they should design and stress-test the rotation, run incident simulations with your team, and hand over a rotation your engineers own. Be suspicious of a consultancy that designs an on-call system it would never agree to join.

How long should an SRE engagement take to show results?

Weeks, not quarters, for the first visible artefacts: an SLO set that leadership signed off, burn-rate alerts replacing threshold noise, and a post-mortem template in use. Structural results such as reduced alert volume and faster incident resolution typically land inside 90 days. Anyone quoting a year before you see measurable change is selling a transformation program, not engineering.

Do we need an SRE consultancy or should we hire SREs in-house?

Below roughly 50 engineers, most companies need an SRE practice, not an SRE team: a few well-chosen SLOs, sane alerting, and an on-call culture that doesn't burn people out. A consultancy can stand that up in about 90 days and hand it over. Hire in-house when reliability engineering becomes a permanent, product-shaped workload. The two also combine: bootstrap outside, then hire into a working practice.