A lot of Laravel developers use Livewire to build their interactive frontends. Write some PHP, sprinkle in a few wire:click attributes, and things just work. It's great.
But when something goes wrong? That's where it gets painful. Stack trace frames point to hashed filenames in Livewire's compile cache. Components can be nested in other components, creating a complex hierarchy. You have no visibility into which component is running when, or how long it's taking. Your components are basically invisible to most debugging tools.
We built deep Livewire support into Flare. Let's take a look at what that gives you.
Livewire components in your traces
When you open a trace for a page that uses Livewire, you don't just see the HTTP request. You see every component that was involved, nested in the timeline exactly where it ran.
Let's say you have a page with a task board. The trace shows the full hierarchy: TaskBoard mounts, triggers three TaskColumn components, and each of those renders its own TaskCard children. Database queries show up nested under the component that ran them.

Whether you use a regular Livewire component with a separate view, a class-only component with an inline render method, or a single-file component, Flare understands it. You get the same visibility and insights regardless of how you structure your components.
Phase-by-phase breakdown
Every Livewire component goes through a lifecycle: mounting, hydrating, calling methods, rendering, and dehydrating. Flare breaks this down for you.
Each phase gets its own span with timing. So you can immediately see whether a component is spending time in the mount phase, the render phase, or somewhere else entirely.

Method calls
Back on our task board, when a user clicks a card to mark it done, the TaskCard component's toggleStatus method runs. Flare records that call as its own span, with the method name and the parameters (if any). As with any other span, you can see nested spans for database queries or other operations that happen during that method call.

Aggregated components
Flare also aggregates components across traces, treating them as their own top-level entity.

You get an overview of all your Livewire components with their average phase times and the number of traces they appear in. If one component is consistently slow, it'll stand out immediately.

Flare links each component to its surroundings, in both directions. You can see what uses the component:
- Which routes render it
- Which views include it
- Which other Livewire components include it
And what the component uses:
- Which queries it runs
- Which views it renders
- Which components it renders
- And more
These links are always relative to the component and show the time spent in each, along with how often nested or parent links were called. So you can quickly see if a component is slow because of the queries it runs, the views it renders, or the other components it includes.

Error tracking
When an error occurs during a Livewire request, Flare shows you the original URL the user was on, which component was involved, its data and state, and which method was being called. All the context you need, right there.

Stack traces for single-file components
Livewire v4 introduced single-file components where both the PHP class and template live in one Blade file. Neat! But internally, Livewire compiles these into hashed PHP files. So when an error happens, the stack trace points to something like a4f8e2c1.php. Not that helpful.
Flare maps these back to the original source file. Your stack trace points to the actual .blade.php, at the correct line number. No configuration needed.
Want to know more about how this works? Check out our deep dive into the internals of Livewire's single-file components and how we integrate with them: How Flare handles Livewire v4's single-file components.
The small things
A few more details that we think matter:
- Livewire's JavaScript assets are excluded from traces. Requests for
livewire.jswon't pollute your performance data. - Noisy components can be ignored. If you have a component that runs a lot and isn't relevant to your performance monitoring, you can exclude it from being collected.
- Minimal component spans can be enabled. Instead of showing the mount, render, and dehydrate phases separately, you'll see just one span for the whole component. This is useful if you want to keep your traces simpler and don't care about the phase breakdown.
- Both Livewire v3 and v4 are supported. Different internal APIs, same experience.
Getting started
All of this works out of the box. Install spatie/laravel-flare, and if Livewire is in your project, the integrations activate automatically.
We use Livewire every day. We made sure Flare understands it just as well as we do.
Happy debugging!
Continue reading
Integration testing our Laravel package with a real server and queue
When unit tests aren't enough. We started testing the Laravel Flare package against a real application in order to verify that our code works using orchestra workbench. Here's how we did it.
Ruben
A minimal "Last used" login option indicator with Alpine.js
Flare's login page now remembers which sign-in option you used last time. Built on Alpine's $persist plugin and just about 25 lines of code.
Alex
Subscribe to Backtrace, our quarterly Flare newsletter
No spam, just news & product updates