Operations | Monitoring | ITSM | DevOps | Cloud

Ask a platform team why their application logs aren't in their observability backend and you'll often get a one-sentence answer: And, that's where the conversation ends. The logs stay in a silo. Or, they don't get collected at all. The team loses the troubleshooting signal, and nobody revisits the decision because the alternative looks like a compliance violation. Application logs in healthcare, aviation, insurance, and retail are full of personal information that should not be stored in plain text.

Full-Pipeline Blueprints are the headline, and Scoped API Keys went to preview. Here is the rundown.

Blueprints launched as processor bundles, and that solved the repetitive middle of the problem. But the middle was never the whole job. You still had to know which source type to add, which parameters mattered, how to batch for your backend, and how to route it all together. That changes now. The first two cover the two requests we hear most.

By the time an IoT device shows up in an incident review, it has usually already done its damage. Not the dashboard-gap kind. These devices are load bearing. They sit in the control path of substations, haul trucks, pump stations and cold rooms, so when they go blind the blast radius gets measured in tripped relays, spoiled stock, and unplanned outages rather than in missing datapoints.

Originally written by Paul Stefanski, updated by Dylan Myers. Data costs fill a large column in many organizations' accounting sheets. Data pipeline setup and management is a significant time sink for DevOps, IT, and SRE. Setting up telemetry pipelines to reduce unwanted data often takes even more time, which could better be spent creating value rather than reducing costs. This post will show you how to quickly set up your data pipeline to filter unnecessary telemetry data.

The new Advanced Pipeline Editor went live for all paid plans, we launched a public Blueprints library of ready-made pipeline patterns, we reworked plan pricing and raised the Free tier to 100 GB/day, and the source and processor catalog grew with an AWS Neuron source, an AWS CloudWatch metrics source, and a full set of XML processors. None of these are flashy on their own.

The Advanced Pipeline Editor is now live for all paid Bindplane plans. It's a rebuilt configuration editing experience that puts your whole config in a single interactive graph: every source, processor, router, and destination, across logs, metrics, and traces, in one view you can search, pan, zoom, and edit directly. If you've ever bounced between pipeline tabs trying to figure out where a processor sits in a config with a dozen sources and three destinations, this release is for you.

Chelsea and I recently wrote a guide on how we monitor Claude Code usage internally with Bindplane. TLDR; We remotely manage a Bindplane Distribution of the OpenTelemetry Collector (BDOT) that runs on every engineer's laptop. This setup is great, but it has one downside. Sending to Google Cloud Monitoring, Swarmia, and any other destination directly from an engineer’s laptop is limited to local processing. You can’t get the benefit of centralized routing and processing on a gateway.

If there was a theme this month, it was making the hard parts of a telemetry pipeline less risky. For SIEM customers, we shipped an ASIM-native Microsoft Sentinel destination and automatic OCSF mapping in Pipeline Intelligence, two of the most-requested pieces for teams routing security data through Bindplane. On the platform side, we added config rollback, which turns "I changed something and now it is behaving differently" into a one-click trip back to a known-good version.

If you're sending security data to Microsoft Sentinel, you now have a faster path. A new ASIM mode lands your logs directly in Sentinel's native ASIM tables: no custom tables to predefine, no schema to design before data flows. We added ASIM mode to the Microsoft Sentinel destination, backed by a new ASIM standardization processor that converts raw logs to ASIM in the pipeline and routes each record to the table it belongs in. Here's how it works, and why we built it this way.