Flame Graph

What Is a Flame Graph?

A flame graph turns raw profiling or tracing data into stacked, color-coded bars. One glance tells you which function or service call actually ate the time.

Each bar is one function call or one service span, and its width shows how long that call took relative to everything else on the graph. Stack one bar on top of another and you're showing which call triggered which.

Brendan Gregg built the technique for CPU profiling, originally pairing it with Linux's perf tool to fold thousands of stack samples into one picture instead of a scrollable list nobody wants to read.

APM platforms borrowed the same visual grammar for distributed tracing, so today a request's entire execution path gets rendered bar for bar, service for service.

The idea is the same, just aimed at two different jobs. A flame graph turns a wall of raw trace data into something you can scan in five seconds flat.

Why Do Flame Graphs Matter?

Before a flame graph, "the app feels slower lately" is about as specific as it gets. After one, it's this exact function or that one service call.

Without it, someone is stuck reading logs line by line, or worse, just guessing. A wide bar just points at the answer instead.

This matters most in microservice setups. One dragging service can quietly slow down everything downstream of it, and by the time users notice, the actual cause is three hops away from where the complaint started.

A flame graph is often the fastest way to see that whole chain before it turns into an outage nobody saw coming.

How Do You Read a Flame Graph?

Once you know the two axes, a flame graph reads fast.

1. Width shows duration: A bar's width is a share of the total time recorded, not a fixed unit, so a bar twice as wide burned roughly twice the time relative to everything else on the graph.

2. Height shows the call stack: Stack one bar on another, and you have shown that the bottom function has called the top one.

3. An exposed top edge marks where time actually went: If nothing sits on top of a bar, that function was doing the work itself, not waiting on a child call, and that is usually where the real cost hides.

4. Color separates functions or services: Most tools assign one color per function or service, so the same one lights up the same color wherever it shows up on the graph. That is especially handy when you are hunting for one repeat offender across a big trace.

What Are Typical Use Cases for a Flame Graph?

When people say flame graph, they usually mean one of two things.

1. CPU and code profiling: This is the original use case. A profiler samples the stack over and over, and folding those samples together shows exactly which function hogged the CPU across the whole run, the fastest route to whatever needs optimizing first.

2.Distributed request tracing: Application performance monitoring tools render a single request's path this way too, using distributed tracing data pulled straight from the request itself. A slow service call turns into an unusually wide bar, not a line buried in a trace list you have to dig through.

3. Root cause investigation: When a request times out, or some function runs strangely slow, a flame graph is usually the fastest way to point root cause analysis at the exact call responsible, instead of guessing from logs alone. Sometimes that is the whole investigation, start to finish.

How Do You Generate a Flame Graph?

No matter which tool you reach for, generating a flame graph follows roughly the same pipeline.

1. Collect stack samples or trace spans: A profiler samples the call stack at a set interval. A tracing agent, instead, records each span in a request as it fires.

2. Fold or aggregate the data: Repeated call stacks get merged, and in a tracing setup, connected spans get grouped under their shared parent instead. Either way, what started as a flat log is now shaped like something you can actually draw.

3. Render the visualization: The folded data becomes the picture itself, an SVG file if you are using a standalone profiling toolchain, or a chart built right into your APM platform's trace view.

Either pipeline lands in the same place. What used to mean scrolling through a raw stack trace or a request log, one line at a time, now takes one glance.