Operations | Monitoring | ITSM | DevOps | Cloud

Picture a familiar scene: a critical application goes down during peak business hours, and your on-call engineers scramble to restore service. Two weeks later, the same application fails again, frustrating your teams with the same symptoms, the same scramble, and the same customer frustration. If this pattern feels familiar, your organization may be strong at IT incident management, but underinvested in IT problem management.

Instrumenting a tech stack for distributed tracing is a complicated process that often takes weeks. For large fleets running services written in multiple languages, the timeline could be months. Every service needs a tracing library added, configured, and redeployed, and that work has to fit into each team’s release schedule. Datadog’s Single Step Instrumentation (SSI) cuts the time it takes to instrument your applications to send traces to Datadog APM down to minutes.

Until now, allocating by account name meant doing the work yourself: hand-building a custom dimension that mapped every twelve-digit AWS ID to a readable name, then maintaining it by hand in CostFormation. That mapping is fragile. Rename a definition or edit the wrong line and dashboards that depended on it quietly break. Now the account name is built in for accounts connected through AWS CUR 2.0.

How to recover deleted files from the SharePoint recycle bin - both stages, restore steps, PowerShell, the 93-day limit, and how to get back files that are already gone.

Tracking tests on non-default branches was one of the most requested capabilities during the Bitbucket Tests (beta). We heard you, and today, we’re shipping it. Most teams don’t ship from main. Integration happens on develop, stabilisation on staging, releases cut from release. Until now, Bitbucket Tests only tracked the tests from default(main) branch, leaving the branches that actually matter invisible. Multiple branch tracking in Tests changes that.

Since November, Kosli’s own engineering team has been running a live experiment: what happens to code review when the thing generating the code - and increasingly, the thing reviewing it - is an AI, not a person. Alex Kantor, Kosli’s Director of Technology, walked through that experiment in this webinar: what broke, what it cost to fix, and what four “obvious” assumptions in a standard code review control turned out not to hold once you took the human out of the loop.

As we entered 2026, enterprises raced to build internal AI engineering agents, automating incident response, code review, and support. The investment was real, but 88% of these pilots never reached production, and teams are now in rebuild mode, trying to understand why. Live runtime validation was the key architectural decision skipped in these v1 agents and it’s still missing from many v2 designs. Agents need to verify their reasoning against production before they act.

Roughly a year ago, I left Honeycomb’s SRE team to join the newly formed Tenant team, which works on our Private Cloud offering. This team held some significant challenges on its roadmap if it wanted to demonstrate that the offering was possible, would be worth the cost, and could be done without representing a heavy tax on the rest of the organization.

We recently released version 2.0.0 of Sentry’s Godot Engine SDK, bringing C#/.NET support and application metrics to general availability. That means you can now capture errors from your managed C# code and track custom metrics across your development and retail builds.