---
title: "The hierarchy of observability needs | Grafana Labs"
description: "Understanding the 4 levels of observability maturity"
---

> For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt).

## Why this matters

Observability **works best as a progression**. Each level builds on the previous, though teams sometimes need to work on multiple levels at once.

[Hierarchy of Observability Needs - 4-layer pyramid showing Infrastructure Visibility, Baseline Service Visibility, Deep Transaction Insights, and Custom Logic](/media/docs/learning-hub/instrumentation-hub-hierarchy-of-needs.png "Hierarchy of Observability Needs - 4-layer pyramid showing Infrastructure Visibility, Baseline Service Visibility, Deep Transaction Insights, and Custom Logic")

## Each level builds on the previous

> **Each level provides context for the next.**

| Dependency               | Why                                                                                    |
|--------------------------|----------------------------------------------------------------------------------------|
| Level 2 requires Level 1 | You can’t debug **applications** without seeing the **infrastructure** they run on     |
| Level 3 requires Level 2 | You can’t trace **requests** without knowing **which service** is causing problems     |
| Level 4 requires Level 3 | You can’t add **custom instrumentation** without understanding **where** to instrument |

## The key question at each level

| Level       | Focus             | Key question                         |
|-------------|-------------------|--------------------------------------|
| **Level 1** | Infrastructure    | “Is my infrastructure healthy?”      |
| **Level 2** | Services          | “Which service is the problem?”      |
| **Level 3** | Transactions      | “Why is this specific request slow?” |
| **Level 4** | Application logic | “What’s happening in my code?”       |