SRE Practices Review

Read-only viewer access to your incident-management platform (PagerDuty, Opsgenie, Incident.io, FireHydrant, Rootly, Grafana OnCall, Datadog On-Call), SLO tooling (Sloth, Pyrra, Nobl9, native), and observability platform - scoped to alert, incident, on-call, SLO, and runbook APIs only. Pager and incident data is anonymised at ingestion; engineer names, customer IDs, and free-text incident details are stripped or hashed before analysis. We never copy production telemetry off your environment, and we provide the exact scopes in advance for your security team to review.

Internal retros are excellent for team-level reflection but rarely produce hard maturity scoring against external benchmarks, quantified MTTA / MTTR / page-volume baselines, or comparison to dozens of similar teams. A senior SRE who has run on-call for high-traffic SaaS combines anonymised pager-data analysis, structured engineer interviews, and benchmarking against the Google SRE Workbook, OpenSLO, and DORA - into a prioritised backlog with quantified impact per change rather than a list of opinions.

Yes. The deliverables include a per-service SLO rollout plan mapping every customer-facing user journey to the SLI it should have (availability, latency, quality, freshness), the SLO target and rationale, multi-window multi-burn-rate alert templates per the Google SRE Workbook, an error-budget policy template with pre-defined consequences, and a tool-fit recommendation across Sloth, Pyrra, Nobl9, OpenSLO, Datadog SLOs, Grafana SLO, or Honeycomb SLOs based on your stack.

Both. The objective signal comes from 90 days of pager data - page volume per engineer, off-hours and weekend page distribution, time-to-acknowledge spread, chronically-acked alerts, and shift-handoff quality. The subjective signal comes from confidential 30-minute interviews with on-call engineers, asking the questions that pager data cannot answer (psychological safety during incidents, quality of runbook coverage, IC support, sleep impact). The two perspectives almost always reveal different gaps.

Yes. Incident command coverage includes severity classification (SEV-1 → SEV-5), incident commander role and rotation, status-page communication (Statuspage, Better Stack), war-room tooling, executive escalation paths, and ICS / Google IMAG alignment. Post-mortem coverage includes blameless facilitation, root-cause analysis depth (Five Whys, CAST), action-item ownership and follow-through, and learning dissemination across teams - with templates and facilitator guides included in the deliverables.

We define toil per the Google SRE Book - manual, repetitive, automatable, tactical, no-enduring-value, scaling with service growth - then quantify it through ticket analysis, time-tracking signal, and engineer interviews. The automation backlog prioritises top-toil categories and recommends concrete tooling (GitOps, ChatOps, Rundeck, StackStorm, Ansible, AWS Systems Manager, Azure Automation, internal developer platforms with Backstage, Port, or Cortex) with quantified hours-saved per change.

Yes - and this is one of the most useful parts of the review. Vanity SLOs and SLOs on internal-only services that nobody acts on are a major source of programme decay. The rollout plan explicitly identifies which services should not have SLOs, which should have only error-rate or freshness SLIs, and which should have full multi-burn-rate alerting - so the programme stays sustainable past the first quarter.

Typical turnaround is 3-5 business days from the moment read-only access is granted and engineer interviews are complete, plus a 45-minute live findings walkthrough at a time that suits your SRE, platform, and engineering leads. Larger teams with multiple on-call rotations can take a little longer; we confirm the timeline as soon as we see the scope.