Product Decisions This Supports
- Build vs. buy for internal ops tooling. A "Logs" page in the admin panel is the kind of feature every Laravel/Filament team eventually writes and nobody wants to own. This package is a credible buy: MIT, drop-in, small surface area. The decision it informs is whether to spend 1–3 engineer-days building a bespoke viewer (auth, file resolution, search, pagination over large files) or adopt and move on.
- Support-tier escalation design. Putting read-only log access behind the panel lets Tier 1/2 support triage "my export failed" without pinging an engineer for SSH or a log paste. That's a staffing/workflow decision — it changes the support runbook and the on-call load — not just a feature decision.
- Incident response scope on the roadmap. It answers "do we need observability-lite in-app before we need real observability?" Useful for early-stage products and agencies running many small client deployments where standing up Loki/Datadog per app is disproportionate.
- Channel-aware resolution as a design precedent. Because files are resolved from
config/logging.php rather than a hardcoded path (single, daily, monolog streams, stack file members), it fits existing logging config without forcing a logging refactor. That reduces the migration cost estimate for adoption.
- Environment gating decisions. Where to enable it (staging, internal admin, per-tenant panels) is a policy call the PM owns, not the implementer — log content routinely contains tokens, emails, and customer payloads.
- Decisions it explicitly does not support: alerting, retention policy, cross-service search, log aggregation, or audit trails. If those are on the roadmap, this package is a stopgap, not a foundation. Don't let it defer a real observability decision indefinitely.
When to Consider This Package
Good fit when:
- You already run a Filament panel (v3/v4) and the team lives in it daily.
- Logs are local files on a single host or a shared volume — classic single-server or small-fleet Laravel.
- The audience is internal: engineers, support, account managers with a legitimate need.
- You want zero infrastructure change and zero vendor cost, and you're comfortable pinning a version.
- Time-to-value matters more than long-term ownership — e.g., a client deployment where a bespoke admin feature isn't billable.
Look elsewhere when:
- Logs are ephemeral or distributed (containers, autoscaled workers, multi-node). There is no file to read; you need a shipper and a store — Sentry, Flare, Loki/Grafana, Papertrail, Datadog.
- You need alerting, retention guarantees, structured query, or correlation across services.
- Log content is regulated or contains customer PII and you can't confidently restrict access — this is a diligence blocker, not a nice-to-have. Verify authorization/policy gating before rollout; the README excerpt doesn't establish it.
- The panel is customer-facing or multi-tenant without strict scoping.
- Log volumes are large enough that in-browser rendering and in-file search become a UX problem (very large
daily files, high-traffic apps). Test against your real production log size first.
- You need a vendor with a support contract or SLA.
Adoption risk to price in: 6 stars, 0 dependents, single-agency maintainer, no third-party validation. Mitigating factors: MIT, narrow scope, and it's a UI over files — the exit cost is a fork or a delete. Treat it as a utility dependency, not a platform bet.
How to Pitch It (Stakeholders)
To executives: "It's a free, open-source plugin that puts log reading inside the admin panel we already use. It replaces an internal tool we'd otherwise build and maintain, at roughly 1–3 engineer-days saved, with no infrastructure or vendor cost. It's reversible in an afternoon if we don't like it."
To engineering: "Drop-in Filament plugin. It reads your existing config/logging.php channels — single, daily, monolog streams, stack file handlers — so no logging changes. Slide-over viewer with search, match navigation, and keyboard shortcuts; raw file download. MIT, so we can fork if the maintainer goes quiet. Two asks: (1) gate it behind a policy and enable it only in internal/staging panels, (2) pin the version and smoke-test against a realistically large log file before we ship it to support."
Framing the risk honestly: the package is small, new, and lightly adopted. That's acceptable because the blast radius is small and the scope is narrow — it renders files, it doesn't touch data. The real risk isn't the code, it's exposure: logs contain secrets and PII, so the access-control decision matters more than the dependency decision. Recommend a scoped pilot on staging, one named owner, and a re-evaluation trigger if the maintainer stops releasing or we outgrow file-based logs.