laravel-logger records application activity and puts it behind a dashboard

Activity recorded inside the app, not shipped somewhere else

laravel-logger is described as activity logging and an investigation dashboard for Laravel applications, tested on Laravel 8 through 13, and it can be added as middleware or called through a trait. That framing matters, because it is not a log shipper and not a replacement for a centralised logging stack. What it records is application activity, meaning the things a person did in your application, and it stores it in your application's own database and shows it back to you inside the same application. The audience is a team that has been asked what someone did, and who wants the answer to be queryable from the product rather than assembled from log files on a server. The project description calls it an investigation dashboard, and the topics list is explicit about the shape of the feature set, with activity log, activity drilldown, activity dashboard, request logger, request logging, middleware and logging dashboard all named. The practical distinction is that this is a business record of actions, and it will be read by administrators and auditors rather than by developers debugging at midnight.

Two ways to record, middleware or a trait

There are two integration styles, and the choice depends on whether the event is tied to a request or to a piece of application logic. The first attaches the activity middleware to the routes you want recorded:

Route::get('/dashboard', [DashboardController::class, 'index'])->middleware(['auth', 'activity']);

The second uses a trait in a controller or service, which records specific actions with a description and a payload:

use jeremykenedy\LaravelLogger\App\Http\Traits\ActivityLogger;

class AccountController extends Controller
{
    use ActivityLogger;

    public function update()
    {
        $this->activity('Updated account', 'Changed billing address', [
            'id' => 42,
            'model' => Account::class,
        ]);
    }
}

The trait call takes a short action name, a longer description and an array of extra data, in this case an id and the model class involved. That payload is what turns a log line into an investigation record, since the dashboard can then be filtered by model or by identifier. The middleware form is the coarser one and suits capturing all traffic to a set of routes, while the trait form is the precise one and is what you would use for the actions an auditor would ask about. The documentation points out that the dashboard lives at /activity while signed in, and that the existing rolesEnabled and rolesMiddlware settings can restrict the dashboard and the exports to an administrative role.

A Blade dashboard your own application hosts

The dashboard design decision is the one that most affects adoption, and it is stated plainly. The dashboard is rendered by Blade, and Livewire, Vue, React and Svelte applications can link to it without installing another frontend runtime, because the package does not ship separate client-side dashboards. The framework support table makes the trade explicit. Bootstrap 4 with Blade, using existing views including published overrides, is the default. Bootstrap 3 with Blade uses existing panel based views, Bootstrap 5 and Tailwind CSS with Blade use a modern dashboard with dark mode, and neither of those is the default. The composer update command does not switch frameworks or replace your views or configuration, so an upgrade will not surprise you. The cost of the design is that the dashboard needs a parent Blade layout, layouts.app by default, and that layout must render three specific sections. The documentation is explicit that the parent layout must render content, template_linked_css and footer_scripts, or the section names from your configuration, and for layouts using stacks you set bladePlacement to stack and use the stack directive instead. The dashboard honours your layout and does not load a second application shell.

Installing, and what the installer will and will not overwrite

Installation is three commands:

composer require jeremykenedy/laravel-logger
php artisan logger:install
php artisan migrate

The installer detects an existing config/laravel-logger.php and asks before continuing, and in unattended deployments you use logger:update, or logger:install --force to skip that confirmation. Configuration and published view overrides are preserved even with --force, and database migrations remain a separate step, which is deliberate since a migration is the part you want to review before it runs. If you want the modern dashboard the installer takes options, with --css, --views and --theme:

php artisan logger:install --css=bootstrap5 --views=modern --theme=system

The installer publishes configuration if it is missing and publishes dashboard assets to public/vendor/laravel-logger, while views stay in the package unless --publish-views is supplied. The existing vendor:publish --tag=LaravelLogger and LaravelLogger-legacy language publishing continue to work. The requirements are modest. You need a Laravel application with authentication and a database connection, Bootstrap or Tailwind assets in the host application, and PHP's zip and XMLWriter extensions for Excel exports. The modern Bootstrap 5 views can load Bootstrap CSS from a CDN when enableBootstrapCssCDN is enabled.

Compatibility ranges that need reading carefully

The framework support section is unusually precise, and two of its statements deserve attention. The test matrix covers Laravel 8 through 13, including Laravel 8 on PHP 7.3, while the Composer runtime PHP constraint is unchanged. The existing anonymous migration requires Laravel's anonymous migration loader, available in Laravel 8.37 and later, and the documentation adds that earlier framework installations are historical compatibility targets rather than newly verified by the matrix. That distinction matters when you are choosing which version to install. The second is cursor pagination, which requires a Laravel version that provides cursorPaginate. Then there are the older compatibility paths. Laravel 5.4 and earlier require manual Logger provider registration, and existing Lumen installations should keep their activity middleware registration, copy the configuration and set LARAVEL_LOGGER_DISABLE_ROUTES=true, since they do not use the dashboard or the new setup commands. Crawler detection is now bundled in Laravel Logger, and Composer no longer installs jaybizzle/laravel-crawler-detect or jaybizzle/crawler-detect, though existing manual registrations, the old crawler facade and the LaravelCrawlerDetect container binding remain supported through compatibility aliases, and if your application explicitly requires either package, Composer keeps that dependency and its classes take precedence.

What this is not, and where the alternatives start

Two boundaries matter. The first is that this is an activity record, not a log pipeline. It has no shipping to a collector, no structured log format, no correlation identifiers and no trace context, so it does not substitute for something like a log aggregation service or an APM tool when you need to diagnose a request. The second is that the dashboard is server rendered Blade inside your own layout, which is the right choice for a Laravel application that wants one shell and one auth system, and the wrong choice if you want a reactive, live updating interface, since the package explicitly does not ship client-side dashboards for Livewire, Vue, React or Svelte. The alternative approaches differ in kind. A dedicated audit or activity package maintained by the framework team would give you the same records with less of the view configuration, at the cost of the framework choices. An external service such as a logging or analytics backend gives you a richer query interface and retention model, at the cost of shipping the events off the box. What laravel-logger offers that those do not is that the activity rows live in your database next to your application data, so a report can join them, and the dashboard appears inside the product your users already log in to. On maintenance, the version history shows V11.1.1 in January 2026, V11.2.0 and v12.0.0 both on 2026-10-08, and the last push to the repository was on 2026-10-08, so the work is current. The project is MIT licensed, and the repository also carries a THIRD_PARTY_LICENSES.md alongside a FEATURES.md, TESTING.md and a LARAVEL9_LANG_FIX.md.

Editorial conclusion

Adopt laravel-logger if you want an in-application record of who did what, searchable from inside the same app, without standing up a separate logging or audit service. Do not adopt it as a general purpose log shipper, since it records application activity rather than diagnostics, and do not expect a modern reactive dashboard, because the interface is Blade and other frontends only link to it. Before you install, plan the database migration and the layout sections your app must render, and decide who may see the activity, since the default is that any authenticated user can open the dashboard.

Frequently asked questions

Official sources

1. Issues
2. jeremykenedy/laravel-logger on GitHub
3. License: MIT
4. README
5. Releases