Product · Incident agents
From hypothesis to a scoped pull request
Hypotheses checked against live production, the blast radius drawn, and the fix written as a scoped pull request.
ewakeapp11:08A pull request, not a suggestion
Scoped to payment-api, tested against production, and stopped at your rule.
#291 Restore connection pool size on payment-api
ewake/revert-4821 → main · 1 file · +1 −1
Opened by ewake
services/payment-api/db.py
The pool is back at max_size=32, where it sat before #4821. I ran the hypothesis against live traffic first: replaying the last hour at the old pool size clears the waits, at the new one it does not.
Blast radius is one file and one service. Nothing else reads this pool, and the change needs no migration and no restart of anything downstream.
What an incident agent actually does
Hypotheses, ruled out
Every candidate cause is checked against live production data (logs, traces, metrics) until only one survives, not asserted from a plausible pattern.
The blast radius, drawn
Which services, which customers, which downstream calls are affected: mapped out before any action is proposed.
The fix arrives as code
A scoped pull request, opened by ewake, with the diff, the reasoning and the tests it ran attached, not a paragraph telling a human what to type.
Your rules decide what merges itself
Auto-merge is scoped per service. Where it's off, the PR waits on the approval you already require: bounded autonomy, not unattended production changes.
The best incident is the one that never happens.
Thirty minutes, your own production, one perimeter. You will know inside a week whether it holds.