Nova Log Viewer Laravel Package

Technical Evaluation

Verdict for the TPM: A half-day, fully reversible capability add — approve as a scoped pilot if Nova is already licensed and the app writes conventional log files to local disk. Do not frame it to stakeholders as an observability investment, and do not let a log viewer become the business case for buying Nova (that inverts the economics: the "free" package would then depend on a paid platform).

Architecture fit. This is a Nova tool — a registered panel inside the existing Nova application, not a new service. That is the entire architectural story: no migrations, no queue workers, no new secrets, no external endpoint, no config service, no asset build on our side. It reads files from the app's own log directory via the PHP filesystem layer and renders them in the Nova UI, with polling for near-real-time refresh. Because it is read-only by design, the risk profile is disclosure, not integrity — nothing mutates application state, and the worst failure mode degrades to "can't see logs," not "broke production." That asymmetry is what makes this a low-ceremony approval.

Fit is strong when: single-region Laravel monolith; Nova is load-bearing and staff log in daily; single/daily log driver on local disk; and the incumbent workflow is tail -f over SSH — friction that support, QA, and agency clients structurally cannot pay.

Fit is poor when: API-only/headless services with no Nova to attach to; containerised or autoscaled deployments where each request reads only whichever replica served it; or an estate already centralising logs in CloudWatch/ELK/Loki/Datadog, where this becomes a second-class duplicate with a misleading emptiness. Also poor where compliance requires access auditing or redaction — neither exists in the package.

The structural limit to put in writing in any business case: it answers "what just broke on this box, right now?" It does not answer "how often, on how many hosts, and who gets paged?"

Integration feasibility. Near-zero. composer require laravel/nova-log-viewer, then add \Laravel\Nova\LogViewer\LogViewer::make() to the tools() array in NovaServiceProvider. Commit a half-day envelope — install, staging spike, permissions decision — and treat anything beyond that as a scope signal worth investigating rather than absorbing quietly.

Technical risk. Three items, none of which are architectural:

1. Disclosure surface. Logs routinely carry stack traces, internal hostnames, SQL fragments, email addresses, and the occasional leaked token. The package ships no RBAC of its own and inherits whatever Nova gates exist — so "who may view raw logs" becomes a deliberate role decision, not an inherited default. This is the one gate I would not let a pilot skip.
2. Polling under real volume. Polling is the headline feature and it means repeatedly reading a growing file. The README documents no batching, pagination, or throttle control. No knob to tune means no knob to turn when it degrades — hence a staging spike against production-shaped logs is a pass/fail criterion, not a nice-to-have.
3. Adoption signal. 138 stars and zero recorded dependents is thin crowd-sourced battle-testing. Read that separately from maintenance, which is strong: consecutive releases added Laravel 12, Laravel 13, and Nova 5.7.7/5.9.0 support, plus a fix so unauthenticated users redirect instead of receiving a 403. If procurement requires demonstrated third-party adoption, escalate that as a policy exception, not a technical objection — and be honest that you're leaning on the first-party maintainer signal, not the crowd.

Key questions to close before approval.

• Is Nova already load-bearing, or would this be the excuse to buy it? (If the latter: stop.)
• Are logs on local disk on a host the Nova app can read — and is that a single, unambiguous location?
• Which Nova roles get this panel, and does that decision have a named owner?
• What is peak log volume on the busiest day, and does staging reproduce it?
• Is there a written trigger for graduating to a real log platform (multi-server, alerting, retention/compliance, PII redaction)?
• What is the baseline ticket-escalation rate we'll measure against, so the pilot has a verdict and not just an opinion?

Integration Approach

Stack fit. Composer package into an existing Laravel + Nova application. It adds a route, a tool registration, and PHP-side file reads — nothing that touches the deploy topology, the data model, or the runtime contract. For a TPM this matters because it means the change is reviewable by one engineer in one sitting and carries no cross-team dependency: no infra ticket, no security review of a new network path, no vendor onboarding.

Migration path. There isn't one, and that's the point. No data migration, no publish step, no config to port. The "migration" is the deletion of a workflow, not the movement of data: support stops asking engineers to SSH, and engineers stop context-switching for what is now a two-click check. Frame it internally as workflow displacement rather than system replacement — the CLI stays available as the fallback and remains the correct tool for anyone who needs grep across rotated history.

Compatibility. Currently tracks Laravel 12, Laravel 13, and Nova 5.7.7 through 5.9.0. Two things a TPM should verify rather than assume: pin the Nova and Laravel versions in the pilot's acceptance criteria, and confirm the app's log driver is single/daily on local disk — because on stderr, a container runtime, or an off-host aggregator, the tool installs cleanly and shows nothing. A silent empty view is the compatibility failure mode to screen for, not an error page; it will be misread by support as "no errors."

Sequencing. Deliberately linear, roughly half a day:

1. Confirm the prerequisite — Nova licensed and in daily use, logs on local disk. Minutes, and it's the only step that can kill the project.
2. Permissions decision, before install — which Nova roles see the panel, decided by a named owner and recorded. Doing this after install risks it never happening and raw logs quietly defaulting to whoever has Nova access.
3. Install on staging, register LogViewer::make() in tools().
4. Staging spike — load production-shaped log volume, exercise polling, watch for read latency or browser strain. Pass/fail gate; a fail here means defer, not tune, since there's no throttle knob.
5. Pilot with support/QA — the four concrete use cases: confirming a customer-reported error before escalating, checking a deploy or failed queued job without CLI, staging QA diagnosis, and agency handover where a client self-diagnoses routine issues.
6. Measure one quarter, then decide on any observability spend from data.
7. Production, behind the step-2 policy.

Keep steps 3–5 in one half-day block; splitting them across sprints is how a half-day task becomes a three-week one.

Operational Impact

Maintenance. This is the strongest argument in the package's favour and should be the lead in the engineering pitch. It's a first-party package under the laravel/ namespace, with a release authored by a Nova core maintainer and a cadence of consecutive support releases (Laravel 12, Laravel 13, Nova 5.7.7/5.9.0) plus an auth-handling fix. A log viewer is the archetypal "we'll build it in a sprint" tool that then gets quietly maintained forever; adopting this removes that decision from the roadmap entirely and redirects those hours to product work. Exit cost is a composer remove plus one deleted array entry — which is precisely why this should be a pilot rather than a committee review.

Support. The operational change here is an operating-model choice, not a technical one: do Tier-1/Tier-2 support get to answer "is this a genuine application error?" themselves, or does that stay an engineering-only function gated behind SSH and a Slack ping? Adopting the tool is a commitment to the former. Make that commitment explicit to both teams before rollout, because the value shows up as reduced engineer interrupts — and interrupts only fall if support is actually authorised to look. Note the honest ceiling when briefing them: it won't search last month, won't report frequency, won't alert anyone. Anything beyond "what happened just now" still goes to engineering. Set that expectation up front and you avoid a second wave of tickets asking the tool to do things it can't.

Scaling. The binding constraint is volume, and it scales against you. Polling repeatedly reads a growing file; there is no documented batching, pagination, or throttle. On a modest single-box deployment with modest log volume this is fine. Add hosts and you get a worse problem than slowness: each request reads only the replica that served it, so the view becomes inconsistent rather than merely stale — two refreshes can show different histories. Treat multi-server as a written trigger to graduate to a real platform, not a tuning exercise. This is the single most important expectation to set with stakeholders, because a log viewer that shows partial data is more dangerous than no log viewer: people trust it.

Failure modes. All degrade to "can't see logs," none to "broke production" — the read-only design is what makes the risk budget work. Enumerate them for the runbook:

• Empty view on a centralised/containerised log setup — the highest-risk failure, because it's silent and misread as "no errors." Screen for it at step 1.
• Missing log files — previously crashed the tool; fixed in v1.0.0. A reason to be on a current version rather than a pinned old one.
• Unauthenticated access — previously returned 403, now redirects to login (v1.2.0). Another currency argument; also a reminder that auth behaviour in this panel has been patched recently.
• Polling degradation on a large file — degraded UX, not an outage. No mitigation available beyond reducing log volume.
• Disclosure to an over-broad Nova role — the only failure mode with real business consequence, and the only one entirely within our control. It is a policy failure, not a package failure, which is why step 2 is sequenced before install.

Ramp-up. Effectively zero for anyone already in Nova — it's a menu item with a searchable list. Budget the half-day for engineering; budget a short walkthrough for support rather than formal training. The ramp-up cost that does exist is decision latency, not learning: the permissions call and the pilot's success criteria. Both are yours to close, and both are cheap. Proposed pilot success measure: ticket escalation rate to engineering, tracked for one quarter. Commit to that number publicly, and commit equally publicly to making no percentage claims about incident-time improvement until it's measured — the tool's job is to move one operational metric, and if it doesn't move, that's a finding worth having for a half-day's cost.