Breaking: Exla (YC W25) ships Libra, an AI site-reliability engineer Production broke at 3:07 AM — the fix PR landed by 3:14 Founders: ex-Amazon ML engineer + ex-Apple kernel engineer Guardrail: “No claim without evidence” Pivoted from edge-model SDK to autonomous incident response Backed by Y Combinator — Winter 2025 batch Breaking: Exla (YC W25) ships Libra, an AI site-reliability engineer Production broke at 3:07 AM — the fix PR landed by 3:14 Founders: ex-Amazon ML engineer + ex-Apple kernel engineer Guardrail: “No claim without evidence” Pivoted from edge-model SDK to autonomous incident response Backed by Y Combinator — Winter 2025 batch
Company AI · Developer Tools · Site Reliability

Exla built an engineer that never sleeps through your 3AM outage

The Y Combinator W25 startup put its whole pitch in one line: production broke at 3:07 AM, you slept, and its AI did not. Meet Libra, the on-call teammate that reads the logs, blames the right commit, and opens the fix.

The dashboard read 3:07 AM. Fourteen errors in eight minutes, up from zero the hour before. Two workspaces down, replies stalling by the dozen. On most engineering teams this is the moment a phone buzzes on a nightstand, a laptop opens in the dark, and a tired person starts asking the same four questions they always ask: Does this matter? What changed? Who is affected? What do I do about it? At Exla, the answer is that nobody wakes up. By 3:14 AM a pull request is already open, tested, and waiting for a human to say yes.

That gap - seven minutes from a spike nobody was watching to a fix nobody had to write - is the entire product. Exla, a San Francisco company in Y Combinator's Winter 2025 batch, builds Libra: an AI site-reliability engineer that watches your logs, traces, and deploys around the clock and steps in when something breaks. The company sells it with a single, blunt line that doubles as a mission statement.

Production broke at 3:07 AM. You slept. Libra didn’t.Exla’s pitch for Libra

01 / What It Actually DoesThe night shift, handled

Libra is not a dashboard you check in the morning. It is a loop that runs whether or not anyone is looking. It reads raw telemetry - logs, traces, deployment records, pull requests, cloud metrics, product analytics, past incidents - and builds a picture of what “normal” looks like for one specific business. Then it waits for reality to drift. When it does, Libra runs the same five steps a good on-call engineer would, minus the drowsiness.

01
Detect
Catches failures that had no alert configured
02
Investigate
Pulls logs, traces and recent deploys
03
Root cause
Names the exact commit, with evidence
04
Fix
Opens a PR with a regression test
05
Verify
Won’t close until production stays quiet
The loop that runs while you sleep. Five steps, no coffee, no nightstand buzz - Libra walks from a spike nobody saw to a fix nobody had to type.

The part that reads like science fiction is step five. Plenty of tools can draft a fix. Libra runs the patch beside a baseline in a sandbox, replays the actual failing requests using real trace data, and refuses to mark the incident closed until the exact failure stays silent in production. It is the difference between a fix that compiles and a fix that works.

There is a quieter design decision underneath all of this, and it matters more than the demo does. Instead of asking an engineer to set a threshold - alert me if error rate crosses two percent - Libra learns what each business normally looks like on its own. It notices which customers are active at which hours, what a given endpoint usually returns, how long a background job typically takes. A regression, in that framing, is not a number crossing a line. It is a system behaving unlike itself. That is a harder thing to detect, and it is also the thing that catches the failures nobody thought to write a monitor for.

It also lives where engineers already are. Libra sits in Slack and is queryable over MCP, so a groggy human who does get pulled in can ask it questions in plain language rather than pivoting through six browser tabs. The point is not to replace the on-call engineer's judgment. It is to hand that engineer a case file that is already assembled - the affected customers, the suspect commit, the evidence, and a proposed fix - so the only remaining job is the one humans are actually good at: deciding.

3:07AM — failure detected
~7 minDetect → fix PR
14Errors in 8 minutes
24/7Always on call

02 / The PeopleAn Apple kernel and an Amazon search box walk into a startup

Exla is two people. Viraat Das, the CEO, was a machine-learning engineer at Amazon working on model optimization and the infrastructure behind personalized search. He also, for what it is worth, finished college in about two and a half years. Pranav Nair, the CTO, was an operating-system engineer at Apple, working on the kernel that manages the sleep and wake behavior of more than a billion devices. The joke almost writes itself: the man who spent his career perfecting how machines fall asleep now builds software whose entire job is to stay awake.

They met in college and had been building things together long before Exla. That history shows up in the product's temperament. Libra is opinionated about honesty in a way that feels like it came from engineers who have been burned by confident tooling before.

No claim without evidence.Exla’s guardrail for Libra

In practice that rule means an alert only fires if it can be traced back to a real log line or a specific commit. Libra asks for human approval before it changes code, and it says so plainly when it is not sure. In a market flooded with AI that answers every question with the same unearned confidence, a tool that volunteers its own uncertainty is a genuine differentiator.

This is the sort of principle that only comes from people who have been on the receiving end of a bad alert. Anyone who has carried a pager knows the specific dread of an incident channel filling up with confident, contradictory guesses at 3am. Exla's answer is to build a teammate that would rather say “I am not certain” than manufacture a root cause. It is a small philosophical stance with large practical consequences: a tool you can trust to page you is a tool you will actually let page you.

03 / The PivotFrom tiny chips to the graveyard shift

Exla did not start here. Its first product was an SDK to run large transformer models - language models, vision-language models, computer-vision models - on small edge devices like NVIDIA's Jetson boards. The trick was aggressive quantization: shrink a datacenter-scale model until it fits on hardware that draws a few watts, without losing the plot. The numbers were real.

Memory footprint
-80%
Inference speed
3–20×
Model size
2–5× smaller
The old obsession, charted. Exla's edge SDK squeezed big models onto small chips - up to 80% less memory and 3-20x faster inference. The optimization instinct survived the pivot; the target changed.

So why the switch? Because the founders kept running into a different problem they could not stop thinking about - their own on-call rotations. The systems failed overnight. Customers noticed first. Mornings were spent reconstructing a story from logs. They built Libra because they wanted it, which is usually the most reliable reason a tool ends up good. The optimization instinct did not go away. It just found a heavier target: the cost, in sleep and sanity, of keeping software alive.

04 / The CompetitionWhere Libra sits in a crowded room

The observability and incident-response market is not empty. Datadog owns the dashboards. Sentry owns the stack traces. incident.io and Resolve.ai orchestrate the human response. Exla's argument is not that these tools are wrong, but that they mostly wait - for an alert you configured months ago, or for a person to declare that an incident is happening. Libra's pitch is that it moves first, and moves further.

CapabilityLibra by ExlaDatadogSentryincident.io
Catches failures with no monitorYesPre-built alertsErrors onlyManual declare
Learns your business contextYesGeneric curvesNoNo
Opens a fix pull requestYesNoDrafts, untestedNo
Tests fix on real failing trafficSandbox replayCI onlyNoNo
Verifies recovery in productionYesRollout checkRe-detects errorsNo
How Exla frames Libra against the field. The through-line: raw telemetry over pre-set thresholds, and a verified fix over a helpful chart.

The subtle claim buried in that table is about false alarms. Because Libra learns which customers are active and what each endpoint normally does, it can tell the difference between a real regression and a noisy test environment - the kind of distinction that generic threshold alerts miss, and the reason so many on-call engineers learn to ignore their own pagers.

Positioning matters here because the incumbents are not going anywhere. A team already running Datadog is not going to rip it out. Exla seems to understand that, and frames Libra less as a replacement for the dashboard and more as the thing that acts on what the dashboard shows. Datadog can tell you the error rate spiked; Libra's job is to tell you the commit that did it and hand you the patch. One is a better map. The other is a driver. In a category where most products compete on how much they can show you, choosing to compete on how much they can do for you is at least a clear position - and a risky one, because doing things is where AI tools most often embarrass themselves.

05 / The BusinessSelling back a good night’s sleep

The model is straightforward B2B software: Libra plugs into a team's logs, cloud infrastructure, source control, and Slack, and works as an autonomous on-call teammate that is queryable over MCP. The buyers are the people who currently carry the pager - platform teams, DevOps groups, and the engineers who run production and are tired of being its first line of defense.

3:07 AM
Failure detected - 14 errors, 2 workspaces
3:09 AM
Root cause traced to a single deploy
3:12 AM
Fix drafted, replayed against real traffic
3:14 AM
Pull request opened, awaiting approval
Seven minutes, start to finish. A single night on Libra's demo timeline - the stretch a human would have spent squinting at logs.

The company is early. It is two founders, a seed round reported around March 2025, and a Y Combinator stamp from the W25 batch. There is no enterprise sales machine and no six-figure logo wall. What there is, instead, is the founders answering customer emails themselves - a stage most startups are nostalgic for and few admit they are still in.

That smallness is not incidental to the pitch; it is part of the credibility. An autonomous system that can open pull requests against your production code is exactly the kind of tool you want built by people who will personally pick up the phone when it gets something wrong. Exla is betting that trust in this category is earned one careful incident at a time, and that being reachable is a feature. For now, the two of them are both the engineering team and the support desk - which is, if nothing else, a very literal demonstration of the problem they are trying to automate away.

“Somebody has to be awake.”
The one-sentence reason Exla built Libra

06 / The BetWhat you can actually do with it

Strip away the framing and Libra offers a small, concrete trade. You give an AI read access to your production nervous system and permission to propose fixes. In return, the overnight incident - the one that used to cost a person their sleep and cost the company an hour of blind log-reading - becomes a pull request waiting politely for a review. You still hold the merge button. The machine just did the parts nobody wanted to do at 3am.

Whether that trade wins depends on trust, and trust is exactly what Exla's guardrails are built to earn: evidence for every claim, approval before every code change, and an honest shrug when the system does not know. It is an unglamorous pitch for an unglamorous problem. But every engineer who has ever answered a page in the dark knows precisely how much that unglamorous problem is worth.

#ai#sre#devops#observability#incident-response#on-call#developer-tools#yc-w25#y-combinator#san-francisco