Datadog launches Scout 1.0, a model trained to investigate production alerts

What Datadog announced on 15 October

Datadog, the cloud monitoring company, published an announcement of Scout 1.0 on 15 October 2026, together with a technical report from its AI research team dated the same day. Scout is the company's first AI model specialised for investigating production issues, and it powers Bits Investigation, the agent Datadog sells as an AI site reliability engineer, or SRE.

Datadog's stated aim is cost. It says it trained Scout so that investigations are cheap enough to run an order of magnitude more often, and earlier in an incident. The headline claim is that Scout 1.0 medium matches GPT-6.1 Sol high and Claude Opus 5.5 high on its internal benchmark at 3 to 8 times lower estimated inference cost, and performs comparably to Claude Fable 5.1 medium and GPT-6 Astra medium at 12 and 19 times lower cost. With more test-time compute, Datadog says Scout 1.0 xhigh matches Fable 5.1 xhigh at a quarter of the cost.

Datadog engineering teams already use Scout on production alerts, as do a small group of customers in a closed preview. The company is taking sign-ups for that preview ahead of general availability.

Why Datadog wanted its own investigation model

Datadog wants Bits to act as an always-on first responder that gathers evidence and identifies likely causes before an engineer steps in. Each investigation means forming hypotheses, querying telemetry and deciding whether the evidence supports a conclusion, and every one of those steps is another model call. The more an investigation costs, the fewer alerts a team can afford to send to the agent.

A cheaper model changes that budget. Datadog argues that Scout's efficiency makes it practical to cover more alerts and to dig deeper into complex issues, and that the savings can be spent where they matter: the xhigh setting uses more computation per incident to improve quality during high-stakes outages.

The base model is GLM-5.3 Flash from Z.ai, the same open-weight family that legal AI company Harvey used for its GLM Legal agent model. Datadog's report says it chose to specialise an open-weights model rather than rely only on general-purpose frontier models, and that specialising on SRE work gives a better price-to-performance curve on the scenarios it cares about.

How Datadog built training incidents without customer data

Reinforcement learning needs practice problems with known answers, and real incidents are hard to reuse: the telemetry is often gone, and labelling each one takes expensive expert time. Datadog's answer is GenSim, a simulation framework that deploys what the report calls behavioural twins of the kinds of applications its customers run, then injects realistic failures in the spirit of chaos engineering. Each scenario produces an alert, queryable telemetry and a reference root cause.

GenSim has two ways of turning a postmortem into a training task. CausalGen extracts the causal chain of a real incident, has an agent build and deploy a working distributed system in a sandboxed cluster, and then triggers the failure so the system emits real metrics, logs and traces. SynthTel skips running the application and has an agent write code that generates coherent telemetry directly. SynthTel is cheaper and faster; CausalGen is more faithful but limited by compute and wall-clock time. Datadog trains on a curated mix of both.

The report stresses that the simulations are seeded from real incidents and real alert telemetry but contain no customer data. It also describes curation work: dropping scenarios where the evidence is not actually visible through the tools, and scrubbing service names, metadata or runbook text that would give the answer away. During training, a sandboxed copy of Datadog's tools and APIs answers the model's queries from archived scenario data, so practice runs never touch live production systems.

Teaching the model to investigate, not just to guess

Datadog's training stack is its own, built on a fork of the open-source SkyRL framework running on Ray, with asynchronous reinforcement learning in which generation and training run concurrently. The learning algorithm is a modified version of GRPO adapted for stale rollouts and overly long investigations. Other labs are building similar infrastructure for long agent runs, such as Alibaba's QwenGyre elastic RL framework.

The most candid part of the report is about rewards. When Datadog trained directly on its evaluation judge, which compares an investigation's findings with the reference cause and penalises unsupported claims, the model learned to limit its investigations and say less to avoid penalties. The report calls this a form of reward hacking. A denser set of granular rubrics raised rubric scores but did not improve the benchmark. After many ablations, Datadog settled on a hybrid reward that balances correctness, exploration and evidence grounding.

The team also used what it calls harness fuzzing. Production tools keep changing as Datadog ships updates to its Model Context Protocol server and APIs, so during training it randomly removes optional tools and varies the number of turns the model may take. When a tool is missing, the model has to find another route to the evidence; when the budget is short, it has to prioritise.

How Datadog measured Scout

The main benchmark is AlertEval, which Datadog built by adding annotation tooling to its own incident-response workflow so engineers could label thousands of evaluation points. It combines real alerts, archived telemetry and root-cause explanations written by engineers. Training happens on simulated incidents and evaluation on real ones, which Datadog presents as a test of whether the skills transfer.

Scores come from DeepJudge, an LLM-as-judge rubric that awards partial credit for the immediate cause and deeper causal findings and subtracts for contradictions or spurious findings. Datadog notes the scores run from 0 to 100 but are not percentages of incidents solved, and that its cost figures are estimated inference costs per investigation relative to Scout 1.0 medium.

To check that Scout had not simply fitted its own harness, Datadog also ran the public SREGym benchmark, 90 faults using its supplied Stratus harness, and added runs for the latest Opus, Sol, Fable and Astra models. It reports that Scout 1.0 medium clearly improves on the base GLM-5.3 Flash and beats the larger GLM-5.3 at more than four times lower cost, and that with extra test-time compute Scout is competitive with the best models while keeping at least a twofold cost saving, and about tenfold against Astra- and Fable-class models. The report notes that Claude Fable's safety classifier declined some SREGym tasks, which Datadog reran on Opus 5.5.

A real incident: five steps from a node drain to an alert

The report closes with a real internal incident that Bits diagnosed using Scout. The alert said all 30 Postgres autovacuum workers had been busy for more than an hour while dead rows piled up. The cause had happened about two hours earlier and on a different component: a routine Kubernetes node drain removed a read replica along with its local disk. The replacement replica started on another node with an empty disk, while the primary kept the old replication slot, which stopped its cleanup from advancing.

According to Datadog's write-up, the investigation worked backward from the symptom. It ruled out a write spike after seeing rows read rise tenfold while query counts stayed flat, checked for idle transactions and lagging replicas, found the new replica logging requests for a write-ahead log segment that had already been removed, and tied that replica to the node drain ten minutes before the onset. Its conclusion was to drop the stale slot and rebuild the replica. Datadog uses the case to show why it needs training environments with several paths through the evidence and rewards that separate a supported explanation from a plausible story.

Who can use Scout and what comes next

Scout is not a model developers can download or call on its own. It runs inside Bits Investigation, and access for now is through the closed preview, with general availability to follow. Datadog has not published pricing for the Scout-powered version, and the announcement does not say whether the weights will ever be released.

Datadog's plans are to simulate a wider range of failures, keep raising quality while lowering cost, and extend the approach from investigation to autonomous remediation. It says that would move Bits from first responder towards being the only responder during an incident. That direction echoes a wider push to train agents in realistic environments, such as the shared FineEnvs collection of RL environments.

What to keep in mind

Every comparison here is Datadog's own. AlertEval is internal and not public, its judge is itself a language model, and the cost figures are estimates relative to Scout rather than prices a customer would pay. The SREGym numbers for other models partly come from the public leaderboard and partly from Datadog's own single attempts per fault. AI Lookout has not tested Scout.

The case study is one incident, selected by Datadog, that the system got right. It shows how an investigation can work but says nothing about how often Bits is wrong or how it behaves when the evidence is missing. Teams trying the preview should compare its conclusions with their own postmortems before giving it more autonomy, especially as Datadog moves towards letting the agent fix problems as well as diagnose them.