Operations | Monitoring | ITSM | DevOps | Cloud

Agentic AI in ITOps has emerged as a practical way to go beyond just detecting incidents. Modern IT teams have invested heavily in observability, yet the gap between detecting an issue and resolving it continues to widen. Three major challenges are driving this shift: This is where agentic AI makes a difference.

You shouldn’t have to grant full repository admin rights just to let an engineer or release manager trigger a deployment. To solve the all-or-nothing access problem, Bitbucket Pipelines introduces custom deployment permissions (Beta). You can now gate specific environments to authorized users and groups, ensuring safer releases and easier compliance. Left: Add users and groups to gate deployments for this environment.

The recent announcement that OpenTelemetry (OTel) has achieved CNCF graduation further reinforces OTel’s credibility as the industry standard for vendor-neutral telemetry. As organizations increasingly adopt the OpenTelemetry Protocol (OTLP), the OTel Collector, and OTel SDKs, they need an observability platform that supports OTel-native data without sacrificing flexibility or portability.

Software release management moves code through testing, approval, and into production with a clear rollback plan. 72% of organizations have hit a production incident from AI-generated code; developers now ship 63% faster (Harness, 2025). Effective release management needs defined stages, approval gates, automated testing, and the ability to roll back quickly. Feature flags, automated safety gates, and progressive delivery let teams ship faster and safer as AI raises code volume.

If your.NET app talks to MongoDB, you almost certainly want to be able to measure DB performance so that you can effectively debug any performance issues you might run into. For that, you need to know which database command was running, how long it took, and whether this was a one-off blip or part of a broader pattern. Ideally, you also want to pivot from that trace to related errors and replays without stitching the story together by hand.

Most PR review tools answer one question: does this code look correct? They scan the diff, flag known patterns, catch security violations, and post inline comments before merge, which is useful, but only half the review. The other half is behavioral: does the code actually behave correctly once it’s running against your live system?

Enterprise applications don't fail quietly anymore. A single checkout flow might touch a dozen microservices, three databases, a message queue, and two external APIs before a customer sees a confirmation screen.

A design partner told us the AI Explorer table needed a way to get data out so it could be saved and shared elsewhere. Now you export the whole view in one click, cost, tokens, cache, and model count all included. The values come through as clean numbers, not text you have to scrub. It’s the same pattern as Explorer, so there’s nothing new to learn.

If you run LLM features in production, your most dangerous failures are the ones your monitoring never flags. Your LLM feature passed every test, and the demo went great. Three weeks after launch, a support ticket lands: the chatbot quoted a refund policy that does not exist. The dashboards are all green, and the same prompt answers correctly when you retry it. This is the blind spot LLM observability exists to close. Your existing tools saw the request come back fast with a clean status code.

For years, the cloud migration business case was framed around one comparison: “Will AWS be cheaper than our data center?” That question still matters, but it is no longer where the value is. The 2017-2024 wave of mass migration is largely complete. Most enterprise workloads are already in the cloud - often in a lift-and-shift state: oversized instances, commercial-OS BYOL, on-prem-shaped network designs, and legacy frameworks that block the next step.