Filament Laravel Log Laravel Package

Getting Started

Install and register (the whole integration).

composer require saade/filament-laravel-log

Then register the plugin on the panel that should see logs — not necessarily your main admin panel:

use Saade\FilamentLaravelLog\FilamentLaravelLogPlugin;

public function panel(Panel $panel): Panel
{
    return $panel
        // ...
        ->plugins([
            FilamentLaravelLogPlugin::make(),
        ]);
}

Run php artisan filament:assets (v4.2.0 rebuilt the embedded Ace 1.44 editor, so asset publishing matters) and php artisan optimize:clear, then look for the new page in the panel navigation.

Where to look first.

1. The rendered page itself — open it against a staging log file and confirm it lists the files under storage/logs you expect.
2. config/filament-laravel-log.php after php artisan vendor:publish --tag="filament-laravel-log-config" if you need to change the log path, navigation group/label/sort, or translation strings. Confirm the actual keys in the published file — the package is small enough to read the source in ten minutes, and you should, because you're trusting it with your logs.
3. The plugin class source, specifically anything that governs who can reach the page and what clear does. Default access is typically "any authenticated panel user", which is almost never what you want.

First use case to ship: a read-only log page in a staging or internal ops panel. Pick one recurring support question ("what's the stack trace on the 500?") and route it there instead of SSH. Do not enable clearing in production on day one.

Implementation Patterns

Isolate it in an ops panel, not the customer-facing one. The strongest pattern is a separate Filament panel (/ops) whose canAccessPanel() is restricted to staff roles. That gives you one authorization boundary to reason about, keeps the page out of /admin where more people have accounts, and lets you disable the whole panel in one config flip.

public function canAccessPanel(Panel $panel): bool
{
    return $this->hasAnyRole(['ops', 'on-call', 'engineer']);
}

Split read from clear if the plugin lets you. The release notes confirm v4.2.0 made the clear action's copy explicit, but the package does not ship an audit trail. If the plugin does not expose a separate authorization hook for clearing, treat clearing as read access and solve it at the panel level: enable the plugin in staging, and in production either omit it or gate the panel behind a break-glass role. Never leave clear reachable by a broad support role in production.

Keep the log channel boring and predictable. The viewer browses files on disk, so your LOG_CHANNEL/LOG_STACK choice is your UI:

// .env — daily rotation means the page lists dated files, which is what you want
LOG_CHANNEL=daily
LOG_DAILY_DAYS=14

single gives you one laravel.log that grows unbounded and is painful to load. Structured/JSON channels and stderr drivers won't produce browsable files at all.

Treat it as a triage front door, not a search engine. Day-to-day usage looks like: post-deploy smoke check (open the page, confirm no new ERROR lines), support triage (find the timestamp a customer reports, read the surrounding stack trace, paste the exception into the ticket), and confirmation ("yes, the queue worker logged that"). For anything that needs cross-request correlation or alerting, link out to your real tooling from the same panel — Telescope locally, a managed log service in production.

Version pin. "saade/filament-laravel-log": "^4.2" — v4.2.0 is the release that adds Filament 5 support, constrains reads and clears to files the page lists, and cleans up the Ace listener on navigation. Do not run 4.1.x on Filament 5.

Gotchas and Tips

Clearing is destructive and irreversible. It deletes forensic evidence. Before you enable the page in production, get a written answer for "who is allowed to clear logs, and what happens after they do?" If the answer is fuzzy, ship read-only.

Logs contain secrets. Stack traces routinely include request bodies, SQL with PII, bearer tokens in headers, internal hostnames, and env values from dd() leftovers. An admin-panel log viewer turns one compromised support account into a data-exposure incident. Scope the panel role tightly, and consider whether your logs are safe to show to the people who'd have that role.

Ephemeral and multi-node deployments break the premise. In containers, the page shows that container's filesystem — the request may have been served by a pod whose logs are already gone, and rolling deploys destroy them. This package is for single-server or monolith deployments with persistent storage/logs. If you're on ECS/K8s/Lambda, this is the wrong tool and centralized logging is the answer.

Large files and memory. Check whether the viewer streams or loads files before you point it at a 500MB laravel.log. Rotate aggressively (daily + a short retention) and avoid ever letting single grow — an OOM on a log page is an embarrassing outage.

Permissions. The web server user must be able to read storage/logs (and, if clearing is enabled, write to it). A common failure is artisan writing as your deploy user with 0600 while www-data can't read — the page shows an empty list or throws. Check with sudo -u www-data ls -la storage/logs.

Assets and CSP. The rebuilt Ace editor loads JS/CSS assets. If your panel has a strict Content-Security-Policy or a non-standard asset host, verify the editor actually renders after deploy — a blank editor pane with a passing-looking page is the classic symptom. Re-run php artisan filament:assets on every deploy.

Missing directories and odd files no longer crash the panel (fixed in 4.2.0), but rotated/compressed files (laravel-2026-10-01.log.gz) and symlinks are unlikely to be handled gracefully. Don't rely on the viewer for archived logs — that's your retention tool's job.

Don't build tests around it. No dependents and 121 stars means low community validation and a single maintainer; the DOM and internal APIs are not a contract. Assert on your own logging behavior (channel, level, context) and treat this page as a manual operator tool. Keep ssh + tail or a managed log service documented as the fallback, and be prepared to vendor or fork — MIT licensing makes that cheap, which is the main reason the dependency risk is tolerable.

Check the translations and copy in your locale. v4.2.0 tidied the clear-action wording; if you support non-English panels, confirm the confirmation dialog still communicates "this deletes the file" rather than a generic "are you sure."