An AI SRE that knows your incidents

Every AI SRE demo starts the same way. A slick screen recording. A P0 alert. An "Investigate" button. Ten seconds later, a root cause hypothesis appears on screen.

The demos are compelling. The problem is what happens after you install one and it starts investigating actual incidents on your actual services.

Most AI SREs are pattern matchers trained on public data. They know what a memory leak looks like in the abstract. They don't know that your payments-api has a flaky liveness probe everyone ignores, that the checkout team owns the retry policy, or that the last three "database incidents" were actually cache misconfigurations. That knowledge lives in your postmortems, your Slack channels, and the heads of two senior engineers.

That is where Sera AI comes in. Sera AI is Xurrent's AI SRE, the Root Cause Hypothesis Agent built into our incident management platform. It is built differently from the pattern matchers above: it reads your team's incidents. Only your team's.

The investigation gap

Most of an incident's resolution time is not spent fixing. It is spent investigating. Engineers chase symptoms across a dozen dashboards, dig through gigabytes of logs, and replay the last twelve deployments. Manual incident investigation eats 60 to 80 percent of MTTR in distributed systems. The average enterprise MTTR still sits at four to six hours.

The 3am scramble looks the same at every company. Alert gets fired and you join a bridge call, scroll through logs trying to remember if you have seen this before. Twenty minutes in, you still do not have a starting point.

That is what Sera AI closes.

What Sera actually does

Click Investigate on any incident. Or trigger it from the incident's Slack channel. Within seconds, Sera returns four things:

• A probable root cause, specific enough to act on
• A confidence level: High, Medium, or Low
• The evidence behind the hypothesis
• Mitigation steps for right now, and what can wait

The confidence level matters more than it sounds. Most AI SREs give you a single answer and expect you to trust it. Sera AI tells you when it is guessing. A High confidence hypothesis with matching signals from three past incidents is a starting point. A Low confidence hypothesis is a nudge to keep looking. 

The evidence is what makes that judgment possible. Sera AI does not just name a cause, it shows the work behind it: the metrics that moved, the threshold that was crossed, the similar incidents that match. That is the difference between a black box and a colleague. An on-call engineer can read the evidence, agree or disagree, and decide how much weight the hypothesis deserves. 

See it in action

Here is what an investigation looks like from the on-call engineer's seat.

At 10:42 AM, Prometheus fires an alert on the Cart Service: Database Connection Utilization Increasing. Payments DB is at 82 percent of its connection pool.

Over the next thirteen minutes, six more alerts fire. Connection pool critical. Checkout API latency spike. Payment authorization failures. Orders API queue backlog. Each one from a different service. Each one technically a separate signal.

Without Xurrent IMR, seven alerts means seven pages, seven Slack notifications, and an on-call engineer opening seven tabs at 3am trying to work out whether this is one problem or four.

Xurrent's content-based correlation groups them into one incident before anyone gets paged. Same service, matching annotation patterns, inside a ten-minute window. Incident #8. One page.

The engineer opens the incident and clicks Investigate.

Sera returns a hypothesis in seconds. The orders-api message queue has accumulated 18,400 messages against a baseline of 120. That is 153 times normal. Processing latency has reached roughly 407 minutes. Consumer workers are either falling behind or have stopped entirely, and the likely causes are a downstream dependency failure, database connection exhaustion, or a crashed worker process.

Three things to do now: check worker process health and restart crashed consumers, scale consumer workers three to five times to drain the backlog, and verify that database connections, payment gateway, and inventory service are responding. One follow-up: add queue processing rate and consumer health metrics to dashboards so a stall gets caught before the backlog builds.

Note step three. Sera cannot confirm the database is the cause, so it tells the engineer to go check. That is what a good hypothesis looks like when the evidence is thin.

The engineer restarts the two workers holding connections. Pool utilization drops from 98 percent to 45 percent. Checkout latency returns to 420ms. The incident resolves in 26 minutes.

Then comes the part everyone skips.

Postmortems are where incident knowledge either gets written down or gets lost. Sera automatically drafts the post-incident review from the incident record: the correlated alerts, the timeline, the investigation steps, the resolution.

The engineer edits and publishes. And that postmortem becomes evidence for the next investigation. The Low confidence you saw above is what a cold start looks like. Every incident the team documents from here makes the next hypothesis sharper.

The innovation: your history, not the internet's

Here is what makes Sera different. Every hypothesis is grounded in your team's incident history.

When an alert fires, Sera does this:

1. Reads the alert payload: service name, error type, severity, thresholds from your monitoring
2. Finds the most similar past incidents your team has resolved
3. Pulls the postmortems, engineer notes, and Slack war-room threads from those incidents
4. Ranks the most likely causes and returns a hypothesis with evidence

This is what the industry calls incident similarity matching: using embeddings to retrieve past SEVs, tickets, and postmortems that match current failure signatures. What we have built extends that with the specific artifacts your team writes. The Slack thread from three months ago where someone typed "wait, is this the redis thing again?" and the answer that followed.

What is coming next

Sera gets sharper from here.

GitHub - Sera will cross-reference recent PRs and deploys against the incident timeline. If a config or code change landed in the last hour on the affected service, you will know. Roughly 80 percent of production incidents trace back to a recent deploy. Correlating that automatically means a big chunk of your investigations start with a strong lead.

Datadog, Grafana, Sentry - Connect your observability stack and every investigation gets richer signal. More context in, better hypotheses out.

Every incident Sera investigates also feeds back into the corpus. The postmortem your team writes today makes next month's investigation faster. The knowledge base compounds.

Where AI SRE is actually going

The debate over full autonomy will play out for a while. Sera is built on a simpler bet: the fastest way to fix an incident is to give the human on-call the first thirty minutes back. Not to replace them. To hand them a hypothesis before they finish reading the alert.

The Root Cause Agent is live today. 

‍

Try Sera AI →

‍