How the AI works
Model-agnostic, and grounded on purpose
Reasoning over messy telemetry under pressure is the hard part of an incident, and it is what modern language models are good at. Ember is built around that, with the evidence in front and a human on the decision.
Four things Ember always does
Read the evidence first
Ember does not start from a prompt, it starts from your telemetry. It ingests the alarm, logs, traces, metrics and recent changes, normalizes them onto one timeline, and selects the lines most likely to matter before the model reasons over them.
Reason, then rank with confidence
The model proposes candidate causes and Ember ranks them by how well the evidence supports each one. The confidence is a function of that support, not a flourish. Weak evidence yields low confidence and an explicit next check.
Ground every claim
Each ranked cause carries the specific signals it keyed on, so the on-call can verify it in seconds. If Ember cannot point at the evidence, it does not assert the cause.
Route across models
A thin layer maps each task to a provider and model, and fails over during an incident. The interface is one function, so adding a provider, or pointing Ember at your own endpoint, is a change in one place.
One interface, any model
Every model call in Ember goes through one function. It takes a task and the evidence, and returns a grounded, structured result. The router chooses the provider and model, retries and fails over. Swapping vendors, or registering your own endpoint on Scale, does not touch the product code above it.
Because the boundary is small and explicit, Ember is never hostage to one vendor being fast, available or unchanged, which matters most during an incident.
// the whole model boundary, in one call
type Provider = "openai" | "anthropic";
async function chatJSON(req: {
system: string;
user: string; // the evidence, normalized
model?: string; // router picks a default
}): Promise<{ content: string; model: string; provider: Provider }>;
// ranking a cause and drafting a rollback
// are just two tasks through the same door.A cause you can check in seconds
cause Redis connection pool exhausted after deploy v2025.7.3 confidence 78%
evidence 15:02:11 pool timeout acquiring connection after 5000ms (redis)
15:02:12 redis connected_clients=200 maxclients=200
14:58 deploy v2025.7.3 raised pool to 200, landed 4m before alarm
fix rollback kubectl rollout undo deploy/checkout-apiThe evidence is the point. A confident answer with nothing behind it sends people down the wrong path at the worst time. Ember ranks by support and shows its work, so the human can agree or override in seconds.
Human on the decision, careful with telemetry
No autonomous production changes
Ember drafts and shows commands. A person runs anything that changes production.
Not training on your telemetry
Your logs and traces are processed to run the incident and are not used to train shared models.
Your models on Scale
Register your own endpoints so the reasoning runs on models you control, inside your perimeter.
Put Ember on your next incident.
Start free and run a real incident in a minute, or talk to us about Team and Scale.