Observe with turnkey solutions on Grafana Labs

Connective intelligence layer

Wed, 17 Jun 2026 12:54:46 -0500

Connective intelligence with Knowledge Graph

Knowledge Graph is the connective intelligence foundation built into Grafana Cloud:

The engine that powers the opinionated observability experience across turnkey solutions (Kubernetes Monitoring, Application Observability, Database Observability, and Frontend Observability)
Automatically discovers your services, infrastructure, and databases, maps how they depend on each other
Continuously analyzes your environment for issues

Try it out in Grafana Play

Core capabilities

Entity Catalog, where you can view all entities (services, hosts, pods, databases) and their relationships
RCA (root cause analysis) Workbench, where you view correlated metrics, logs, traces, and insights on a timeline for guided investigation
Insights, which surfaces five categories of issues:
- Saturation: Resources approaching limits (CPU, memory, disk, connections)
- Amend: Deployments, config changes, scale events
- Anomaly: Unusual patterns in traffic or behavior (request rate spikes or drops, latency changes)
- Failure: System deviating from desired state (pod crashes, missing Redis master, controller errors)
- Error: Problematic requests (5xx errors, latency threshold breaches, error log rate breaches)

Knowledge Graph advantages

Wed, 17 Jun 2026 12:08:02 -0500

What keeps you up at night?

Role / Worries	What you get with Knowledge Graph
SRE, On-call Engineer Getting paged in early morning with no idea what’s related Spending the first 30 minutes of every incident just mapping what’s affected Never being sure you’ve found the real root cause versus a downstream symptom	A unified timeline of correlated metrics, logs, traces, and insights across all affected components, no manual correlation required Causality traversal that surfaces the origin of the issue, not just related symptoms Grafana Assistant to suggest root cause hypotheses and next steps
Platform, Infrastructure Engineer No single view of how services, infrastructure, and databases connect to each other Constantly maintaining topology documentation that goes stale the moment something deploys	An entity map that rebuilds automatically from your live telemetry, always current, never stale Automatic discovery of services, hosts, pods, and databases and how they relate Insights that surface saturation, failures, and errors without you writing a single alert rule
Senior Engineer Being the only person who knows the service topology Getting escalated to on every major incident because no one else knows where to start	Topology encoded automatically so any engineer can navigate the system without tribal knowledge Entity catalog with health status and insights visible to the whole team Guided investigation that shifts troubleshooting from “who do we page?” to “here’s what changed and why”
Engineering Manager, VP Engineering Watching MTTR stay flat quarter after quarter Best engineers stuck in war rooms instead of building Not knowing which tools in your observability stack are actually being used	A single intelligence layer across Application Observability, Kubernetes Monitoring, DB Observability, and Frontend Observability, no additional tooling to manage Incident response that scales with headcount, not just expertise Activates on top of data you’re already sending, with minimal incremental cost

Monitor and manage your Kubernetes fleet

Wed, 17 Jun 2026 12:54:46 -0500

Kubernetes Monitoring

When you open the Kubernetes Monitoring app in Grafana Cloud, there’s a ready-made monitoring experience rather than a blank canvas you have to build yourself.

Try it out in Grafana Play

What keeps you up at night?

Role / Worries	What you get with the app
Platform Engineer, K8s Admin Keeping clusters healthy Figuring out why something broke Making sure the system can grow without constant babysitting	A dashboard view of your entire fleet at once A way to investigate pods and components even after they’ve been deleted Early warnings before things fail
SRE, DevOps Engineer Getting paged in early morning hours Taking too long to find the root cause of an outage Fighting alert noise that drowns out real problems	No manual correlation of data on your part Direct alert creation based on what you’re looking at
Developer Wondering if slowness is in your code or in the infrastructure underneath Solving issues without becoming a K8s expert	Visibility into applications running in your infrastructure A navigation structure that means there’s no need to become a K8s expert
Engineering Manager, VP Engineering Watching Kubernetes costs balloon as the team scales Seeing engineers spend time firefighting instead of building	An app built and fully managed by Grafana Labs inside Grafana Cloud Cost tracking that shows where money is being wasted Right-sizing recommendations for over-provisioned workloads

Kubernetes Monitoring: Is it right for you

Wed, 17 Jun 2026 12:08:02 -0500

Is it right for you?

Kubernetes Monitoring meets your needs when you:

Run production workloads on Kubernetes, on any distribution and any cloud
Don’t have one place to see what’s actually going on across all Clusters and workloads
Get frustrated by the cost or the alert noise of another vendor’s product
Have a team spending too much time keeping the monitoring stack running with open source Grafana
Want platform-wide tools that speed up troubleshooting and resolution even more

Real results from real teams

FalconX

“Our goal was to find a solution that seamlessly integrates with Kubernetes, where most of our applications run. Beyond Kubernetes, we needed a platform that could support additional tools and add-ons across our clusters while offering various plugin support and a single pane of glass for everything.”
Dubber

“We use this Kubernetes Monitoring for capacity planning… we use this to also cost optimize some of our cloud spend based on the performance of our Kubernetes clusters.”

Monitor AWS, Azure, and GCP in one place

Wed, 17 Jun 2026 12:54:46 -0500

Cloud Provider Observability

Cloud Provider Observability is a turnkey app for monitoring AWS, Azure, and Google Cloud. It’s built for organizations that have outgrown native CSP tooling.

Instead of:

Separate native consoles, you get one app for all three clouds
Different proprietary query languages, you have open standards (PromQL and LogQL)
Separate alerting systems, there is one unified alerting engine

Provider	What you monitor
AWS	EC2, RDS, Lambda, S3, ELB, ECS, and more
Azure	VMs, Azure SQL, Functions, Storage, App Services
GCP	Compute Engine, Cloud SQL, Cloud Functions, Google Kubernetes Engine

Try it out in Grafana Play

What keeps you up at night?

Role / Worries	What you get with the app
Cloud Admin Constantly switching between different cloud consoles to check what’s happening Each console has its own way of doing things	One place to manage and monitor all three clouds No more context switching between consoles
SRE, DevOps Engineer When something breaks, is the problem in AWS, Azure, or GCP?	Pre-built dashboards and alerts for each provider, all in one place Logs from all three clouds accessible in the same tool
Developer Is my app slow because of my code, or is something wrong with the cloud services underneath it? How do I figure this out without becoming an expert in each cloud’s tooling?	Pre-built views of cloud services that don’t require deep knowledge of each provider’s tooling
Engineering Manager, VP Engineering Cloud bills growing faster than the team can explain Paying a premium on top of that for observability tools	Priced on metrics ingested, so no per-host premium. With growth, you pay for the telemetry you generate, not a flat charge per resource on top of it.

Cloud Provider Observability: Is it right for you

Wed, 17 Jun 2026 12:08:02 -0500

Is it right for you?

Cloud Provider Observability meets your needs when:

You run services on AWS, Azure, or Google Cloud (or a mix of all three) and need one place to monitor them.
You’re switching between CloudWatch, Azure Monitor, and GCP Operations Suite to answer basic questions about what’s running and what’s broken.
You’ve outgrown your cloud provider’s built-in monitoring tools. You need fast troubleshooting, not assembling dashboards and alerts by hand.
You’re paying a per-host premium with your current observability vendor and your bill grows every time your cloud footprint does.
Your team is spending engineering time maintaining scrape configs, dashboard mixins, and alert rules across providers. That’s time that should go to the product.

Real results from real teams

ASOS

ASOS started with Grafana OSS specifically because it had an Azure Monitor plugin, handy for visualizing their Azure telemetry. But as they scaled, querying Azure Monitor and New Relic directly through Grafana started hitting rate limits and causing dashboard timeouts. The fix? Send Prometheus metrics into Grafana Cloud Metrics instead of querying Azure on the fly. That’s what pushed them from OSS to Cloud.
TeleTracking

TeleTracking built their own OSS stack to wrangle a sprawling AWS + Azure environment: EKS, AKS, EC2, Lambda, Azure VMs, the works. It got unsustainable fast. The multi-cloud complexity was a direct reason they moved to a managed solution.

Track the health of your services

Wed, 17 Jun 2026 12:54:46 -0500

Service-level visibility

Application Observability is built natively on OpenTelemetry and lives inside the same Grafana Cloud platform as your other telemetry. It:

Tells you when your services are slow or broken
Helps you trace what went wrong across microservices
Gets you to the root cause without switching tools

Try it out in Grafana Play

What keeps you up at night?

Role / Worries	What you get with the app
SRE, On-Call Engineer When something breaks in the early morning hours, the first 30 minutes are spent just finding the right data across multiple tools By the time you have context, the damage is done	Click from a service in the map straight to traces, then logs, then profiles. No tool switching. Automatic correlation means no manual timestamp matching across systems.
Developer My endpoint is slow, but I can’t tell if it’s my code, a downstream service, or a database call underneath Tracing it end-to-end requires expertise I don’t have	Auto-generated service maps show exactly where latency is introduced across your dependencies Guided root cause analysis takes you from alert to likely source without needing to be an observability expert
Platform, Observability Engineer Proprietary agents installed across every service If we ever want to switch vendors, we have to re-instrument everything from scratch	Built natively on OpenTelemetry. No proprietary agents to install or manage. Your instrumentation is portable; it works with any OTel-compatible backend if you ever need to move
Engineering Manager, VP Engineering APM bill grows with every host we add Paying for multiple overlapping tools: APM here, logging there, tracing somewhere else	Usage-based pricing: you pay for telemetry, not per host or container, so cost tracks usage, not fleet size Metrics, logs, traces, and profiles in one platform. Fewer contracts, less duplication.

Application Observability: Is it right for you

Wed, 17 Jun 2026 12:08:02 -0500

Is it right for you?

Application Observability meets your needs when you:

Run distributed services or microservices, and incidents turn into war rooms because nobody can quickly tell which service is the problem
Are jumping between your APM tool, your logging tool, and your tracing tool during every investigation, and the time you lose switching context is time the incident is still running
Are paying a flat cost per host or per container for APM, and your bill grows every time you scale up or deploy something new
Are adopting OpenTelemetry and want an APM product built natively on it, not one that translates your OTel data through a proprietary layer
Want your developers to investigate their own services without needing to page a senior SRE who knows the system

Real results from real teams

C Spire

“Grafana Cloud’s Application Observability finally 100% sold us on moving to cloud — it gave us request, error, and duration metrics automatically, something we never had before.”
MIC

“Application observability is our main focus right now. We already have strong infrastructure visibility, but connecting that to business impact still requires manual effort. Application observability will help us understand what our code is actually doing in production.”

See what your users actually experience

Wed, 17 Jun 2026 12:54:46 -0500

What real users experience

Frontend Observability captures performance data from actual browser sessions. You instrument your frontend once, using an open source SDK that emits standard OTel signals.

See what your users actually experience: real browser sessions, Core Web Vitals, and performance data from actual user traffic, not synthetic proxies.
Find and fix frontend errors fast: triage errors with automatic grouping, detailed stack traces, and actionable guidance.
Trace problems from browser to backend: connect a user’s frontend session to the exact backend service call that caused the issue, with full distributed tracing context.
Analyze frontend data in the workflow you already use: query and visualize frontend performance alongside your application insights, logs, and traces in Grafana dashboards.

Try it out in Grafana Play

What keeps you up at night

Role / Worries	What you get with the app
Developer Users report checkout is slow or a page hangs, but backend metrics look fine and it doesn’t happen in staging Can’t reproduce it, can’t explain it	Real user sessions broken down by page, browser, device, and geography, so you can isolate where it’s happening and who is affected Tie performance data to deployment markers to catch regressions before users find them
SRE, On-Call Engineer During an incident, the frontend team blames the backend and the backend team’s dashboards look clean Hours spent debating ownership instead of fixing the problem	Distributed tracing connects the browser session to the exact backend span. Both teams see the same evidence. No more finger-pointing across separate dashboards and different data
Frontend, Web Engineer Error reports arrive as support tickets and screenshots No fast path from “a user saw this” to “here’s what broke and why”	Errors are automatically grouped and prioritized by user impact Detailed stack traces give you a direct path from symptom to root cause
Engineering Manager, VP Engineering Paying for a standalone RUM tool, a separate APM, and a separate logging platform Engineers still have to manually stitch them together during incidents	Browser telemetry in the same Grafana Cloud instance you already use. One fewer vendor, one fewer login. Frontend performance alongside your logs, traces, and application data. No manual correlation.

Frontend Observability: Is it right for you

Wed, 17 Jun 2026 12:08:02 -0500

Is it right for you?

Frontend Observability meets your needs when you:

Are already using Grafana Cloud for backend observability and the frontend is a blind spot
Have backend dashboards that look healthy but users are still reporting slow pages or broken flows, with no way to see what they’re actually experiencing
Have frontend issues that only surface in production. They don’t reproduce in staging, and they vary by browser, device, geography, or network condition.
Are paying for a separate RUM tool and want to consolidate to one platform, one login
Want frontend instrumentation built on open standards, not a proprietary agent that only works with one vendor’s backend

Real results from real teams

River Island

“Just before Easter, we noticed a small increase — around 3% to 5% — in page load times in the basket. At the same time, we saw order value starting to drop. We investigated and found a backend process causing additional load on the front end. It was a bug. We were able to fix it and deploy a change within 30 minutes.”

Find the slow queries behind problems

Wed, 17 Jun 2026 12:54:46 -0500

Query-level visibility with Data Observability

Your application hits the MySQL or PostgreSQL database thousands of times a day. Database Observability watches all of those hits. Then it gives your engineers the context to understand why, without needing a DBA to interpret it.

See every query across all your databases: execution times, wait events, and error rates, aggregated or broken down by instance, schema, or table.
Find the root cause faster: correlate database queries directly with application traces and infrastructure metrics without bouncing between tools.
Drill into deep diagnostics: execution plans, table schemas, and index usage via visual explain plans, without needing DBA expertise.
Get actionable optimization: AI Helper provides specific recommendations (composite indexes, query rewrites) with the exact SQL to implement them.

Try it out in Grafana Play

What keeps you up at night?

Role / Worries	What you get with the app
Developer I follow the trace and it points to the database, then the trail stops I know something in the database is the problem, but I can’t tell which query, why it’s slow, or what changed	Query-level visibility shows exactly which queries are slow, how often they run, and what they’re waiting on Visual explain plans take you from “slow query” to “here’s what to fix” without needing DBA expertise
SRE, On-Call Engineer During an incident in the early morning hours, infrastructure metrics look fine, traces point to the database, and the DBA is asleep No way to investigate the database layer myself	Query samples, wait events, and execution plans are available to any engineer, not just DBAs Correlate database queries directly with application traces so you get the full picture in one place
DBA, Platform Engineer Every slow endpoint becomes a ticket for me Developers can’t self-serve through database problems, so I spend my time answering “which query is slow” instead of doing actual database work	Developers and SREs can investigate database performance independently AI Helper surfaces specific optimization recommendations (composite indexes, query rewrites) with the exact SQL to implement them
Engineering Manager, VP Engineering Paying per host for database monitoring and the bill compounds every time we add an instance Still getting escalations because nobody can answer why a specific query is slow	Usage-based pricing: you only pay for active host hours and associated telemetry, not per host or container, so cost tracks usage, not fleet size Database performance in the same Grafana Cloud instance you already use, without a separate tool or contract

Database Observability: Is it right for you

Wed, 17 Jun 2026 12:08:02 -0500

Is it right for you?

Database Observability meets your needs when you:

Have application traces that stop at the database boundary. You can see a query is slow, but not what inside the database is causing it.
Run MySQL or PostgreSQL on RDS or Aurora
Have developers and SREs spending incident time waiting for a DBA to investigate database problems, and that bottleneck is slowing resolution
Are already using Grafana Cloud for application or infrastructure observability, and the database layer is a blind spot
Are paying a per-host premium for database monitoring, and the bill grows every time you add an instance