Start with the right request

Choose the request

Open the bar at the bottom of your app. The request picker shows recent profiles with their method, path, status, type, and recorded time. Match those details to the action you just took.

Read the overview first

The compact bar and request overview answer the first questions without making you open every section:

• What happened: method, path, request type, status, and duration.
• What needs attention: errors and findings appear before quiet diagnostics.
• Where time went: total query time, query count, and peak memory give you an initial direction.

A high total duration with little database time points away from SQL. A large query count or repeated-query finding points toward the Queries inspector.

Treat findings as leads

Findings turn captured evidence into likely debugging leads: a slow request, repeated query shape, failed HTTP call, high cache miss rate, or another unusual pattern.

Follow the evidence in a small loop

1. 1

   State the symptom

   Name the visible problem: a failed page, repeated database work, a slow update, or an unexpected side effect.
2. 2

   Open one relevant section

   Use the finding or overview to choose Queries, Timeline, Exceptions, HTTP client, Livewire, or another focused inspector.
3. 3

   Trace it to application code

   Use the source location, call stack, related query, model, or event instead of guessing from a count alone.
4. 4

   Repeat the request

   Refresh or repeat the same action after a change. Compare like with like and keep the selected request type the same.

Watch for background requests

The newest profile is not always the page you care about. A Livewire update, polling request, asset-related fetch, or application request made after the main response may be newer.

Reselect the profile by method and path after the list refreshes. When an agent or test needs certainty, pass the exact response-header ID instead of saying “the latest request.”