Visual Trace Tree

How the Trace Tree Works

When Glassbrain ingests a trace, it parses the stack trace and metadata to reconstruct the execution path. Each function call, API request, or logical step becomes a node in the tree. Parent-child relationships are inferred from the call stack, so you can see which function called which.

The tree is rendered in the trace detail view of your dashboard. You can access it by clicking on any trace in your project's trace list. The tree is fully interactive - you can click nodes to see their details, expand or collapse branches, and hover over nodes to see timing information.

For traces that include OpenTelemetry span data, the tree uses span parent-child relationships directly, giving you an even more accurate representation of your application's execution flow.

Reading the Tree

The trace tree reads from top to bottom and left to right. The topmost node is the entry point of the trace, and each level of indentation represents a deeper level in the call hierarchy.

Root Node

The root node sits at the top of the tree and represents the outermost context of the trace. For a client-side error, this is typically the component or page where the error surfaced. For a server-side trace, this is usually the API route handler or middleware that received the request.

The root node displays the trace message, type badge, and the total duration of the trace from start to finish.

Child Spans

Below the root node, child spans represent individual operations that occurred during the trace. Each child span is indented to show its relationship to its parent. A child span includes:

• The operation name (function name, API endpoint, or custom label)
• Duration in milliseconds
• Status indicator (success, error, or warning)
• Input and output data when available

Here is an example of how a trace tree structure might look in data form:

{
  "root": {
    "name": "GET /api/users",
    "duration_ms": 342,
    "status": "error",
    "children": [
      {
        "name": "authenticate",
        "duration_ms": 12,
        "status": "success",
        "children": []
      },
      {
        "name": "database.query",
        "duration_ms": 245,
        "status": "success",
        "children": [
          {
            "name": "connection.acquire",
            "duration_ms": 8,
            "status": "success",
            "children": []
          },
          {
            "name": "SELECT * FROM users",
            "duration_ms": 234,
            "status": "success",
            "children": []
          }
        ]
      },
      {
        "name": "serialize_response",
        "duration_ms": 3,
        "status": "error",
        "children": []
      }
    ]
  }
}

Timing Information

Each node in the tree displays its duration. A horizontal bar next to each node visually represents its duration relative to the total trace duration. This makes it easy to spot which operations consumed the most time.

Hovering over a node reveals a tooltip with exact timing data: start time, end time, and duration in milliseconds. For nodes that overlap in time (concurrent operations), the bars are stacked to show parallelism.

Node Types

The trace tree uses different visual treatments for different types of operations. Each node type has a distinct icon and label style:

Expanding and Collapsing Nodes

Nodes that have children display a toggle arrow to the left of the node name. Click the arrow or the node itself to expand or collapse its children.

By default, the tree opens with the first two levels expanded. Deeply nested branches are collapsed to keep the initial view manageable. You can use the keyboard shortcuts to control the tree:

When a tree has more than 100 nodes, Glassbrain automatically collapses all branches beyond the second level to maintain rendering performance.

Color Coding by Status

Every node in the trace tree is color-coded based on its status. This makes it easy to scan large trees and immediately spot where problems occurred.

When a parent node contains a child with an error, the parent node also displays a small red indicator to show that an error exists somewhere in its subtree. This propagation makes it easy to trace errors up through the call hierarchy without expanding every branch.