Filament Log Viewer Laravel Package

Product Decisions This Supports

Build vs. buy for internal log visibility. If our admin panel runs on Filament (v3/v4/v5), this package turns "give support and ops a way to read logs without SSH" from a 1–2 sprint internal build into a composer require plus one plugin registration line. That makes it a low-cost experiment rather than a roadmap commitment.

Feature decision: do we need a first-party log UI at all? It reframes the question from "build a log viewer" to "do we need in-panel log triage?" The package covers the 80% job: parse, search, filter by level and date, inspect stack traces, preview mail payloads, copy a Markdown excerpt into an incident ticket. If that satisfies support workflows, it removes a backlog item.

Support and on-call workflow design. The Copy-as-Markdown action (configurable per level, e.g. error,warning) is the real product feature — it creates a clean handoff artifact from support → engineering → ticket. That's a process improvement we can pilot without any code.

Access and permission model decisions. authorize(fn () => ...) with a permission closure means we can scope log access to an admin role (or Filament Shield permission) and answer the "who may read production logs?" governance question with a config change instead of a new tool.

Environment-tiered rollout policy. Env-driven config lets us make one product decision per environment: destructive controls off in production (LOG_ENABLE_DELETE=false), delete/truncate allowed in staging and local, and a bounded read size (LOG_MAX_SIZE_KB, default 2 MB) so a runaway log file can't take down the admin panel.

Roadmap sequencing for observability. This is a triage convenience, not observability. It helps us decide whether we invest next in alerting, centralised log aggregation, or error tracking (Sentry/Flare-class), by first measuring how often the team actually goes looking for logs and what they do with them.

Vendor-risk hedging is a design input. Every component (page, provider, parser, schemas, actions, filters) is swappable via contracts and non-final protected extension points, so we can start with the local filesystem provider and swap in a custom/cloud provider later without rewriting the panel. That materially lowers the cost of trying it.

When to Consider This Package

Adopt when:

• The product surface is a Filament admin/staff panel on a supported version — pin ^0.x for Filament v3, ^1.x for v4, ^2.x for v5. Version mismatch is the most common integration failure here.
• Logs are on the local filesystem of the app server (the default LocalLogProvider reads files directly). Single-server or shared-volume setups are the sweet spot.
• The audience is internal: support, ops, QA, on-call engineers. Not end users.
• We want zero-build internal tooling and are comfortable with an MIT-licensed community package in a non-critical path.
• Log hygiene is reasonable — bounded file sizes, rotation in place. The default 2 MB read cap and the fingerprint-based cache (invalidated on file name/size/mtime change) handle moderate volumes well.

Look elsewhere when:

• We need alerting, metrics, retention, or cross-service correlation — this is a file reader, not an observability platform. Pair it with real error tracking rather than substituting for it.
• Logs live in S3, CloudWatch, Papertrail, or a log aggregator, or the app runs multi-container/immutable-infra where local files are ephemeral. Possible via a custom LogProvider, but that's now an engineering project, not a package install.
• Compliance/security posture forbids admin-panel access to raw production logs (PII in stack traces, mail bodies, request payloads). The mail preview feature is genuinely nice and genuinely a data-exposure surface.
• We need multi-tenant or per-user log scoping — there's no tenancy model here.
• Long-term vendor confidence matters. 53 stars, 0 dependents, and a single maintainer is a thin adoption signal. Acceptable for internal tooling; not something to build a customer-facing or SLA-bearing workflow on.
• We're not on Filament. Nothing here transfers to a plain Laravel or Inertia/React admin.

Adoption guardrails I'd set: pin an exact version, register the plugin behind an authorization closure, ship with LOG_ENABLE_DELETE=false in production, and document the replaceable-contract escape hatch so removal is a config change rather than a refactor.

How to Pitch It (Stakeholders)

To executives — one paragraph. Engineers and support currently diagnose production issues by asking for server access or waiting on a log paste. This package gives authorized staff a searchable log screen inside the admin panel we already have — filter by severity and date, read the stack trace, copy a formatted summary into a ticket. It's MIT-licensed, requires no new infrastructure, no new vendor contract, and roughly a day of integration. It is deliberately scoped: it does not replace error tracking or alerting, and I'm not proposing it as a platform. I'm proposing we stop losing engineering hours to log retrieval, then measure whether the usage justifies the next observability investment.

To engineering — the honest technical case. Drop-in Filament plugin: composer require, add FilamentLogViewer::make() to the panel plugins, done. Sensible defaults — 2 MB read cap, cache keyed on file fingerprint so it self-invalidates, 11 bundled locales, per-file and clear-all controls gated on config. The architecture is the reason I'm comfortable: page, provider, parser, schemas, actions, and filters are all bound through contracts with non-final extension points, so if the local filesystem assumption breaks we subclass or replace the provider rather than fork. Authorization is a boolean or closure, so it composes with Filament Shield permissions.

What I need from you: an explicit risk acknowledgement. This is a 53-star package with zero dependents and one maintainer — fine for an internal convenience screen, not fine for anything on the critical path. So: pin the version, keep LOG_ENABLE_DELETE=false in production, gate behind an admin permission, and treat upgrading it as a scheduled task rather than an automatic composer update.

Success criteria for the pilot: number of log-viewer sessions per week, tickets containing a copied Markdown log excerpt, and reduction in "can you send me the logs?" requests. If those don't move in a month, we uninstall it — the cost of finding out is a day, and the cost of backing out is a config change.