Operations | Monitoring | ITSM | DevOps | Cloud

Sometimes the most important engineering work starts with a deceptively simple question. Not “What’s the best dashboard layout?” or “How many Ts are in Matt?” (still contested), but something much more fundamental: What if the read path and the write path didn’t have to share the same fate?

You know the situation: You're in a meeting and your alerts start to go off, but no one on the other side of the camera knows why you have to abruptly drop from the call. What if, instead, you had a robot in the background of your Zoom meeting that started to blink when those same alerts went off? You could just point to it, type in the chat "I have to drop," and off you'd go.

Let's talk about being new. Four months ago, I joined Grafana Labs as a senior solutions engineer. It wasn’t just a new company, it was a new industry. I came from the visual workspace provider Miro, where I was comfortable doing discovery and talking about visual collaboration and innovation. But stepping into observability? I was in the deep end. And let me tell you, the imposter syndrome was real. Everyone around me was fluent in this language of metrics, logs, and traces.

Dawid Dębowski is a software engineer at G2A.COM and a Grafana Champion. Holding an MS of Computer Science, Dawid’s main fields of interest related to observability are PromQL and data visualizations using Grafana. If you’ve ever worked with custom metrics in a Prometheus environment, you've probably heard about something called "high cardinality"—or at least I hope you have.

Your users should not be the first to know when your application goes down. When HTTP endpoints fail or respond sluggishly, users experience timeouts, connection errors, and degraded performance — often without clear indication of the root cause. This is where HTTP checks in Grafana Cloud Synthetic Monitoring come in, allowing you to proactively monitor your endpoints, verify they're online, measure response times, and ensure they're returning the correct status codes.

Every year, Grafana dashboards surface in new corners of the world. And this year, they even reached beyond this world—helping one team land on the moon and another monitor the planet’s health with orbiting satellites. Meanwhile, back here on Earth, the community used Grafana to track everything from wind turbines and wastewater to March Madness and Taylor Swift’s worldwide tour. Here’s a look back at some of the most memorable Grafana community dashboards of 2025.

Our annual Observability Survey provides some great insights on the state of industry and all things observability. And for the third edition of the survey, published last March, we wanted to bring the results into a Grafana dashboard—not just because we could, but because it was quite a nice way to interact with the data. After all, Grafana isn't just for IT observability. You can use it to monitor everything from BI data to lunar landings to pet pythons—and now, survey data.

Tracing is the richest observability signal in common use today. In distributed systems, it reveals how requests flow across multiple services, allowing you to uncover and address performance bottlenecks. Teams often scale back or abandon tracing altogether, however, because most successful requests produce redundant data that’s noisy and expensive to store.

As a vendor-neutral open standard, OpenTelemetry has become the default choice for application instrumentation. However, it’s important to remember that OpenTelemetry isn’t a single technology — it’s an ecosystem. Under the hood, it provides multiple options for instrumenting your applications. In this blog post, we explore two instrumentation approaches: OpenTelemetry eBPF Instrumentation and runtime-specific OpenTelemetry SDKs, like the OpenTelemetry Java agent.

Getting started with observability in a modern, fast-moving environment is harder than it should be. Open-standards-based observability promises flexibility and vendor neutrality, but in practice it often introduces significant complexity and delays meaningful coverage by months or even years. Each layer of the stack requires its own instrumentation approach, and every technology, runtime, and library version comes with unique setup steps, tradeoffs, and rough edges.