Laravel Debugbar: Complete guide to installation, activation, and debugging with Inertia

If you develop with Laravel, sooner or later you find yourself reviewing queries, measuring response times, hunting down an N+1, or simply trying to understand what is happening in the background — even auditing every CRUD operation executed by Eloquent. For all of that, Laravel Debugbar is one of those packages that save your day without asking for anything in return: a visual, direct, and bureaucracy-free bar that activates instantly and reveals everything happening in each HTTP request.

In my case, the first time I installed it, it appeared immediately without tweaking anything, allowing me to review right away which queries were executing and how long they took. Since then, I have it in all my development environments without exception.

We left off knowing how to import or export Excel documents in Laravel

What is Laravel Debugbar and what is it really for?

Laravel Debugbar is a visual debugging tool that displays key information about the current HTTP request: executed SQL queries, total execution time, caught exceptions, resolved routes, rendered views, application logs, and much more. Think of it as a transparent window into your application — everything that was previously hidden is now exposed at a glance.

Main advantages over traditional debugging:

• You see queries in real time and know exactly how many are executed per request.
• You can spot an N+1 problem in seconds, without adding manual logs.
• It allows you to validate routes, middleware, views, and data in a centralized way.
• Monitors times and performance visually, without additional instrumentation.
• Does not require complex configuration: install and it works.

When I use it in large projects, what I appreciate the most is that it brings to light everything that happens "behind the scenes", even things I would normally ignore: an extra session query, an event triggered unexpectedly, or a middleware executing twice.

When to use it and when to avoid it

Use it in development always, without hesitation.

Avoid it in production… except for extremely controlled and short-lived cases. In that scenario, I would prefer Laravel Telescope, which is designed precisely for production environments.

How to install Laravel Debugbar step by step

The package is an essential tool when developing in Laravel. From it, we can inspect which database queries are being made, how many there are per request, the server response time, and much more. The official repository is:

https://github.com/barryvdh/laravel-debugbar

$ composer require barryvdh/laravel-debugbar --dev

The --dev flag ensures that the package is only installed in development dependencies and does not reach production. In my experience, as soon as I finished installing it and reloaded the app, the bar appeared "just like that" without touching any configuration file.

Once installed, we will see something similar to this at the bottom of the browser:

How to enable or disable Laravel Debugbar correctly

To enable or disable the bar, the cleanest way is to use the environment variable in your .env file (by default it appears enabled when APP_DEBUG=true):

DEBUGBAR_ENABLED=true   # to enable
DEBUGBAR_ENABLED=false  # to disable

You can also control it directly from PHP code when you need to conditionally enable or disable it during a specific request:

Enable or disable from code

\Debugbar::enable();
\Debugbar::disable();

Generated files and initial behavior after installation

Debugbar introduces a configuration file in config/debugbar.php that you can publish with php artisan vendor:publish if you need to customize it. By default, it activates automatically as soon as it detects that APP_DEBUG is set to true. Personally, I think it should come disabled by default, but I understand the author does this so developers can test the bar immediately without friction.

Debugging in Inertia with Inertia DevTools

Inertia DevTools is a browser extension that offers a dedicated tool panel to debug applications built with Inertia.js efficiently. There are several similar extensions on the market, so it is important to make sure you install the official version or the one recommended by the Inertia community.

https://chromewebstore.google.com/detail/inertiajs-devtools/cbaffpghpcbmgbnlpamegieokkpdlnih

To ensure it works correctly, the primary requirement is to keep the project dependencies fully updated. In projects created months ago —for example, during the initial versions of Inertia 3 or Laravel 13— it is essential to run a composer update followed by an npm run build to update both the backend packages and frontend assets. 

Without this prior update, the extension may experience detection failures or simply fail to activate.

Request monitoring and route inspection

Once active, the tool begins logging all requests made by the application; to view them, open Google Chrome Developer Tools with F12 and look for the Inertia tab. 

Among its main features, it allows filtering activity based on the request type:

• Conventional HTTP: Standard requests for page navigation.
• Consecutive requests (poll): Periodic queries executed in the background, typical of components that update automatically.
• Initial navigation (initial): The full document load when first entering the application, where Inertia injects the initial state into the page.

When selecting a request within the tool, you can examine the full execution trace in Laravel: from route resolution and assigned controllers, to the middlewares involved in the request.

Component inspection and data transfer (Props)

Unlike the browser's native Network panel, Inertia DevTools organizes structured information that is transferred directly to the frontend. When inspecting a list or detail view, the extension allows reviewing the data passed through the props of the Vue, React, or Svelte component:

• Pagination structure and data collections.
• Applied filters and loaded categories.
• Global information injected via middlewares (such as session data, authenticated user, or shopping carts shared via Inertia::share()).
• HTTP response status, quickly identifying 400 or 500 errors.

Extension activation

Using the tool is extremely intuitive. After installing it in the browser, an icon is added to the developer tools panel (similar to Vue DevTools). Upon detecting that the inspected page uses Inertia, the extension enables itself automatically, displaying the complete diagnostic panel for the current session.

In short, the extension is quite useful when you are developing the application so you can see what is happening at every moment.

Best practices to avoid pushing Debugbar to production

• Add DEBUGBAR_ENABLED=false in your production .env file.
• Never include custom Debugbar configurations in the configuration cache (config:cache) if you are deploying to production.
• Adopt the mental rule: "if it is enabled in production, it can break the view or expose sensitive data".
• Always install it with the --dev flag so Composer automatically excludes it from production autoload.

Key sections of Laravel Debugbar

• Queries: detect N+1, query count, and execution times
  • This is where I spend most of my time. Debugbar lists all SQL queries executed during the request, along with their individual time and origin trace. Once working on a large project, I noticed an absurd increase in queries per page. Opening Debugbar revealed an N+1 that had sneaked into a Livewire component — saving me hours of searching.
• Timeline: measure performance on every request
  • Measures execution times for each phase of the request lifecycle. It helps identify bottlenecks, duplicate loads, or events taking longer than expected.
• Views: template loading and injected data
  • If something doesn't match up in your Blade template, here you can see exactly which variables the view is receiving at render time.
• Exceptions: errors caught on the fly
  • If something breaks during the request, Debugbar catches it with a clean stack trace, without needing to open server log files.
• Routes: executed routes and applied middlewares
  • Perfect for validating which route is handling the request and which middlewares were applied. It has helped me more than once when a middleware accidentally blocked an authentication flow.
• Custom messages, logs, and events
  • You can send custom messages to Debugbar directly from your PHP code:

  • \Debugbar::info("Testing debug");
    \Debugbar::warning("Something suspicious here");
    \Debugbar::error("This should not happen");

Practical usage examples (real development scenarios)

• Detecting an N+1 problem
  • Every time I see a higher number of queries than expected, I open Debugbar and the repeated query appears immediately. The solution is usually adding a with() in the Eloquent query to eager load relationships.
• Analyzing performance in large projects
  • When I ran performance tests on a complex project, Debugbar was my primary tool: complete timeline, framework events, individual queries, resolved routes, and rendered views, all in a single panel.
• Validating that a route returns expected data
  • If a route is not responding as it should, the routes and views panel gives you the answer right away: which controller executed, which middleware intervened, and what data reached the view.

Laritor: Monitor a Laravel project - Requests, Queries, Jobs, Logs...

Laritor is a package and service designed to measure and monitor in real time the activity and performance of applications developed in Laravel. The client installed in the project is open-source, while the graphical interface and the control panel (dashboard) are managed through an external service.

Metrics and Control Panel

The service interface centralizes multiple key indicators for continuous system supervision:

• Overall performance: Analysis of HTTP requests, response times, and weekly traffic volume.
• Error management: Detection and logging of system exceptions and pages not found (404 errors).
• System activity: Tracking active user sessions, executed Artisan commands, and background tasks (jobs and processing queues).
• Authenticated users: Metrics regarding total logins and user interaction of registered accounts.

Service Model and Plans

Use of the platform is offered through subscription plans that define the monthly volume of processed events (for example, 300,000 events) and data retention duration (such as 14 days). This enables monitoring production applications without having to deploy or maintain your own monitoring infrastructure.

Frequently Asked Questions about Laravel Debugbar (FAQ)

• Why is Laravel Debugbar not showing up?
  • Usually because you have DEBUGBAR_ENABLED=false in your .env, because APP_DEBUG=false, or because you are in a production environment where it disables itself automatically.
• Does it consume a lot of resources?
  • In development, it can add a small overhead per request, but nothing alarming. For true performance benchmarks, temporarily disable it with DEBUGBAR_ENABLED=false.
• Can I use it in production?
  • It is not recommended. It can expose sensitive application information (queries, internal routes, environment variables). For production monitoring, the appropriate tool is Laravel Telescope.
• Debugbar or Telescope?
  • Debugbar for fast development and immediate visual feedback; Telescope for deep analysis, request history, and monitoring in staging or controlled production.
• Which tab is the most useful?
  • Queries, without a doubt. It is where most performance issues are detected. The Timeline tab is also pure gold when the issue is not in the queries but in the request lifecycle.

Conclusion

Laravel Debugbar is an indispensable tool in any Laravel development environment. It allows you to understand what your application actually does on every request, catch errors you didn't even know existed, and optimize response times without requiring additional instrumentation. For me, it is one of those utilities I install out of pure habit every time I start a new project.

Next step: learn how to deploy your Laravel application to an Apache server.