Operations | Monitoring | ITSM | DevOps | Cloud

One of Grafana’s greatest strengths is its ability to provide a consistent monitoring experience for all your data sources. But not everyone wants to go through the process of transforming that data and setting up a data warehouse to make that happen, especially for complex analyses.

In May, we announced the public preview of Prometheus native histograms in Grafana Cloud, unlocking greater precision, ease of use, and compatibility for analyzing latency, duration, and other distributions. Since then, we’ve seen incredible adoption across industries—from financial services companies to e-commerce platforms. Last week, during PromCon EU 2025, the Prometheus developers announced that native histograms are now stable, after three years of intense testing and improvements.

Writing queries is one of Grafana’s most powerful features, but it can also be one of the most time-consuming. Whether you’re exploring logs or building new dashboards, you often find yourself and your team rewriting the same queries over and over again. This is why we rolled out saved queries, a feature that makes it easy for everyone on your team to save, share, and reuse queries, eliminating the need to start from scratch each time.

With the end of the year fast approaching, we want to let you know about some important dates for our upcoming release freezes. Our annual release freeze helps ensure stability for everyone during the holiday season, which is a critical time for many of our customers. This pause helps us protect our on-call teams and maintain a smooth experience for you.

Grafana Tempo 2.9 is now available, delivering MCP server support, TraceQL performance improvements, and more. Watch the video below to see the Tempo MCP server in action and learn how to speed up TraceQL metrics queries, or continue reading to get a quick overview of these and other updates. The Grafana Tempo 2.9 release notes and changelog provide more in-depth details and include all of the changes that came with this release.

When you start building an observability stack, it’s natural to reach for logs first. They’re familiar, easy to generate, and often already part of a developer’s workflow. And sending logs to a centralized system feels like a quick win, too. Simply add a log shipper, and voila, your application is observable.

This meeting could’ve been an email. It’s a phrase most of us have said (or at least thought) at some point in our careers. For me, that realization hit years ago while working for a government organization. I’d frequently sit through long, agendaless meetings that seemingly went nowhere. I wasn’t sure why I was there. And because I’m an engineer at heart, I started to wonder: what were these meetings actually costing the organization?

In observability, we’ve traditionally been taught to think in terms of pillars, namely logs, metrics, and traces (and more recently, profiles). But pillars are rigid and disconnected. They don’t reflect how modern systems actually work or how we troubleshoot in real time. So let’s change that.

When you operate a restaurant, the last thing you want to do is shut your doors and turn away guests and staff because of some technology failure. And if you’re the one providing that tech, it’s your job to make sure that doesn’t happen. “For us, observability is about a lot more than just dashboards and alerts.

The benefits of observability are clear: deep visibility into system health, faster troubleshooting, and improved reliability (to name a few). But what’s equally clear is that, as organizations scale and evolve their observability strategies, they need a way to tap into these benefits without runaway costs. According to Grafana Labs’ 2025 Observability Survey, 74% of respondents say cost is a top priority for selecting tools.