The agent that takes the page first
Triage, context and a named cause, in the channel, before anyone opens a laptop.
DatadogApp11:02 AM
[Triggered] [PROD] payment-api 5xx rate above 2%
payment-api (threshold 2%). @payments-oncallDatadog · Monitor 7730415
ewakeApp11:06 AM
Taking the page.
Root cause found · investigated by ewake
payment-api 5xx rate above 2%
payment-api rose from 0.3% to 6.8%, and every failure is raised from acquireConnection(). Most likely cause: connection pool exhaustion after #4821 lowered max_size from 32 to 8. The deploy landed 4 minutes before the first error.SEVERITY · HIGH · CONFIDENCE · HIGH
RULED OUT · traffic, database, upstream
3 repliesLast reply today at 11:14 AM
Message #p1-alerting
Most of the time an on-call engineer spends on an alert goes before any debugging starts. You find the runbook, or find that there isn't one. You open the dashboard, work out which service actually owns the failing endpoint, check whether anything shipped in the last hour, and read enough logs to know if this is real. Twenty minutes later you finally know what you are looking at.
ewake does that part. It watches the same alerts your team does, and by the time a human opens the thread the work of orienting is already done and written up, with the evidence attached.
At Brevo, whose transactional email team handles around 200 alerts a month, this took time to root cause on a typical high severity alert from 10 to 15 minutes down to 2 to 5.
What ewake does with an alert
Every page lands here first
ewake watches the same alerts your team does, and get to the channel before the first human does.
Context arrives with the page
The affected service, the most recent deploy and the blast radius are pulled together automatically, not requested after the fact.
A named cause, not a guess
Hypotheses are checked against live production before anything is posted, so what lands in the channel is a conclusion, not a suggestion.
You can push back
Ask why it thinks so and it defends its reasoning with the evidence it used, not with a restated confidence score.
How it handles a page
- 01
It takes the alert at the same moment you do
ewake sits on the same feed as your rotation, reading from PagerDuty or OpsGenie and from Datadog, Grafana or Prometheus. There is nothing new to route and nothing to instrument.
- 02
It assembles the context before anyone asks
The affected service, its recent deploys, its dependencies and the blast radius get pulled together automatically, because ewake already holds a map of your production and does not have to go looking.
- 03
It tests what it thinks against live production
A hypothesis is checked before it is posted. That is the difference between a conclusion and a guess, and it is why what lands in the channel is worth reading rather than worth verifying.
- 04
It posts what it found, and what it ruled out
You get a named cause, a confidence score, the evidence behind it and the paths it eliminated. Ask it why and it answers with the reasoning it used, in the thread, not with the same number again.
- 05
Then it acts on it
It closes the noise, fixes what it can within the boundaries you set, or escalates to the right person with the evidence attached.
Where it stops
Read only until you say otherwise
It reads metrics, logs, traces and code. It changes nothing in your infrastructure unless you grant write access, and that is scoped per service and revocable.
It wakes you when judgment is needed
Anything that needs a human call, or that has reached customers, goes to the on-call with the investigation already attached rather than being handled quietly.
It never trains on your data
Your telemetry, your code and your incidents are never used to train or fine tune any model, on any tier, in any hosting option.
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.