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.
ewakeApp12:26 AM
Taking the page.
Resolved · fixed by ewake
checkout-api 5xx rate above 2%
checkout-api was caused by deploy #4821 lowering db.pool.max from 50 to 5. ewake reverted the setting and the error rate dropped from 6.1% to 0.3% in 4 minutes. Fix opened in PR #4823. Nobody was paged.SEVERITY · HIGH · CONFIDENCE · HIGH
ACTION · reverted db.pool.max 5 → 50
Datadog12:26 AMtriggering alert
Show more
2 repliesLast reply today at 12:31 AM
ewakeApp2:52 AM
Taking the page.
Needs a human · escalated
payments decline rate 4.2% → 19.6%
02:51 with no change on our side: no deploy, config or latency shift in the last 2 hours. The pattern points to the payment provider, outside what ewake can fix. Timeline and investigation are ready in inc-2318. Paging @payments-oncall.SEVERITY · CRITICAL · CONFIDENCE · MEDIUM
RULED OUT · deploys, config, latency
Datadog2:52 AMtriggering alert
Message #p1-alerting
Knowing the cause is not the same as knowing what to do about it. The gap between the two is where most of an incident actually goes: working out how far the damage reaches, deciding whether the obvious fix is safe, and writing something you are willing to merge at two in the morning.
ewake works that gap. It starts from the named cause and does the checking a careful engineer would do before touching production, then writes the change as a scoped pull request against the boundaries you set.
The pull request is a proposal, not a decision. Auto merge is off by default, and stays off until you turn it on for a service.
What ewake does in an incident
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.
Only ping a human when one is needed
When human judgment is required or there is customer impact, ewake wakes the on-call, with the investigation, the evidence and the recommended action already attached.
It helps the responders, live, in the channel
Once people are on the incident, anyone can ask ewake what changed, who is affected or what to rule out. It answers from live production, with the evidence.
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.
How it works toward a fix
- 01
It validates the hypothesis against production
Before anything is written, the explanation is checked against what your systems are actually doing right now. A cause that only holds in theory does not get a patch.
- 02
It maps the blast radius
Which services depend on the broken one, which of them are already degraded, and who owns them. This is the part that decides whether a fix is small or whether it needs a human in the room.
- 03
It writes the change inside your boundaries
Scoped to the services you have allowed, in the style of the surrounding code, as a pull request against your repository in GitHub or GitLab.
- 04
It shows the reasoning with the diff
The evidence, the alternatives it discarded and its confidence arrive with the change, so reviewing it does not mean reconstructing the investigation first.
Where it stops
Nothing merges on its own
Auto merge is off by default and enabled per service. Until you enable it, every change waits for a human to approve it.
You set what it may touch
Write access is granted per service and revoked the same way. What ewake can act on alone, what needs approval and what it may only suggest are your rules.
Repeats need to be earned
A pattern your team has already resolved once, under rules that allow it, can be handled again automatically. ewake tells you what it did.
Point ewake at your own production
Thirty minutes to connect it, one perimeter, your real alerts. You will know inside a week whether it holds, on your stack, not in a sandbox.