Elastic nightshift AI SRE: Start With the Investigation Engine

Most AI SRE pitches arrive as one box: plug it in, and it detects, diagnoses and fixes. That is a hard thing to say yes to, because you cannot grant the part you want (a second opinion on a 3 a.m. page) without also granting the part you fear (something running commands in production).

Elastic's nightshift announcement of 8 October 2026 is built differently, and that is the interesting part. I have not been given preview access, so this post is a close reading of Elastic's announcement, its sign-up page and the Workflows documentation, plus my own argument about rollout order. Where something is my judgement rather than Elastic's statement, I say so.

What Elastic actually announced

Elastic announced nightshift AI SRE as a Private Preview inside Elastic Observability, and says its own SRE team has been running it against Elastic's production environment. The agent watches telemetry continuously, detects problems including ones no alert rule covers, investigates them, and recommends or applies fixes. Every reasoning step can be followed and the raw data behind it opened.

Access is a waitlist. The announcement says Private Preview is open to existing Elastic users at no cost during early access, and the sign-up page words it as free for existing users in Elastic Observability Serverless, which is the only deployment supported today. The pages give no price for after the preview and no general availability date, so treat anything you read about cost as unknown.

Four engines, each usable on its own

The structural claim is that nightshift is four engines rather than one agent, and that you can use any of them independently. This table is condensed from Elastic's own description of each engine.

Read the Trigger column as a dependency graph. Investigation is the only engine that can start from something you already own, an alert, while Detection creates new signals and Remediation needs a finished investigation to act on. That asymmetry is the whole basis for the rollout order in the next section.

Why Investigation alone is the low-risk entry

My argument, not Elastic's: adopt Investigation first, on alerts that already page you. It adds no new alert sources, so your pager volume cannot change. It touches nothing, because acting is Remediation's job. And it hands you something you can grade, since a human already knows how each of those incidents actually ended.

Compare the alternatives. Turning on Detection adds a stream of Significant Events that nobody has defined an on-call response for, so you are measuring the agent and redesigning your alerting at once. Turning on Remediation without a track record asks you to trust parameters you have never seen it choose. Investigation first lets you build that record before either is switched on.

Elastic's description supports the safe reading in two ways. Each proposed action waits for user review, and every investigation step and the raw data behind it is inspectable, so a wrong conclusion can be traced rather than merely distrusted. One thing I could not confirm from the pages I read is whether Investigation works well without the Context engine running, so ask that on the waitlist call.

Wire up the alerts you already have

Before the agent touches anything, record what it will be judged on. Elastic's Workflows are YAML automations in Kibana with triggers, inputs and steps, and the triggers page says an alert trigger starts a workflow when a detection or alerting rule raises an alert, with the alert exposed through the event field. This is a baseline recorder, not nightshift configuration.

# Kibana Workflow: record every alert as a baseline BEFORE any AI touches it.
# Syntax follows Elastic's Workflows docs: triggers with "type: alert", the
# alert exposed under "event", and a "console" step that prints a message.
name: alert-baseline-recorder
description: Log each alert the AI SRE pilot will later investigate
enabled: true
tags: ["ai-sre-pilot", "baseline"]

triggers:
  - type: alert        # starts when a detection or alerting rule raises an alert

steps:
  - name: dump_event
    type: console
    with:
      # Print the whole event first. The docs page says it carries fields,
      # severity and rule information, but does not list the exact paths,
      # so read one real payload before you template individual fields.
      message: |
        alert received at ingest time
        event: {{event}}

The announcement says Investigation can be started by any alert in Elastic or a connected tool, but the pages I read do not document how that connection is configured during the preview, so I have not invented settings for it. The Kibana side is plain alerting: a rule has conditions, a schedule and actions, and actions send notifications through connectors such as email or Slack.

The practical point is ordering. Keep your existing rules and connectors exactly as they are, add the recorder, and let a week of alerts accumulate with timestamps before any investigation exists to compare against. Otherwise you will remember the agent's version of events rather than your own.

Remediation: make review mean something

Elastic says the Remediation engine picks an Elastic Workflow or connector action and fills in the parameters, and that each proposed action waits for review. Users choose how much the agent does alone: review each action and its parameters before it runs, or let it apply fixes automatically.

That second option is a setting you will be tempted by, and the first option is only as good as the reviewer. A reviewer who clicks approve on every proposal is auto-apply with extra steps. So I would write down, in advance, what a reviewer reads and when they refuse. The block below is my own template, because nothing in the announcement defines such a file.

# MY OWN review rubric, not Elastic syntax. Nothing in the announcement
# defines a policy file; this is what I would write down before enabling
# Remediation, so that "review each action" means something specific.
remediation_review:
  default: human_approves_every_action
  read_before_approving:
    - the Workflow or connector action chosen
    - every parameter value it filled in
    - the investigation step that justified it
    - the blind spots the investigation listed
  never_approve_when:
    - a blind spot overlaps the target service
    - the parameters name a resource the root cause did not mention
    - the action cannot be undone and nobody is on call to watch it
  auto_apply:
    allowed: false           # revisit only after a month of approved-as-written actions
    candidate_actions: []    # start empty; add one reversible action at a time

Elastic's Agent Builder page notes that Elastic Workflows can be exposed as reusable tools, which hints at why the action catalogue matters: the safest Remediation setup is the one with the fewest, most reversible actions on offer. Start with a short list you would be comfortable running yourself, and grow it deliberately.

Failure modes and trade-offs to price in

The first is evidence. The pages I read contain no published accuracy, precision or time-to-resolution numbers for nightshift, and the one stated proof point is Elastic's own SRE team using it in production. That is a reasonable signal for a preview and not a benchmark. The sign-up page does show customer figures, but those describe Elastic Observability, not this agent, so do not carry them over.

The second is borrowed numbers. Elastic's context engineering post reports tool calls falling from 33 to 9 and input tokens down 71 percent, but it describes a single simulated example, not a general benchmark and not nightshift. Quote it as an illustration of why pre-built context helps, never as an expected result.

The third is coverage. Serverless data is supported now. Elastic Cloud Hosted, self-managed clusters, third-party observability tools and other telemetry stores are planned for a technical preview later this year, and the Slack integration is still in development. The Kibana home page, Elastic CLI and MCP are the surfaces named today. If your telemetry lives elsewhere, your pilot is a waiting game.

Four adoption stages compared

The same four engines give four very different risk profiles depending on how much you switch on. This is my comparison of the stages, derived from Elastic's engine descriptions, not a vendor-published rollout guide.

Context sits underneath all four stages. Elastic describes it as feeding the other engines, so expect to grant it data and system access early, and decide who may see runbooks and wikis before it reads them.

What to do on Monday

None of this needs preview access to start. These five steps get you ready, so that when access arrives you are measuring rather than guessing.

1. Join the waitlist through the sign-up page, and confirm your deployment: only Elastic Observability Serverless data is supported at the moment.
2. Deploy the alert baseline recorder, then collect a week of alerts with their real resolutions written by the engineer who handled each one.
3. Pick one noisy but low-stakes service as the pilot scope, and ask Elastic in writing how an alert from your setup reaches Investigation and whether Context must be on.
4. Run Investigation only. Score every report with the scorecard below, including whether the miss fell inside a listed blind spot.
5. Write the Remediation rubric before enabling it, and let the scorecard decide when the engine earns its first action.

# Pilot scorecard: one row per investigation, filled in by the on-call human.
# Score against the incident's real resolution, not against how confident
# the report sounded.
alert_id:            # the alert that triggered the investigation
human_root_cause:    # written by the engineer, BEFORE reading the report
report_root_cause:   # copied from the investigation conclusion
verdict:             # match | partial | wrong
blind_spots_listed:  # yes | no  (did it admit what it could not check?)
blind_spot_was_real: # yes | no  (was the missed cause inside a listed blind spot?)
minutes_to_first_useful_hypothesis_human:
minutes_to_first_useful_hypothesis_report:
proposed_action:     # what Remediation would have run, even if you never enable it
action_would_have_helped:  # yes | no | harmful

A month of scorecards is also the only evidence you will have that is about your systems. A vendor's production anecdote, however honest, is about theirs.

The useful idea in nightshift is not the autonomy, it is the seams. Because the Context, Detection, Investigation and Remediation engines are separable, you can accept the smallest piece that earns its place and refuse the rest until it has a record. Start where the agent can only read, grade it against what your humans concluded, and give it the right to act last.