Datadog Shipped - 10/30/26

[blondecostanza]

Rounding out this week, 8 ships worth knowing about:

• Workflows and Bits Agent Builder, manageable from Bits Chat and coding agents via MCP
• Tap: turn any raw log into structured data in one click
• Pipeline Simulation for Log Pipelines
• Debug IDs for readable JavaScript stack traces on every deploy
• Self-serve migration tools for Splunk alerts, dashboards, and searches
• GPU Monitoring extended to inference workloads (Preview)
• A redesigned Ingestion Control page for APM
• Bits Testing: enter a URL, map every critical path, launch real browser tests

What shipped, why it exists, docs, and more.

1. Build and manage workflows and agents from Bits Chat and coding agents

What shipped: Workflow Automation and Bits Agent Builder tools are now available in the Datadog MCP Server. You can create and manage automations through Bits Chat, Slack, and AI coding agents like Claude Code, Cursor, and Codex, by describing the automation they want in natural language.

Why it exists: Acting on an automation opportunity used to mean leaving the tool you were working in, opening the Workflow Automation UI, and rebuilding context from scratch, usually mid-investigation or while chasing a fix. Now you build, run, and manage workflows and agents in natural language right where you already work.

How it works: Describe what you want, and the AI builds both halves: it picks the workflow's actions from 2700+ in the Action Catalog and puts them in order, then sets up the custom agent that runs inside it, with its own prompt, tools, skills, and MCP servers. You can also edit an existing automation by describing the change, validate and publish it (or unpublish and delete), and run and debug end to end, down to each step's status and output and the agent's own conversation. Not available in GovCloud.

Shipped by: Yuta Yoshida and Amber Tunnell

Docs: Launch blog post · Workflows MCP tool release note · Bits Agent Builder MCP tool release note

2. Tap: turn any raw log into structured, searchable fields in one click

What shipped: Tap, an AI-assisted capability that turns any raw log into structured, searchable fields in one click, with no regex to write. It works at query-time in the Log Explorer, at ingestion in Log Pipelines, and before logs leave your environment in Observability Pipelines.

Why it exists: The information needed during an investigation is usually buried in raw, unstructured log messages, and structuring it by hand means writing regex, which in practice means a handful of query experts end up bottlenecking everyone else's day-to-day debugging. Tap removes that bottleneck: any engineer can structure a log themselves and immediately filter, aggregate, and correlate on the fields that matter.

How it works: In the Log Explorer, Tap structures a log on the fly for your current session, no regex, no pipeline change, no re-ingestion. In Log Pipelines, Tap is available inside the Grok Parser: it generates the parsing rule with AI, previews the result, and applies it once you save, so the structure applies to every matching log going forward. The same capability is available in Observability Pipelines (on request) for structuring logs before they leave your own environment.

Shipped by: Nicolas Jung

Docs: Log Explorer docs · Log Pipelines docs · Observability Pipelines docs · Release note

What's next: Auto-Processing (automatically extracting core attributes like status, timestamp, service, and trace ID from custom application logs with no manual pipeline configuration), MCP support for configuring pipelines with agents, and Log Findings for capturing investigation context to share with Bits.

3. Pipeline Simulation: preview a log pipeline change before it ships

What shipped: Pipeline Simulation for Log Pipelines, which lets you preview the impact of a processor change against a live streaming view of your real logs before applying it.

Why it exists: A single bad processor change can have a high blast radius: silently dropping fields, breaking facets, or stopping monitors from firing for every team downstream, often without the person making the change realizing it. Pipeline Simulation lets you see the before-and-after shape of your logs, with a developer-friendly diff view, so you catch that kind of breakage before it reaches production instead of after.

How it works: When you edit an existing processor or add a new one, Pipeline Simulation shows a live, streaming preview of how it would transform your actual logs. This pairs with Pipeline Simulation on Observability Pipelines, so you get end-to-end visibility whether the pipeline runs in Datadog's cloud platform or in your own environment. Available in all regions, including GovCloud.

Shipped by: Nicolas Jung

Docs: Public documentation

What's next: Tap to Parse inside this same flow, Auto-Processing for custom application logs, and MCP support for pipeline configuration.

4. Get readable JavaScript stack traces on every deploy with debug IDs

What shipped: Debug IDs, a unique identifier injected into each JavaScript bundle and its source map at build time, so a minified stack frame gets matched to the correct source map by the bundle's content instead of its URL, service, or version.

Why it exists: Matching a minified stack frame to its source map used to depend on three values staying exactly in sync: service, version, and file path, between the source map upload and the RUM SDK configuration. Any drift silently broke unminification, and micro frontend setups needed one upload per service even when bundles were shared.

How it works: With Datadog Build Plugins (webpack, Vite, esbuild, Rollup, Rspack) v3.3.0+, set sourcemaps: { debugId: true, upload: true } and drop the old service/releaseVersion/minifiedPathPrefix config. Without the Build Plugins, upgrade datadog-ci to v5.24.0+ and run datadog-ci sourcemaps inject after the build, then datadog-ci sourcemaps upload --debug-id.

Shipped by: Quentin Sellem

Docs: Source map upload guide · Build Plugins source maps

5. Easily recreate Splunk alerts and dashboards in Datadog with self-serve migration tools

What shipped: Self-serve migration tools that translate Splunk SPL searches and bulk-migrate alerts and dashboards into Datadog, at no additional cost.

Why it exists: Moving off Splunk usually means rebuilding years of accumulated alerts, dashboards, and saved searches by hand, while learning a new query language at the same time. These tools remove both parts of that work.

How it works: Quick Translation takes a pasted SPL query and returns the equivalent Datadog log search, complete with live visualization on real log data and a step-by-step explanation of the translation. Bulk Migration takes an exported Splunk config file and translates every asset into a Datadog monitor or dashboard, with a central inventory to review and publish each result.

Shipped by: Usman Khan

Docs: Public documentation · Release note

What's next: Agentic migration (letting an agent drive the whole process), automatic import directly from a Splunk instance, and smarter translation that resolves more data discrepancies automatically.

6. Improve throughput and GPU efficiency of inference workloads with GPU Monitoring

What shipped: GPU Monitoring now covers inference workloads in Preview, giving full-stack visibility, metrics, traces, and logs together, for diagnosing slow or struggling model-serving deployments.

Why it exists: When an inference deployment slows down, the cause can live anywhere in the stack, the runtime, the router, or the hardware, and figuring out which one today usually means manually cross-referencing separate tools. This brings it into one place instead.

How it works: Covers time-to-first-token, intertoken latency, output tokens/s, error rate, and GPU KV cache usage for every model deployment, correlated with continuous, lightweight tracing of what's actually running on the GPU and CPU. Supports standalone vLLM, vLLM with NVIDIA Dynamo, vLLM on Ray, and SGLang. Available in all regions except GovCloud, no additional cost during Preview.

Shipped by: Kathy Lin

Docs: Setup and documentation

What's next: Enhanced deployment-level insights, automatic remediation workflows to improve throughput and GPU efficiency, and support for llm-d.

7. Get more visibility and control over APM ingestion with the new Ingestion Control page

What shipped: The redesigned Ingestion Control page is now generally available, bringing APM ingestion overview and service-level action into one place.

Why it exists: Managing APM ingestion used to mean piecing together information from several different views just to answer three basic questions: am I on track with my allotment, what's driving my ingestion, and where should I take action. The redesigned page answers all three in one place.

How it works: An ingestion overview (Monthly Ingestion, Adaptive Sampling Setup, Ingestion Over Time) shows ingestion, allotment, coverage, and trends at a glance. A per-service table organizes services by how sampling is managed (by APM, by other Datadog products, or by OTel), and bulk onboarding lets admins enable Adaptive Sampling for multiple services at once instead of configuring them one by one.

Shipped by: Francois Hereng

Docs: Release note

What's next: Bits-assisted ingestion optimization, and a dedicated view for orgs without a set allotment.

8. Bits Testing: enter a URL, map every critical path, launch real browser tests

What shipped: Bits Testing is 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 starting from a single URL.

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 by hand, 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 Ruxanda Lueck

Docs: Public docs · Blog post

What's next: Using Journey Monitoring telemetry as context so Bits Testing can suggest coverage for the flows customers are most likely to adopt, and self-healing tests that repair themselves when they break from configuration drift.

Questions or feedback on any of these? Drop a comment below.