Loading video...
Video Failed to Load
Introducing the Elastic nightshift AI SRE – your always-on SRE coworker. •Investigates like an SRE, ruling out dead ends and showing you how it got there • Uses complete context from all your telemetry, not just what you could afford to keep • Finds unknown issues your alert rules... show more
210,242 views • 20 days ago •via X (Twitter)
7 Comments

What’s under the hood Context: what makes the other three work. It maps the services and hosts in your environment and how they relate, from your telemetry, and reads your wikis, runbooks, and code. Every investigation, postmortem, and piece of feedback adds to its long-term memory, so it knows your systems before the incident event starts. Investigation: starts from any alert, fired in Elastic or in a tool you already use. It forms hypotheses and tests them in parallel against logs, metrics, traces, and profiles. Dead ends get dropped. Every investigation ends with a conclusion, impact, proposed actions, and blind spots: what it couldn't verify. Drill from any step to the raw data. Detection: continuously evaluates your telemetry, with no rules to write. When related signals show up across services, it groups them into one Significant Event and can start an investigation before anyone looks. Remediation: picks an existing Elastic Workflow or connector action and fills in the parameters from this incident, or hands you commands for a terminal or coding agent. You can review each action before it runs, or let it apply fixes on its own. Elastic's own SRE team already runs this in production. See the announcement:

Recommending a fix with the evidence behind it is the right default. Can it also apply one? If so, I'd want to know who approves it and whether that approval lands in Kibana next to the investigation, before letting it anywhere near prod.

the ai sre finding issues your alert rules dont cover is honestly the scariest flex ive seen from a monitoring tool because that means my entire rulebook was just vibes

An AI SRE searching for "unknown issues without alert rules" sounds like an innovation until it triggers a catastrophic alert fatigue storm at 3 AM based on non-deterministic anomaly detection. We are replacing clean, deterministic log parsing with an expensive LLM reasoning loop that treats routine transient network blips as systemic infrastructure failures. How many false-positive pages are engineering teams expected to tolerate before admitting that production incident mitigation requires strict deterministic runbooks, not hallucinated context mapping?

"Showing you how it got there" is the feature that matters. An AI SRE that can't show its reasoning trail is just a faster way to be confidently wrong at 3am. Curious how the evidence trail is retained for post-incident review.

finding issues ur alert rules dont cover sounds great until it pages someone at 3am for nothing. how noisy is it?

An always on SRE coworker that can investigate issues, explain its reasoning, and recommend fixes could seriously change incident response. The ability to find problems beyond existing alerts is especially interesting.


