Operations | Monitoring | ITSM | DevOps | Cloud

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.

Like it or not, vibe coding is here to stay. It’s too easy to just go away. Maybe if the per token cost rises too much at some point that it becomes cheaper to hire a junior… But until then, you’d better get used to it. For now, tools like Cursor, Copilot, and Claude let developers (and plenty of non-devs) ship full-stack apps faster than a junior is able to completely grasp the concept of the app they’re working on. And that’s pretty neat.

When platform providers talk about autoscaling, they usually mean one thing: application autoscaling, adding or removing web instances based on traffic. The pattern is well understood. Define a metric, set a threshold, and let the platform act on it. Most platforms still leave database capacity as a separate, mostly manual problem. Teams either pre-provision for the worst hour of the worst day, upgrade plans on a calendar, or wire together their own scaling logic on Kubernetes or RDS.

Across the United States, data center projects are being stalled, local governments are putting ordinances in place to limit data center buildouts, all because people hate data centers. Due to community pushback, in Q1 2026 alone, over $130 billion’s worth of AI data center projects has been blocked or delayed.

A year ago, I wrote “It’s the End of Observability (and I Feel Fine).” The upshot of that post was that AI was about to fundamentally change the way we approach systems design and operation in the future. In the grand tradition, I’d like to revisit my claims from then and see how my predictions panned out.

You've optimized your Largest Contentful Paint. Your Time to First Byte is under 200ms. Your Lighthouse scores are green. And yet, your checkout conversion rate is quietly dropping. A segment of users in Southeast Asia is churning. Your support team is fielding tickets about a form that "just doesn't work" and you have no idea which one. Traditional frontend performance monitoring tells you whether your application is fast. It doesn't tell you whether people are actually succeeding when using it.

Every AI engagement runs on two clocks, and they no longer agree. The first is the intelligence clock, and it runs fast. The world it keeps time with re-renders every quarter. Models improve, inference costs fall, automation tightens, and the cost of producing a unit of work keeps dropping. This is the clock an enterprise believes it is buying when it invests in AI. The second is the contract clock, and it stopped years ago.