Repository navigation
Datadog Shipped - 10/16/26 #3
blondecostanza
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Kicking off this roundup. 7 things landed this week:
What shipped, why it exists, and more.
1. Scout 1.0 is public: frontier-level investigations at a fraction of the cost
What shipped: Scout 1.0 (known internally as Scooby until a trademark review forced a rename) is Datadog's own model for investigating production incidents, and it's now public. Scout powers Bits Investigation. It's trained specifically to cut inference cost, so investigations are cheap enough to run an order of magnitude more often and earlier in an incident.
Why it exists: Running a frontier general-purpose model on every alert and investigation gets expensive fast, which pushes teams toward investigating less often or only after things have clearly escalated. A model purpose-built for this one job changes that math.
How it performs: On AlertEval, Datadog's benchmark of real production alerts, Scout 1.0 medium matches Claude Opus 5.5 high and GPT-6.1 Sol high at 3 to 8x lower cost. It performs comparably to Claude Fable 5.1 medium and GPT-6 Astra medium at 12x and 19x lower cost, and Scout 1.0 x high matches Claude Fable 5.1 xhigh, the strongest model tested, at 4x lower cost. On the public SREGym benchmark, Scout is competitive with the best models at 2x or more lower cost, so the gains carry over to tasks it wasn't trained on.
Where it stands: Datadog's own engineering teams and a small group of design partners already use Scout on production alerts today. It's rolling out to customers now
Shipped by: Othmane Abouamal and team
Docs: Blog post · Technical report · Preview sign-up
2. Claude Platform now exports OTel traces natively, with Datadog as a launch partner
What shipped: Anthropic's Claude Platform now natively exports OpenTelemetry traces from Claude Managed Agents, the Messages API, and the Claude SDKs, in public beta. Datadog is an official launch partner in observability.
Why it exists: Teams building on Claude previously had limited visibility into what their agents were actually doing in production. Native OTel export means that data can flow into whatever observability backend a team already uses, Datadog included, without custom instrumentation.
How it works: Set up the integration from the Claude Console under Settings, Telemetry Destinations, and add Datadog as a destination. Traces appear in Datadog's LLM Observability product alongside everything else you're already monitoring.
riverside_edit_02.-.datadogclaudeotelface_elizabeth.s_studio.mp4
Shipped by: Kyle Verhoog and the ML Observability team
Docs: Datadog setup guide · Anthropic's Claude Platform OTel docs · Anthropic's launch blog post
3. Bits Testing discovers critical user flows and covers them end to end
What shipped: Bits Testing is now generally available. It's an AI agent that interacts with a web application the way a real user would, maps the critical flows it finds, and generates browser, HTTP, and network path tests to cover them, all from a single click.
Why it exists: Building meaningful test coverage has always required someone to first decide which flows are worth testing, then script or record each one, then keep it updated as the app changes. That's a tedious process, so important flows often end up untested. Bits Testing removes the scripting step and helps with the triage step too, by proposing flows based on how the app is actually used.
How it works: Point Bits Testing at a URL (including authenticated environments via Profiles and Private Locations), describe what you want covered or pick a suggested prompt, and it runs a discovery job that proposes test suites for review. Every generated test runs once for free before you decide whether to save it; saved tests run on the standard Synthetics pricing model.
Shipped by: Younes Berradia and the Synthetic Monitoring & Testing team
Docs: Public docs · Blog post
4. AI-native SAST catches what rule-based scanners miss
What shipped: AI-native SAST is now generally available for all SAST customers, at no additional cost. It's a second detection engine that runs alongside rule-based SAST, tracing how data actually moves through code instead of matching known-bad patterns, with a second AI model that double-checks every finding before it's shown.
Why it exists: Many real vulnerabilities span several steps, like a value typed into a search box that passes through a few functions before reaching a database query unchecked. No single line looks wrong in isolation, so rule-based scanners either miss it entirely or need rules broad enough to flag hundreds of safe paths along with it.
How it performs: On the OWASP Benchmark, it found 86% of SQL injection vulnerabilities versus 63% for traditional rule-based SAST, 90% of command injection versus 59%, and 93% of cross-site scripting versus 65%. It also covers prompt injection and other risks from the OWASP Top 10 for LLM Applications. About 970 organizations used it during its preview over the past six months.
How to use it: Turn on "Enable AI SAST" on the Code Security setup page, for all repositories or selected ones (requires Datadog-hosted scanning). Findings show up alongside rule-based results, as PR comments, and in CI through PR Gates. Supports 14 languages today.
Shipped by: Tae Kim and the Code Security team
Docs: Public docs · Blog: open-source AI SAST · Blog: detecting LLM vulnerabilities
5. Bits AI Investigations now use everything happening in the incident channel
What shipped: Bits Investigations for incidents is now generally available. Responders can run investigations using full incident-specific context, including linked Datadog telemetry and anything shared in the Slack or Teams channel or on the bridge call, not just monitor data.
Why it exists: Critical incident details don't only come from telemetry. They live in the conversations responders have while working the incident. Previously, Bits AI could only be started from a monitor alert or a general prompt, so it missed everything happening in the channel itself.
How it works: Any responder can trigger an investigation from a command or a button click in Slack or the web app. Bits ingests the incident's Datadog telemetry plus chat and bridge call context, posts live threaded updates as it works, delivers a final root cause analysis and suggested remediations, and saves the record to the incident for post-incident reference.
Shipped by: Sam Rodman and the Incident App team
Docs: Public documentation
6. Journey Monitoring brings synthetic coverage, real-user performance, and product analytics into one view
What shipped: Journey Monitoring is now generally available at no additional cost for customers with Synthetics Browser/Mobile Testing, RUM without Limits, or Product Analytics. It unifies three previously separate signals around a single critical user flow, like signing in or checking out: how users progress and where they drop off, whether the flow is slow or failing for real users, and whether it has synthetic test coverage.
Why it exists: When users abandon a flow, figuring out why usually means piecing together signals scattered across separate products, which makes it hard to agree on impact or where to focus. Journey Monitoring gives product, engineering, and QA teams one shared view of journey health instead of three disconnected ones.
How it works: Datadog suggests journeys based on real user activity, or you define your own start and end events. A unified health status (Healthy, Degraded, or Missing coverage) rolls up SLOs from linked RUM operations and Synthetic tests, and the journey details report connects user progression, Session Replays, operation performance, backend dependencies, and test results in one place. A Journey Monitoring API supports managing journeys at scale.
Shipped by: Younes Berradia and the Synthetics, RUM, and Product Analytics teams
Docs: Public docs · Blog post
7. Network Device Monitoring now correlates issues to endpoints, paths, and VPN tunnels
What shipped: The NDM dependency view is now generally available with support for connected endpoints, network path tests traversing a device, and VPN tunnels, all on the same screen as the device itself.
Why it exists: When a network device has a problem, figuring out the blast radius, whether it's network-related at all, and who else is affected previously required context-switching across multiple products with no shared starting point. This puts all of it on one screen.
How it works: From a device's Dependencies or Network Paths tab, select Endpoints, Network Devices, or VPN Tunnels. Connected endpoints show device name, status, signal strength, and active issues, with a direct link into End-User Device Monitoring. Network path tests crossing the device show source, destination, latency, and reachability. VPN tunnels show a topology graph with peer IPs, protocol, and destination subnets. Endpoint dependencies require End-User Device Monitoring (in preview); path dependencies require Network Path; VPN dependencies require VPN Monitoring to be configured.
Shipped by: Kyler Kang and the Network Device Monitoring team
Docs: Dependencies documentation · VPN Monitoring · End-User Device Monitoring
Questions or feedback on any of these? Drop a comment below.
All reactions