Services & tools

Debugger

Requests, dumps, queries, logs and exceptions per site, plus Xdebug step debugging.

The Debugger shows what each request, queued job and failing command in a Laravel site did: its dump() calls, database queries, log messages and exceptions, with the code around them. It's free, needs no package, and touches no file in your project.

Turning it on

  1. Open the Debugger page

    Pick a Laravel site from the list at the top.

  2. Click Turn it on

    From now on that site's requests are recorded. Other sites aren't affected.

  3. Use your app

    Reload a page, submit a form, run an artisan command. Each one appears under Requests as it happens.

Behind the scenes LaraMonster loads a small PHP agent in front of the site (with auto_prepend_file) that listens to Laravel's own events. It doesn't change what your app does, and turning the Debugger off removes it.

Requests

Click a request to see, in one place:

  • Dumps

    With the file and line each came from.

  • Queries

    With their bindings filled in and their time, and a hint when the same query runs again and again (often an N+1).

  • Log messages

    Everything written to the log during the request.

  • The exception

    If any, with the code around each line of the stack trace. Frames in your own code are marked; vendor frames fold away.

Each request also shows its method, URL, status, duration and the signed-in user (or guest). Queued jobs and commands that fail are recorded the same way.

Dumps

Call dump() or dd() anywhere in your code:

public function store(StoreOrderRequest $request)
{
    $order = Order::create($request->validated());

    dump($order->total, $request->user()->email);   // shows up in the Debugger

    return redirect()->route('orders.show', $order);
}

The Dumps tab collects every dump from every request, newest first, with a copy button and a link to the line. Turn off Dumps in the page too to keep dumps out of the HTML, which keeps JSON responses and redirects working while you debug them.

Exceptions

The Exceptions tab lists every exception the site threw, grouped with how often each happened. The sidebar shows a red count when new ones arrive. Click a file name in a stack trace to open that line in your editor; set your editor's command in SettingsGeneral: code (the default), cursor, phpstorm, zed, subl, nvim… LaraMonster opens the exact line in each.

laravel.log

The laravel.log tab shows the site's log file with the newest entries first, filtered by level (errors and worse, warnings and worse, …), with Clear to empty it.

Step debugging with Xdebug

For breakpoints, Xdebug runs only for the site you choose, so your other sites stay fast:

  1. Add Xdebug once

    If the site's PHP doesn't have it yet, click Add Xdebug (see extensions).

  2. Turn on Step debugging with Xdebug

    On the Debugger page, for this site.

  3. Listen in your editor

    VS Code: install the PHP Debug extension and run Listen for Xdebug. PhpStorm: click the phone icon, Start listening for PHP Debug Connections. Both use port 9003.

  4. Set a breakpoint and reload the page

    Execution pauses at your breakpoint.

A minimal VS Code launch.json, if your editor asks for one:

{
    "version": "0.2.0",
    "configurations": [
        { "name": "Listen for Xdebug", "type": "php", "request": "launch", "port": 9003 }
    ]
}
Want the whole story of a request? Activity (Pro) also records every event fired, the listeners that ran and what they returned, as a timeline you can export as PDF.