The SRE work that doesn't need a person to start it

Site reliability engineering spends a disproportionate share of its time on work that happens before a fix: gathering metrics and logs, correlating them against a recent deploy or config change, checking whether this matches a past incident, and forming a hypothesis worth acting on. None of that requires human judgement to start - it requires access to the right systems and enough context to know where to look.

Automating that first stage - not the decision to act, just the gathering and correlation - is what actually reduces the cost of running an SRE function at scale. Metrics and alert rules from your observability platform, the source of the affected service from your repository, and past tickets for the same failure mode, assembled the moment an alert fires rather than the moment an engineer picks it up.

What comes back from that stage is a root-cause hypothesis with an honest confidence rating, not a false certainty - including an explicit "not enough information" when the evidence doesn't support one. A tiered remediation model then matches the response to what's actually reachable: a direct API call against a cluster your infrastructure already exposes, a dispatched CI/CD job through a pipeline you already own, or a proposal that waits for a person, depending on policy.

The organisational effect is a smaller on-call rotation carrying the same coverage - not because fewer things go wrong, but because the expensive, undifferentiated part of responding to them no longer needs a dedicated person to start.