Operations | Monitoring | ITSM | DevOps | Cloud

Continuous profiling is becoming a standard part of the observability stack, and for good reason. It's the only signal that tells you why your code is slow or expensive, not just that it is. Metrics tell you CPU usage is high. Logs tell you a request was slow. Traces tell you which service is the bottleneck. But only a profile tells you which function, on which line, is burning the cycles. As systems grow more complex, that level of visibility becomes essential.

The ways you and your teams build and observe your systems are changing. It’s no longer just engineers looking at dashboards, or writing queries or config files. More often, it’s an agent interacting with the data, too, helping write code, run applications, investigate incidents, rightsize deployments, and more.

A modern web application is not a single thing. A single user request may touch a web server, a database, a cache layer, and several third-party APIs before a response comes back. And as AI tools generate more and more application traffic (API calls, background jobs, automated workflows), the volume and unpredictability of that traffic is growing. When something goes wrong, it could be any of it. When something is slow, it could be all of it at once.

Q1 2026 has been one of our most eventful quarters yet for VictoriaMetrics Cloud. We shipped something we have been building towards for a long time, crossed a few infrastructure milestones, and started clearing the path for what is coming next to the most performant observability stack.

The shift from legacy middleware to open-source innovation promises agility and cost savings, but introduces the 'Modernization Tax'—operational complexity that requires new approaches to observability, governance, and management across hybrid messaging environments.

Most of us run multiple virtual private servers (VPS) at a time. That’s why it’s important to keep an eye on the CPU usage and memory. However, since this step often slips our minds, there is room for automated monitoring. Open-source tools tend to be a default choice, and for a good reason. The problem is that they don't provide everything you need for monitoring in a single place. As a result, you may find yourself writing custom shell scripts for automation.

Setting up website monitoring has always meant a small but annoying detour. You spot a page worth watching, copy the URL, switch tabs, log into your monitoring tool, paste, configure, save. By the time you’re done, you’ve lost whatever train of thought sent you there in the first place. We’re fixing that. Today we’re excited to announce the ChangeTower Chrome Extension — now open for waitlist signups.

UK organizations are increasingly required to design systems that account for data residency requirements, ensuring that operational data remains within national boundaries. Many teams already run their applications on AWS infrastructure in the UK, but telemetry data can still be processed outside the region, creating gaps in visibility. Datadog’s upcoming UK availability zone solves this by keeping telemetry data in the same region as the workloads that generate it.

Developers and SREs who rely on Microsoft Azure DevOps often face fragmented workflows when investigating issues or reviewing code quality. Troubleshooting an error can require jumping between observability tools and source code repositories as you manually connect traces, stack frames, and commits. At the same time, security vulnerabilities, misconfigurations, and flaky tests may go undetected until later stages of the software delivery life cycle (SDLC), where they are more costly to fix.

For years, infrastructure stability could be approximated through static limits. If CPU utilization exceeded a defined percentage or response time crossed a fixed boundary, risk was assumed to increase in a predictable way. Monitoring systems were designed around that assumption, and for contained environments, it largely held true.