Features / Capture & fix
Autopilot
Decide what it may pick up on its own
You set what gets worked automatically and what waits for a person, in numbers you can read before you turn it on. Everything else queues quietly rather than acting on a guess.
Budget, this period8% used
Set per organization, per period. Work stops at the cap whether or not anybody is awake.
What it does
- Rules per source, per project, per environment, in the order you choose
- Waits for five occurrences and an hour before acting, and you move both
- Ten automatic actions an hour and fifty a day, plus a switch that stops work already running
- Auth, billing, migrations, secrets and tenant isolation always go to a person
Without it
The work that is safe to automate is the work nobody automates
Nobody wants to be the person who turned it on
The setting is a single switch and it is either off or it is everything. So it stays off, and you keep doing by hand the work you already agreed a machine should be doing.
The same three errors every single day
You know about the third-party timeout. You know about the extension that throws on load. They are not going away this quarter, and anything automated will keep picking them up and asking you about them until you stop reading it entirely.
One bad deploy and it is off to the races
A release goes out at 6pm, one broken code path fires ten thousand times, and now something is opening work for every single one of them while you sleep. You wake up to a queue you have to clean before you can even see the actual bug.
How it works
It starts switched off, and it fails that way too
Automatic work runs only where a policy on record says it may, for that kind of work and that level of risk. No policy on record means nothing runs. Every gate below is written the same way round: if a check cannot be read, or a rule cannot be understood, the answer is no rather than carry on. There is no configuration you can leave half-finished that quietly means yes.
Only a signed webhook can start work on its own
Automatic pickup requires the incoming report to arrive over a webhook whose signature has been verified. An unsigned or token-only source can still open work for a person to look at; it cannot set the machine going by itself. Sentry is the connected error tracker today.
Say which sources may act, and where
Each connected source gets a default: off, ignore, send to a human, investigate, or draft a change. Scope it to particular projects and environments, so production can be treated differently from staging. Any source can be paused on its own, and a paused source stops before anything else is even evaluated.
What that includes
- ignore
- send to a human
- investigate
- draft a change
Rules read top to bottom, first match wins
Order them by project and by environment, and the first rule that matches decides. Ordering is explicit, so you can always answer why a given error was handled the way it was. A rule the system cannot read stops automation rather than being skipped over, which is the safer failure and the less convenient one.
Thresholds and ignore lists absorb the noise
It waits until an error has happened enough times and has been around long enough to be real. It ships at five occurrences and one hour old, and you move both, though a hard floor underneath means you cannot loosen it past the point where an error is still a coincidence. Ignore patterns hold the things you already know about, matched on the error fingerprint rather than on wording.
What that includes
- It ships at five occurrences
- one hour old
- you move both
Caps and a kill switch sit above all of it
A ceiling on autonomous actions per hour and per day, shipping at ten and fifty, counted against work actually started rather than work intended. Above that sits a budget per organization with a switch that stops runs already in flight, not just new ones. Every decision is recorded with a snapshot of every control that was consulted, so a choice can be traced afterward and undone.
What it means for you
The scary part is the part with the numbers on it
Five occurrences, one hour, ten an hour, fifty a day. You can read the limits before you turn anything on, change them, and check afterward what they actually stopped. Trust here is not a feeling about the model, it is a set of figures you chose.
The noise you already know about stops asking for attention
Known issues are ignored by fingerprint, not by you deciding to stop looking at the channel. What is left in front of you is the stuff that is actually new.
A bad night stays a bad night
The caps mean the worst case is a queue that stopped at a number you chose, not a thousand pieces of work to unpick over breakfast. And the kill switch reaches work already running, so stopping it is immediate rather than eventual.
The honest limit: Anything touching authentication, billing, migrations, secrets or the boundary between one customer's data and another's is escalated to a person instead of being worked automatically, and so is any change where it cannot tell what the code path touches. Above that, the last step of all, opening the pull request on your repository, is not switched on yet. Autopilot can decide to pick something up, investigate it and prepare the change; a person still approves and applies it.