Nova Log Viewer Laravel Package

Getting Started

sergeich5/nova-log-viewer is a Laravel Nova tool that puts your application's log files inside the Nova UI, so you can read, filter, download, and clear logs without SSH-ing into a box. It is a convenience/ops tool, not a logging backend.

Minimal path to first render:

1. composer require sergeich5/nova-log-viewer (v1.0.2 — pin ^1.0).
2. Publish the config: php artisan vendor:publish --tag=nova-log-viewer-config (check the README for the exact tag/provider — provider namespaces vary between Nova tools).
3. Register the tool in app/Nova/NovaServiceProvider.php inside tools():

   public function tools()
   {
       return [
           new \Sergeich5\NovaLogViewer\NovaLogViewer(),
       ];
   }
   

4. php artisan config:clear && php artisan nova:publish if assets misbehave, then hard-refresh the Nova UI.

Where to look first, in order: the published config file (log path(s), file extension whitelist, tail/read limits, authorization callback), the tool's own canSee/authorize method, then the README for the exact config keys — this package's surface area is small enough that the config file is the documentation.

First real use case: an incident where a user reports a 500. Open Nova → Log Viewer in the sidebar → select today's laravel.log → filter to ERROR → copy the stack trace into the ticket. That replaces the usual tail -f over SSH and is the 80% workflow.

Implementation Patterns

Gate it per environment, not per install. The tool is only as safe as who can reach it. Use Nova's tool authorization (canSee/authorize on the tool class, or the package's config callback) so it's visible to admins everywhere and to on-call devs only outside production. A common pattern:

public function canSee(Request $request)
{
    return $request->user()->hasRole('admin')
        || (! app()->isProduction() && $request->user()->hasRole('developer'));
}

Handle daily vs single-file logs explicitly. With LOG_CHANNEL=daily you get laravel-2024-05-01.log; with single you get one ever-growing laravel.log. The file listing UI is far more useful in daily mode because you can jump to the exact day of an incident. If you run stack/stderr channels (typical in containerised deploys), there may be no file at all — point the config at whatever path your app actually writes, and be aware the tool silently shows an empty list when the path is wrong.

Multiple log sources. Configure an array of paths where the package supports it: app logs, queue worker logs, scheduled-task logs from separate LOG_CHANNELs. Keep them under one directory tree if possible so the file listing stays navigable.

On-call triage loop. Filter by level → read the newest occurrence → download the file when you need to grep locally or attach it to a postmortem → clear/truncate when you're done. Pair it with a real aggregator (Sentry, Flare, Papertrail) for anything that needs alerting or retention; use this tool for the "what just happened on this server" question.

Multi-environment Nova installs. If one Nova app fronts staging and a demo box, drive the log path from an env var (NOVA_LOG_VIEWER_PATH) and resolve it in config, rather than maintaining two configs.

Extend via published views. The Blade views and config are publishable; rebranding, adding a "copy permalink" button, or restricting the visible columns is a view edit, not a fork. Do this in resources/views/vendor/... so upgrades stay clean.

Gotchas and Tips

• Permissions are the #1 failure. The PHP-FPM user (www-data) must be able to read the log directory, and to write/truncate if you use the clear-log action. On containerised setups, logs often sit on a volume or are stdout-only — verify a file actually exists on disk before debugging the tool.
• Don't open a 2 GB log. Set the tail/read limit low. A tool that reads the whole file into memory will take the request worker down with it. Prefer tailing the last N lines; keep laravel.log rotated (or move to daily).
• Treat log contents as secrets. Stack traces leak DB credentials, API tokens, session IDs, and customer PII. Never expose the tool to non-admin Nova users, and consider IP allowlisting or a Local-style middleware on top of Nova's gate.
• config:cache bites. After editing the published config, php artisan config:clear (or config:cache in deploy scripts). A stale cached config pointing at the old path is the classic "it worked locally" bug.
• Republish on upgrades. If you've published the config or views, diff them against the vendor version after each bump; a patch release can still add a new default key you'll want.
• Debugging an empty file list: check (a) the configured path, (b) storage/logs vs your custom path, (c) file permissions, (d) whether the current LOG_CHANNEL writes to a file at all, (e) whether the extension whitelist excludes .log-adjacent names.
• Extension points: tool canSee/authorize, the published config for paths and limits, published Blade views, and any route middleware the tool registers (configurable in newer Nova versions via Nova::routes()->withMiddleware(...)).
• On v1.0.2 specifically: the release notes are only a GitHub compare link, so there's no documented breaking change, migration, or config addition. Treat it as a routine patch — bump ^1.0, run composer update sergeich5/nova-log-viewer, php artisan config:clear, and skim the linked diff before rolling to production. No code changes should be required on your side.