Filament Log Laravel Package

Getting Started

ryangjchandler/filament-log is a small Filament plugin that drops a log viewer page into your panel. Because it is a thin, low-traffic package, treat the source as the primary documentation — install, open the plugin class, and read it before wiring it into a real app.

Minimal path:

composer require ryangjchandler/filament-log

Then register the plugin on the panel you want it to appear in:

// app/Providers/Filament/AdminPanelProvider.php
use RyanChandler\FilamentLog\LogPlugin;

public function panel(Panel $panel): Panel
{
    return $panel
        // ...
        ->plugin(LogPlugin::make());
}

Confirm the exact class/namespace from the README or src/ — this package predates some of the Filament v3 plugin conventions, so the registration API may differ between Filament 2 and 3.

Where to look first:

1. src/ — usually a handful of classes: the plugin, a Pages/ log page, and maybe a parser/resource class.
2. config/ (if published) — typically the log directory, allowed extensions, and page slug/navigation settings.
3. The Filament panel provider — this is where access control and navigation grouping belong.

First use case: expose it on a local/staging admin panel so you can read storage/logs/laravel.log without SSH. Hit /admin/logs (or whatever slug the plugin registers) and confirm it renders. Do that before adding authorization, so you know the baseline works.

Implementation Patterns

Scope it to the right panel. Register the plugin only on an internal/admin panel, not on a customer-facing one. If you have AdminPanelProvider and AppPanelProvider, keep it in the former.

Gate it behind authorization. A log viewer leaks stack traces, SQL, file paths, and sometimes secrets in exception messages. Use Filament's canView() / canAccess() hooks (or a policy/Gate) rather than relying on panel login alone:

LogPlugin::make()
    ->canViewUsing(fn () => auth()->user()?->is_admin === true),

The precise method name varies by version — check the plugin class for the can* methods it actually exposes.

Environment-gate it. For production you usually want either no page at all or a read-only tail of the last N lines. Wrap registration:

->plugin(LogPlugin::make()->visible(fn () => ! app()->isProduction()))

Pair it with a real logging channel strategy. The viewer is only as good as what you write. If you rely on daily channels, make sure the plugin's configured directory matches storage/logs and that the filename pattern (laravel-YYYY-MM-DD.log) is picked up.

Use it as a triage surface, not a debugging tool. Day-to-day workflow: open the page, filter to error/critical, copy the exception class into your IDE, then go back to Telescope/ray/Xdebug for the actual trace. The viewer answers "what broke and when," not "why."

Complement, don't replace, existing tooling. If you already run Telescope, Sentry, or Flare, this plugin's value is the cheap "last 100 errors on staging without a VPN" case. Don't duplicate alerting logic into it.

Gotchas and Tips

Large log files will hurt. Most simple viewers read the whole file into memory or into a collection. A 200 MB laravel.log can blank the page or blow PHP's memory limit. Cap reads (tail N KB), rotate logs aggressively, and never point it at a file you haven't checked the size of.

Daily vs single channel. The plugin likely globs *.log. That works for both single and daily, but it will also list unrelated files you drop in storage/logs. Check whether there's a configurable pattern before assuming.

JSON-formatted logs break line parsers. If you use Monolog's JsonFormatter (common with Logstash/Datadog shipping), a line-based regex parser will show raw JSON blobs or nothing. Either keep a human-readable channel for this viewer or accept the degraded UX.

Permissions. The PHP-FPM user must be able to read storage/logs. On hardened prod setups where the web user is denied read access to logs (a good idea), the page silently shows empty — that is a feature, not a bug.

Filament version drift. This package has few stars and no dependents, so it is unlikely to track Filament majors promptly. Pin it, test on Filament upgrades, and be prepared to fork. Check composer.json constraints before installing.

Navigation and slug collisions. If you already have a "Logs" page or the default slug clashes, override the slug/navigation label in the plugin config rather than editing vendor files.

Extension points are thin. Expect to extend by subclassing the page or parser class, or by publishing the view. If the plugin doesn't expose what you need, a small custom Filament page reading a tailed file is often less work than fighting it.

Debugging the plugin itself. If the page 500s, it's almost always (a) a Filament version mismatch, (b) a missing view namespace, or (c) an unreadable log path. Check storage/logs/laravel.log for the plugin's own exception — mildly ironic, but it's the fastest signal.