Laravel Log Reader Laravel Package

Getting Started

This package is a lightweight, self-hosted log viewer: it registers a single route that lists files in storage/logs and renders their contents in the browser. It is best treated as a fast local/staging debugging convenience, not as a production observability tool.

Minimal setup

composer require haruncpi/laravel-log-reader

Laravel package auto-discovery registers the service provider. Publish the config if you need to change the route or middleware:

php artisan vendor:publish \
  --provider="Haruncpi\LaravelLogReader\LogReaderServiceProvider" \
  --tag=config

Then set the relevant environment values:

LOG_READER_ENABLED=true
LOG_READER_ROUTE=admin/log-reader

Visit /admin/log-reader (or whatever route you configured) while logged in under the middleware you choose.

Where to look first

1. config/log-reader.php — controls enablement, route path, and middleware.
2. The package route file — confirms the exact URI and route name in your installed version.
3. storage/logs — the package reads files from this directory; confirm your logging channel writes there.

First use case

A staging report fails with a 500 and you do not have SSH access. Open the log reader, select the current laravel-YYYY-MM-DD.log file, search for the exception class or request ID, and read the stack trace in context. This replaces ad-hoc tail -f for quick triage and makes it easy to download a log file to attach to a ticket.

Implementation Patterns

Lock the route down immediately

The package route is a browser-facing file reader. Default middleware is usually just web, which means no authentication. Put it behind auth and an authorization gate:

// config/log-reader.php
return [
    'enabled' => env('LOG_READER_ENABLED', false),
    'route' => env('LOG_READER_ROUTE', 'log-reader'),
    'middleware' => ['web', 'auth', 'can:viewLogs'],
];

// app/Providers/AuthServiceProvider.php
Gate::define('viewLogs', function (User $user) {
    return $user->is_admin;
});

Enable it only in local/staging:

# .env.local / .env.staging
LOG_READER_ENABLED=true
LOG_READER_ROUTE=admin/log-reader

# .env.production
LOG_READER_ENABLED=false

Link it from your admin panel

Use the configured path rather than hardcoding the URI, so environment-specific route changes keep working:

<a href="{{ url(config('log-reader.route')) }}" target="_blank">
    Application Logs
</a>

For Filament, Nova, or a custom admin dashboard, add this as an external/navigation link rather than rebuilding the viewer.

Use daily log files as your navigation model

The reader is easiest to use when logs are split by date. Prefer the daily channel for applications where you expect to inspect logs interactively:

// config/logging.php
'default' => env('LOG_CHANNEL', 'daily'),

'daily' => [
    'driver' => 'daily',
    'path' => storage_path('logs/laravel.log'),
    'level' => env('LOG_LEVEL', 'debug'),
    'days' => 14,
],

This gives you one file per day in the UI and avoids a single multi-gigabyte laravel.log that is slow to open.

Triage workflow

A practical day-to-day loop:

1. Reproduce the issue on staging.
2. Open the newest daily log file.
3. Search for the exception class, route path, job class, or a request/correlation ID included in log context.
4. Copy the stack trace into the ticket or download the file.
5. Delete or archive old logs only after triage is complete.

Programmatic access

The package exposes a small LogReader class that can be used from an artisan command or internal tool when you do not want the HTTP route:

use Haruncpi\LaravelLogReader\LogReader;

$files = LogReader::getLogFiles();

$entries = LogReader::getLogs('laravel-2025-01-01.log');

Verify method names against the installed package version, because the API is intentionally minimal. For anything more advanced — filtering by level, parsing JSON logs, aggregating across servers — write a small custom command instead of stretching this package.

Keep it out of the request path

Do not link the log reader from public error pages or expose its route in API responses. Treat it as an internal admin tool with its own access boundary.

Gotchas and Tips

Security is the main risk. Logs routinely contain tokens, passwords, PII, SQL, and full request payloads. A log reader with only web middleware is effectively an unauthenticated data leak. Always combine auth, a gate or role check, and environment gating. Consider an IP allowlist middleware for staging.

Route and config caching will bite you. After changing LOG_READER_ENABLED, the route path, or middleware, clear caches:

php artisan config:clear
php artisan route:clear
php artisan view:clear

Then re-run config:cache and route:cache in deployed environments. A stale route cache can leave the old path active.

Large files can exhaust memory or hang the browser. The viewer reads log files into the request; multi-hundred-megabyte files are painful. Rely on daily rotation, keep LOG_LEVEL appropriate, and avoid dumping huge payloads into logs. If logs are consistently large, this package is the wrong tool and a centralized system is better.

It only sees the local filesystem. In a multi-node, container, or ephemeral Kubernetes setup, each request may hit a different pod with a different log file. The reader shows only the local instance. Use centralized logging for distributed systems.

Permissions matter. The PHP-FPM/queue user must be able to read storage/logs. If the UI shows an empty list or an error, check ownership and permissions first:

ls -la storage/logs
sudo -u www-data test -r storage/logs/laravel.log && echo readable

Custom channels and formats may not render well. Channels writing outside storage/logs, JSON-formatted logs, or non-standard line formats can display poorly because the reader expects typical Laravel/Monolog text lines. Keep a standard single or daily channel available for interactive debugging.

Deleting logs from the UI is irreversible. If your version exposes delete/download actions, restrict them to trusted roles. In production, disable the reader entirely rather than relying on the UI to prevent deletion. Preserve logs for incident review and compliance.

Timestamps are only as reliable as your app timezone. Log lines use the application's configured timezone. When correlating with browser errors, APM, or UTC-based infrastructure logs, convert explicitly rather than assuming the displayed time is UTC.

Do not confuse APP_DEBUG with log visibility. The reader does not depend on debug mode, and turning debug off does not hide logs. Conversely, enabling debug mode can write more sensitive context into the same files the reader exposes.

Version compatibility needs checking. This is a small, low-maintenance package. Confirm its illuminate/* constraints against your Laravel version before adopting it, pin the version in composer.json, and smoke-test the route after framework upgrades.

Extension points are limited by design. You can change the route, middleware, and enablement via config, and override views if the package publishes them. For richer behavior — level filters, retention controls, audit logging of who viewed logs — build a thin internal controller or command around the package rather than forking it.