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.

The first half of 2026 reinforced a key idea about Cloud and SaaS reliability - dependency risk. IncidentHub tracked 30,246 outages across 1,082 providers between January and June 2026. May was the busiest month, with 6,070 incidents. Cloud providers led in the total number of outages (4,723), followed closely by developer tools (4,589).

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.