Statamic Logger Laravel Package

Getting Started

Install the addon with Composer and run the Statamic addon installation routine:

composer require mitydigital/statamic-logger
php artisan vendor:publish --tag=statamic-logger-config
php artisan vendor:publish --tag=statamic-logger-migrations
php artisan migrate

Look first at the published config file (config/statamic-logger.php) — that's where you control which events are captured and where log records are stored. Then check the Statamic Control Panel for the log listing view (usually under Tools or Utilities) so you know where to inspect activity.

The fastest first use case is auditing content changes: enable entry save/delete logging, edit a page, and confirm a record shows up in the CP listing. This validates that events fire, that the migration ran, and that permissions are set up before you rely on it in production.

Implementation Patterns

Event-driven capture. The addon is typically wired into Statamic/Laravel events (Entry::saved, Entry::deleted, user login/logout, etc.). Rather than calling a logger manually, let the configured listeners do the work. If you need custom events (e.g., "exported report"), add them to the config's event list rather than scattering Log::info() calls — keeps everything queryable from the same table.

Programmatic logging from your own code. When a configured event isn't enough, inject the logger service or use its facade in a controller/job:

app(\Mity\StatamicLogger\Logger::class)->log('exported', ['count' => $rows]);

Keep the payload an array; it gets serialized into the log entry and is much easier to filter/search later than a free-form string.

Querying logs for reporting. Log entries are stored in a database table, so you can query them like any Eloquent model from a custom report, dashboard widget, or scheduled digest. This is the pattern to reach for when someone asks "who changed this entry last week" — don't scrape the CP, query the table.

Retention / pruning. Most log addons ship a prune command or a configurable retention window. Schedule it (e.g., daily in routes/console.php or the Statamic scheduler) so the table doesn't grow unbounded. This is the single most common production maintenance step for a logger.

Pairing with Laravel's logging. This addon records business events into its own table; it does not replace Log/laravel.log. Keep both: use the addon for human-auditable actions and standard Laravel logging for debugging. Don't try to make one do the other's job.

Gotchas and Tips

3.0.3 removed ShouldQueue — logging is now synchronous. In 3.0.2 and earlier, the logger's listeners/jobs implemented ShouldQueue, so log records were written asynchronously by a queue worker. After 3.0.3, records are written inline during the request. Consequences to plan for:

• No queue worker required anymore. If you were getting silent log gaps because queue:work wasn't running, that resolves itself — but only after upgrading.
• Slight request-time cost. Every logged event now does a DB write during the request. On high-traffic sites with verbose event configs, watch for increased write IO. Trim the enabled-event list before scaling up, and consider keeping heavy custom events in your own queued listeners instead.
• Ordering is now accurate. Previously queued writes could arrive out of order relative to each other; synchronous writes preserve submission order, which matters for audit trails.
• No breaking config change, but if you have a test that asserted a ShouldQueue listener was registered, update it.

Upgrade steps are light. This is a patch release; composer update is enough. Run the test suite once to confirm nothing depended on queued dispatch timing. If you had a queue worker dedicated to logging, you can retire it.

Event lists are additive by default. When you publish the config, it overwrites. Merge new keys from the package's config/statamic-logger.php by hand during upgrades rather than re-publishing, or you'll lose your customizations.

Permissions. The CP listing is usually gated behind a Statamic permission. If a non-super user can't see logs, it's a permission issue, not a missing record — check the permission mapping in the config.

Payload size. Because entries are written synchronously now, a large model payload (e.g., logging the entire entry object) makes every save slower. Log IDs and identifiers, not full serialized models.

Timezone/ordering. created_at follows your app timezone setting. If you cross-reference against server logs, set both to UTC in config to avoid confusing offsets during debugging.

Extension points. To customize what gets stamped on a record (user, IP, context), extend the base log model or subscribe to the addon's model events rather than editing vendor files — patches to the package will overwrite anything you put under vendor/.