Nova Log Viewer Laravel Package

Product Decisions This Supports

• Build vs. buy (and the answer is "neither, just install it"). A log viewer is the classic internal tool that gets scoped as a one-sprint build and then quietly absorbs maintenance forever — file rotation edge cases, auth handling, framework upgrade churn. This package deletes that line item from the roadmap. It's first-party (published under the laravel/ namespace, released by a Nova core maintainer), installs with one Composer command, and registers with one line in NovaServiceProvider::tools(). Its low opportunity score is the point, not a weakness: there is no competitive differentiation in writing your own log viewer, so the correct move is to spend zero engineering hours on it and redirect them to product work.

• Who owns first-line diagnosis: support, or engineering? This is an operating-model decision disguised as a tooling decision. Does 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 this is a commitment to the former — and a measurable one, if you track ticket escalation rate before and after.

• Where this sits on the observability roadmap. Be explicit internally: this is triage, not observability. It answers "what just broke on this box, right now?" It does not answer "how often, on how many hosts, and who gets paged?" Writing that boundary down is what lets you defer a paid log platform while the product is small, and gives you a concrete trigger list — multi-server, alerting requirements, retention/compliance, PII redaction, access auditing — for when that spend becomes justified rather than aspirational.

• An explicit access policy for raw logs. Adopting this forces a decision you should have made anyway: which Nova users may see raw application logs? Log files routinely contain stack traces, internal hostnames, SQL fragments, customer email addresses, and the occasional leaked token. The package ships no RBAC of its own — it inherits whatever Nova gates you have, and a recent release specifically fixed unauthenticated access to redirect rather than 403. That fix is reassuring, but it is authentication, not authorisation. Treat role gating as a launch prerequisite, not a follow-up ticket.

• Squeezing more value from an existing Nova licence. Nova is already a per-seat commitment. Adding a daily reason for support and QA to open it strengthens the renewal case and improves the ROI narrative for the admin panel as a whole.

• A concrete, defensible pilot scope:

  • Support confirming a customer-reported error before escalating.
  • Engineers checking a deploy or failed queued job without CLI or SSH access.
  • Staging/UAT QA where a tester needs to see why a request failed.
  • Agencies handing a client an admin panel where the client can self-diagnose routine issues.

When to Consider This Package

Adopt when most of these hold:

• Laravel Nova is already load-bearing, with a team that logs in daily. If Nova is vestigial, the marginal value here is close to zero.
• Logs are written to local disk (single/daily driver) on a host the Nova app can read. This package reads files; it is not a shipping or aggregation layer.
• The fleet is small and long-lived, so "the logs" is an unambiguous location.
• Log volume is modest. Polling is the headline feature, and it means repeatedly reading a growing file. The README documents no batching, pagination, or throttle control — validate against real volume on staging before committing.
• The current workflow is CLI-first (tail -f, SSH) and that friction is a measured pain point, especially for people who cannot SSH.
• You want a maintained dependency rather than an owned one. The release history is the strongest signal available: consecutive releases added Laravel 12, Laravel 13, and Nova 5.7.7/5.9.0 support, plus fixes for multiple storage-file selection, missing log files, and the auth-redirect behaviour above. That is the cadence you want sitting behind your admin authentication path.

Look elsewhere when any of these hold:

• No Nova. The package is inert without it, and Nova is a separate paid licence. Never let a log viewer be the reason you buy Nova — that inverts the cost argument, because the "free" package then depends on a paid platform.
• Logs are centralised or off-host (CloudWatch, ELK/OpenSearch, Datadog, Papertrail, container stdout on ephemeral pods). The viewer will show an empty or misleading file — and in a multi-replica deployment, only whatever replica happened to serve the request.
• You need capability, not viewing: historical search, aggregation, alerting, retention policy, PII redaction, or an audit trail of who viewed what. None of that is in scope. Pair with a real platform rather than asking this tool to grow into one.
• Compliance or data-residency rules forbid rendering raw logs in a browser session, or require documented access auditing. The absence of package-level authorisation is a blocker until you wrap it in your own Nova policy.
• You need an SLA or a vendor support contract. Open-source package under the Laravel org, not a commercially supported product. Fine for internal tooling; a poor fit for contractual uptime obligations.
• Third-party adoption is a procurement gate. 138 stars and zero recorded dependents are low. Read that alongside the first-party maintenance signal: maintenance is strong, crowd-sourced battle-testing is weak. If your policy requires demonstrated adoption, escalate this as a policy exception, not a technical one — the alternative is inventing an exception route for every genuinely good internal tool.

How to Pitch It (Stakeholders)

For executives — one paragraph. We can put application log visibility inside the admin panel we already pay for, for roughly half a day of engineering time and no new vendor contract. The business outcome is faster time-to-diagnosis on production issues and fewer engineer interrupts, because support staff can answer "what went wrong with this customer's request?" themselves. It is built and maintained by the same team behind Nova, so it moves with our framework upgrades instead of becoming orphaned internal code. The honest limit: this is convenience and triage, not monitoring. I am not claiming a percentage reduction in incident time until we measure it — I would propose tracking ticket escalation rate for one quarter and deciding any further observability spend from that data.

For engineering — the short version. composer require laravel/nova-log-viewer, then add \Laravel\Nova\LogViewer\LogViewer::make() to tools() in NovaServiceProvider. No new infrastructure, no config service, no migrations, no queue workers, no secrets. It reads Laravel's log files from disk and polls for near-real-time refresh. It is read-only by design, so the risk is disclosure, not integrity — nothing here mutates application state, and the worst failure mode is "can't see logs," not "broke production." First-party, currently tracking Laravel 12/13 and recent Nova 5.x, and it recently fixed auth handling so unauthenticated users redirect instead of receiving a 403. Two things to review before production: (1) confirm it sits behind Nova's auth gate and decide explicitly which Nova roles may see raw logs, since stack traces and context routinely carry customer data and secrets; (2) smoke-test polling against our actual log volume on staging, because there is no documented throttling or pagination knob to tune. Exit cost is a composer remove plus one deleted array entry — which is why this should be a time-boxed pilot, not a committee review. Budget half a day including the staging spike.

For support and DevOps — the pitch that lands. No more Slack messages asking an engineer to go read a log file, and no SSH. Logs appear in Nova, where you already work, and the view refreshes on its own so new errors show up while you watch. You can confirm in seconds whether a customer's issue is a genuine application error before escalating, and paste the relevant entry straight into the ticket. What it will not do: search back through last month, tell you how often an error occurred, or alert anyone. Anything beyond "what happened just now" still goes to engineering.