Laravel User Monitoring: activity tracking inside the application

Three kinds of record: visits, actions and logins

The package tracks user activities such as logins, page visits and model interactions, and the README's table of contents splits the documentation into three groups that map onto the three things it records.

Visit monitoring covers the request layer: which pages a user opened, with the visit monitoring views, the handling of Ajax requests, a guest mode for visitors who are not signed in, and custom conditions that decide whether a given request should be recorded at all. There is also a section on deleting visit monitoring records by specific days and a switch to turn the whole thing on or off.

Action monitoring covers the model layer, which is the part that is specific to Laravel rather than to the web in general. It records interactions with your Eloquent models, with its own views, its own guest mode, and its own custom conditions. A reverse proxy config section sits alongside it, which matters because the IP address a request appears to come from is exactly the wrong thing to trust when the application sits behind a load balancer.

Authentication monitoring covers logins, with its own set of views, and the user configuration section explains how the package ties a recorded event to a user record.

The result is a dashboard with insights including IP address, browser information and user behaviour. That is the value proposition in one line: it is an activity log for your own application, stored in your own database, rather than a third party analytics script that sees only what the browser chooses to send.

One Composer command, then publish the pieces you need

The requirements are PHP 8.0 or later and Laravel 9.0 or later, and installation is a single Composer command:

composer require binafy/laravel-user-monitoring

What follows is the part that makes this package more than a library. Almost everything the package does is publishable, and the README gives one artisan command per artefact.

The config file is published with the tag laravel-user-monitoring-config, the migrations with laravel-user-monitoring-migrations, the views with laravel-user-monitoring-views, the middleware with laravel-user-monitoring-middlewares, and the routes with laravel-user-monitoring-routes. If you would rather have all of it at once, you can publish everything in one go by naming the provider:

php artisan vendor:publish --provider="Binafy\LaravelUserMonitoring\Providers\LaravelUserMonitoringServiceProvider"

After publishing, the README tells you to run php artisan migrate.

That pattern, publishable everything, is the design decision worth noting. A package that registers its routes, views and middleware for you is convenient until you need to change a route or replace a view, and then it is a fight. Here you can take ownership of each piece, one artefact at a time, and the provider level command means the full set is still available for a fresh install.

The configuration file: model, foreign key, table and guards

The configuration file is where the package decides how recorded events connect to your users, and the README walks through the keys in order.

The user section names the fully qualified class name of the user model, the name of the foreign key column that links user data to other models, and the name of the table storing user data:

'user' => [
    /*
     * Specify the fully qualified class name of the user model.
     */
    'model' => 'App\Models\User',

    /*
     * Name of the foreign key column linking user data to other models.
     */
    'foreign_key' => 'user_id',

The section then covers the authentication guards used for verifying the user, and the README notes that multiple guards can be specified for flexible authentication strategies, and that the guards need to be configured correctly in the guards section of your own configuration. There is a separate configuration area for the foreign key type, with UUID, ULID and ID listed as the options, which is the key to check if your application uses UUIDs or ULIDs rather than auto incrementing integers, because the monitoring tables have to reference your users with the same type.

The routes section is configurable too. You publish the route file with the same laravel-user-monitoring-routes tag, edit routes/user-monitoring.php, and if you want a different file name entirely you change the file_path key in the config:

'config' => [
    'routes' => [
        /*
         * Path to the route file that handles user monitoring routes.
         */
        'file_path' => 'routes/user-monitoring.php',
    ],
],

The route file path lives inside a config key, which is a small but useful detail, since it means the dashboard URL does not have to be the default one.

Guest mode, Ajax requests and the custom conditions switch

Three settings decide how much the package records, and they are worth understanding before you enable it on a production site.

Guest mode appears in both the visit and the action sections, which means the package can record activity from visitors who are not signed in. That is a policy decision, not a technical one, because a guest record has no user to attach to, and the visit record will still carry the request's IP address and browser information.

Ajax requests are called out separately, and the reason is straightforward. A single page application can fire dozens of background requests, so recording every one of them turns a visit into a flood of rows. The package gives you a way to treat them differently, and the custom conditions sections for both visits and actions are the place to decide what counts.

The custom conditions are the most powerful and least documented part of the setup, and the README is thin on them. What is clear from the structure is that they exist per recording type, so you can be permissive about page visits and strict about model interactions, or the other way round, and that the same idea applies to the on and off switch for the whole package.

There is also a section on using the package in big projects, which is a signal that the recording volume is a design constraint rather than an afterthought. A row per visit, with IP and browser details, adds up quickly on a busy site, and the deletion by specific days feature is the counterweight.

Deleting old records is a scheduling job you have to set up

The retention story is the one place where the package hands work back to the application, and it is worth being explicit about the consequence.

The README has a section on deleting visit monitoring records by specific days. That is the only mechanism described for keeping the table from growing without bound, and it is a manual command or a scheduled one, depending on how your application runs jobs.

In a Laravel application the natural place for it is the scheduler, which means the package's storage cost is under your control rather than the package's. That is a reasonable design for a monitoring table, because the right retention period is a property of your compliance obligations and your disk budget, not of the library. The trade is that if you do not schedule the job, nothing prunes the table, and a table that grows by a row per request is the kind of thing that shows up in a disk alert rather than in an error.

The same reasoning applies to the visit and action tables separately. The README describes the deletion feature under visit monitoring, so if you enable action monitoring as well, it is worth checking what the action table does over time, because that is not something the documentation in this file answers.

A 1.x package with a permissive licence and a busy upstream

The package lives on Packagist as binafy/laravel-user-monitoring, the default branch is 1.x, and the licence is MIT, so there is no copyleft obligation if you install it into a commercial application.

The release history is regular. The recent tags are v1.2.6 on 2026-04-22, v1.2.5 on 2025-09-11 and v1.2.4 on 2025-09-05, so the 1.2 line is being maintained with patch releases rather than left alone. The last push to the repository was on 2026-08-14, and the repository is not archived, so the code is still moving.

The repository layout is the standard Laravel package shape, with a src directory holding the package code, a config directory, database for the migrations, resources for the views, routes for the route file, tests and a phpunit.xml, plus a CHANGELOG.md and a LICENSE at the root, and an art directory for the images used in the README banner.

The README also points to an AI documentation site for the package and a test workflow badge, so there is a test suite behind the releases, which is the main thing to look for in a package that writes to your database and renders a dashboard.

One thing to weigh is what the package is not. It is not a traffic analytics service, it does not replace a product analytics tool, and it does not give you funnels or retention cohorts. It answers a narrower question, which is what happened inside my application and who did it, and for a Laravel team that already knows how to read an activity log that is a reasonable tool to have.

Editorial conclusion

Adopt laravel-user-monitoring if you run a Laravel application and need to see what your signed in users actually do, which pages they visit and which models they touch, without building that instrumentation yourself. Do not adopt it if you need a general purpose analytics product, since it is an in-application activity log rather than a traffic analytics tool, and think hard before enabling it on a public site, because it records IP addresses and browser details per request. Verify first that your PHP 8.0 and Laravel 9.0 or later requirements match your application, that the user key you choose works with your primary key type, UUID, ULID or integer, and that the retention job for deleting old visit records is scheduled, since the package stores a row per visit by default.

Frequently asked questions

Official sources

1. binafy/laravel-user-monitoring on GitHub
2. License: MIT
3. Project website
4. README
5. Releases