By role
For Site Reliability Engineering
Toil is the part of the job you can measure and the part nobody has managed to delete. Most of it is not repetitive execution, it is repetitive reading, and that is the half a platform can actually take.
- ReconstructionThe joining, matching and change-hunting happens before the page, not after it.What moves off your plate
- CitedEach claim links to the change record, counter or log line behind it, so you check one thing.How you disagree fast
- It refusesWhere an action sits outside its radius, the platform proposes nothing and says so.Why the acceptances matter
- Your scriptsExisting automation becomes procedures with a pre-check, post-check and armed rollback.What happens to your toil
What actually costs you
Three things, and none of them is a tooling gap
These are the problems we hear described in the same words on almost every estate. Each one is structural rather than a failure of effort, which is why buying another point tool has not fixed them.
Toil is mostly reading, not running
The scripts are the easy part and most SREs already wrote them. What does not automate itself is deciding whether this alert is the same as that one, what moved in the last two hours, and whether anyone has seen this signature before.
The reconstruction hour is unbillable to anyone
Every incident starts by rebuilding a picture that already existed across change records, topology, prior incidents and telemetry. It is mechanical, it repeats forever, and it is where the error budget quietly goes.
Ungoverned automation is a liability you own
The script that fixes it at 3am has no pre-check, no post-check and no rollback, because you wrote it under pressure to solve one thing. It works until the day the assumption underneath it stops being true.
What changes
The two decisions that matter for your role
The mechanism is the same across the platform and is set out on the solution pages. What is worth your time here is how it lands on the specific work you are accountable for.
Your existing automation, with the missing parts added
A written runbook or a working script is most of a procedure already. What gets added is the pre-check that asserts the conditions at execution time, the post-check verified against live signals rather than exit codes, and a rollback armed before anything runs.
That is the difference between automation you tolerate and automation your change process will approve.
Blast radius is the concept you already think in
SREs have always reasoned about the consequence of an action rather than the confidence of a diagnosis. Restarting a pod behind healthy replicas is a different decision from draining a stateful node, and no confidence score has ever captured that difference.
The platform gates on exactly that, which is why the governance model tends to be an easier conversation with SRE teams than with anyone else.
How autonomy is granted per actionWhy confidence is the wrong gate
See it on a real fault
Four walkthroughs from your side of the desk
Each one follows a specific fault end to end: what arrived, what was correlated, what ran and where the boundary of autonomy sat.
- Service OpsSomething is slow. Nobody can say which something.Read the walkthrough →
- Data OpsThe connection pool ran out and took checkout with itRead the walkthrough →
- Service OpsThe CPU spiked at 3am and the pager did its jobRead the walkthrough →
- Service OpsSeventy-eight percent of the way to a timeoutRead the walkthrough →
Being straight with you
What we are not going to claim
Questions we get asked
Frequently asked questions
Is this just another runbook automation tool?
Runbook automation executes steps. It generally does not assert preconditions at execution time as a named step, does not verify against live signals rather than exit codes, does not arm a rollback before running, and does not decide who may press go based on what the action can break. Those four differences are the whole product.
Will it page me less or page me better?
Better first, less second, and in that order deliberately. Investigation runs before notification, so what reaches you carries a probable cause. Volume comes down later, as specific actions earn the right to resolve without a human, which is a per-action decision rather than a switch.
What happens to our error budget policy?
Nothing automatically. The platform gives you a cleaner input to it: fewer pages that turn out to be the same event, and a record of which classes of fault are consuming the budget rather than an anecdote about it.
Can we bring our own agents and tools?
Yes. Agent-to-agent and Model Context Protocol integration means the orchestrator can task agents your team built and call tools the platform does not ship, which matters because no serious estate was going to let one vendor own every action.
Go deeper
Where to read next
Bring us the toil you have not managed to delete
The thing that repeats, that you half-automated once, and that nobody will let you run unattended. We will walk through what its pre-check would assert and what would have to be true for it to run alone.