GrafanaCON 2026 in Barcelona: Back Where It All Began

Hands-On Lab

We arrived in Barcelona on Sunday evening to be ready for Monday’s hands-on lab, a dedicated session called “Alloy in Action: Build telemetry pipelines with OpenTelemetry and Prometheus.” Alloy is Grafana’s open source distribution of the OpenTelemetry Collector.

In this lab, we took control of the operation center for a network of agents, configuring our setup to receive and centralize their telemetry. To get there, the lab walked through building a full telemetry pipeline from scratch: receiving, transforming, and exporting metrics, logs, and traces from a sample application to the respective backends. For anyone who has spent time wiring together separate scrape configs, remote_write targets, and OTel exporters by hand, Alloy’s unified configuration model makes the process much easier to manage. As if learning how to build a proper telemetry pipeline was not enough, we also left with one of the coolest stickers of the entire conference. The workshop material is open source and available on GitHub for anyone who wants to work through it independently.

Keynote

The full recording of the opening keynote is available on YouTube, and Grafana Labs published a detailed write-up of everything announced.
The keynote focused on three themes: easier onboarding, scaling large deployments, and broader platform availability. Grafana Labs also shared updated company metrics, including 35 million active users, over one million companies using Grafana, and $400 million in annual recurring revenue.

The following sections cover the announcements and talks that stood out most to us.

Grafana 13

Grafana 13 was the main product release of the conference. Several features are immediately practical for anyone running Grafana for a team.

Suggested Dashboards

When you connect a data source in Grafana 13, it can now surface pre-built community dashboards compatible with that data source, alongside a compatibility score showing how well each dashboard will work with your specific data. You can preview any of these against your live data before importing. For anyone who has had to start from the community library manually every time a new data source is connected, this removes a meaningful step.

Dashboard Templates

Grafana 13 ships built-in templates based on common methodology frameworks: DORA metrics, RED method, USE method, golden signals, and service health. The integration with Grafana Assistant is what turns these from simple starter templates into something genuinely practical: it can scan your connected data sources, identify relevant metrics, and populate the template with actual queries automatically. The result still requires refinement, but the heavy lifting of mapping your data to a known structure has already been done. Org-defined templates are also coming as an experimental feature, allowing platform teams to publish their own templates for the rest of their Grafana instance.

GitSync

GitSync enables a bidirectional integration between Grafana and a Git repository. Dashboard changes made in the UI can generate a pull request that your team reviews. When a change is merged in the repository, Grafana picks it up and applies it automatically. This makes a proper GitOps workflow for dashboards practical without external tooling or workarounds. GitSync now supports GitHub, GitLab, Bitbucket, and bare Git repositories, and is marked as production-ready in Grafana 13. As a side effect, it also serves as a disaster recovery mechanism: the full state of your dashboards is always in version control.

Dynamic Dashboards

Dynamic dashboards, introduced in the previous release, are now generally available. They support tab-based layouts within a single dashboard, which lets multiple audiences work from the same URL and the same shared context. An engineer, a product manager, and an executive can open the same link during an incident and navigate to the tab relevant to them, with shared filters applying across tabs automatically. Section-level variables let you scope filters to specific tabs or rows rather than the entire dashboard. Combined with auto-grid layout, which removes the manual panel resize work, building a multi-audience dashboard is noticeably less tedious.

The full deep-dive session is available here.

Loki’s New Foundation

The Loki sessions were some of the most technically significant of the conference and focused largely on the architectural direction toward Loki 4.0. Loki’s original architecture was optimized for low-cost log storage by avoiding full indexing and scanning chunks at query time. That model worked well for years, but the shift toward structured logging and high-cardinality queries has pushed the architecture toward its limits.

A major change is the introduction of a new columnar storage format called DataObjects. Instead of storing timestamps, metadata, and raw log lines together, Loki can now read only the specific fields needed for a query. Combined with a redesigned query engine, Grafana Labs reported internal results of up to 20x less data scanned and 10x faster analytical queries.

The ingestion pipeline is also changing. Loki now supports Kafka-backed ingestion to separate reads from writes and prevent expensive queries from impacting ingestion performance. The team was candid about the trade-off: Kafka increases system complexity, but at their scale the previous architecture had already become difficult to operate reliably.

Grafana Labs also announced the acquisition of Logline, a company focused on secondary indexing for log search. Their technology reportedly reduces bytes scanned for full-text search by up to 99%, addressing one of Loki’s long-standing weaknesses.

The full architecture talk is available here.

Scaling Grafana Assistant

The AI session from Ivana Huckova and Yasir Ekinci opened by joking that it was “the mandatory AI talk,” then turned into one of the more technically grounded sessions of the conference. The talk covered the engineering challenges of running a production AI agent at scale, which is a more useful conversation than a feature announcement.

Context Engineering

The Grafana Assistant team structured their approach around three layers of context. The first is what your environment contains: dashboards, data sources, running services. A new “memories” capability handles this layer by running weekly background scans of connected observability data sources, discovering services, grouping them into logical domains, and building a persistent map of what is monitored and how. This means the assistant no longer starts from zero with every conversation. The second layer is what your team and organization knows: runbooks, triage procedures, internal APIs, and institutional knowledge that lives in someone’s head. A new “Skills” feature lets teams encode this as repeatable workflows. When someone asks a relevant question, the assistant searches the skill library and applies matching procedures automatically, even if the user never mentioned a runbook by name. The third layer is what you are doing right now, addressed through context hooks in the UI: one-click actions such as “explain this trace,” the ability to point to a specific panel, and image attachments for describing dashboards visually.

Context window management is handled through deferred tool loading for less common capabilities, context compaction for long conversations, and output summarization for large query results.

Self-Improvement Loop and o11y-bench

The team built a benchmark suite called o11y-bench, published as open source, that runs the assistant against a real Grafana stack and grades it on a defined set of observability tasks. The raw pass rate was acceptable, but consistency across multiple runs of the same task dropped significantly: a problem they described as the “flaky test” problem applied to AI behavior. Their solution was to use coding agents to propose changes to prompts and tool instructions, verify the changes against the benchmark, and merge only improvements. This closed loop makes it possible to iterate on assistant behavior while keeping regressions visible before they reach production.

AI Observability

The product for monitoring AI agents in production started as an internal tool for the Grafana Assistant team. It tracks inputs, outputs, execution traces, latency, cost, and output quality for agent runs in production, and is now in public preview for external use. The gcx CLI tool was also announced, giving engineers a way to query Grafana Cloud from within agentic coding environments like Claude Code or Cursor without switching to a browser tab.

The full talk is available here.

Further Highlights

LEGO’s Dashboard Framework

Paul Farver and Lorenzo Setale from the LEGO Group presented the observability dashboard framework their platform team built using the Grafana Foundation SDK. We already know Paul from the Swiss Cloud Native Day 2025 on the Gurten, and the presentation style is unchanged: technically precise, self-aware, and funnier than most conference talks. His bio on the slide read “YAML Engineer & Minifigure Poser.”

Many platform teams run into the same problem: Pre-built dashboards cannot cover the diversity of what product teams actually want to visualize, but giving every team full dashboard freedom leads to inconsistency, dashboards that cannot be compared across the organization, and a steady stream of “can you fix my dashboard” requests. Their framework is opinionated about how data is presented (layout, panel types, labels, thresholds) but leaves what to present entirely to the consuming team. Teams describe their telemetry requirements, and the framework assembles dashboards from those inputs using the Foundation SDK. The platform team owns the visualization conventions; the product team owns the data.

The clean separation of concerns is what makes it work in practice. Platform teams stop being the bottleneck for dashboard changes, and product teams stop arguing about panel placement and color thresholds, allowing both sides to focus on where they add the most value. The video of the talk has not yet been released at the time of writing.