Filament Memory Tracker Laravel Package

Getting Started

Requirements check first. This package's last release was February 2023, so before installing verify the version matrix in its composer.json: it was built for the Filament v3 era and Laravel 9/10. If you are on Filament v4 or Laravel 11+, expect friction — see Gotchas.

Install and publish:

composer require danilopolani/filament-memory-tracker
php artisan vendor:publish --tag="filament-memory-tracker-config"
# If the package ships migrations for a stats table:
php artisan vendor:publish --tag="filament-memory-tracker-migrations"
php artisan migrate

Register the plugin in your panel provider (app/Providers/Filament/AdminPanelProvider.php):

use Danilopolani\FilamentMemoryTracker\FilamentMemoryTrackerPlugin;

public function panel(Panel $panel): Panel
{
    return $panel
        // ...
        ->plugin(FilamentMemoryTrackerPlugin::make());
}

Where to look first.

1. The published config file (config/filament-memory-tracker.php) — it tells you the storage backend (cache vs. database), retention, and refresh cadence. That config is the source of truth for how the widget gets its data.
2. The service provider / plugin class — confirms whether the widget is auto-registered on the dashboard or must be added manually to ->widgets([...]).
3. The queue event listeners — this is where memory samples are captured; understanding this tells you whether tracking happens at the job level or the worker loop level.

First use case: open the admin dashboard and confirm the memory widget renders. Then php artisan queue:restart and push a representative job through the queue; watch the widget update. That round-trip (worker → listener → store → widget) is the whole package in one loop.

Implementation Patterns

Dashboard-first monitoring. The primary pattern is passive: register the widget on the Admin panel dashboard and treat it as an at-a-glance health tile alongside your existing Filament widgets. Add it to a dedicated "Operations" or "System" dashboard page rather than the default landing page if you have non-technical admins.

Pair it with a running worker. The widget is useless until a worker is actually consuming jobs with the package's listener active. A typical dev workflow:

php artisan queue:work --queue=default,emails --memory=256
# in another terminal, dispatch representative jobs
php artisan tinker
>>> App\Jobs\ExpensiveJob::dispatch();

Watch which queue/connection shows growth; that is your signal for --memory tuning and worker recycling (--max-jobs, --max-time).

Filtering by queue/connection. If the package exposes per-queue or per-connection breakdowns (check the config for a queues array), scope it to the workers you care about rather than every connection — otherwise noise from a busy sync or redis-backed queue drowns out the worker you're debugging.

Alerting / scheduled checks. Because the package records samples, you can bolt a scheduled command on top that reads the same store and fires a Slack/email alert above a threshold:

// app/Console/Kernel.php (or routes/console.php in L11)
$schedule->call(function () {
    $usage = cache('memory-tracker.latest.default');
    if ($usage && $usage > 200 * 1024 * 1024) {
        // Notify::route(...)
    }
})->everyFiveMinutes();

(Confirm the cache key format from the package source — this is the extension point most people need.)

Customization via published views. Publish the widget views (php artisan vendor:publish --tag="filament-memory-tracker-views") if you need to reformat the memory number, add a sparkline, or change the polling interval. This is far safer than subclassing internals.

Gotchas and Tips

Version currency is the biggest risk. 27 stars and a last release in Feb 2023 means: no Filament v4 support, no Laravel 11/12 CI, and any upstream Filament API change since then is untested. Budget for a fork if you're on a modern stack. Pin compatible versions explicitly in composer.json and lock them.

Restart workers after every deploy. Queue workers are long-running PHP processes; they keep the old code and old config in memory. php artisan queue:restart is mandatory after changing config, listeners, or the package itself — otherwise the widget will show stale or no data and you'll spend an hour debugging a non-issue.

Peak vs. current memory. PHP's memory_get_peak_usage() never resets within a worker process. If the package reports peak, a single heavy job early in the worker's life will make every subsequent reading look inflated. Look for whether the package measures deltas per job (correct) or absolute worker memory (misleading) and interpret accordingly.

Record volume and retention. If the package writes a row per job to a database table, a busy queue will grow that table fast. Check for a prune command or schedule one; if data lives in cache, confirm the TTL — otherwise you may be looking at a stale sample from yesterday.

Testing blind spots. Queue::fake() and Bus::fake() bypass the real queue events, so the tracker records nothing in tests. Don't assert on tracked memory in feature tests; use a real queue connection (database driver) in a dedicated integration test if you need coverage.

Authorization. Filament widgets inherit panel access, but if you only want senior devs/ops to see memory data, gate the widget with canView() rather than assuming the whole panel should see it.

Config cache. php artisan config:cache in production means editing the published config file has no effect until you re-cache and restart workers. Make both part of your deploy script.

When to not use it. For production-grade worker observability, Laravel Horizon (Redis) or a proper APM (Sentry, New Relic, Tideways) gives you per-job memory, throughput, and failure context that a dashboard tile cannot. Treat this package as a dev/staging convenience or a lightweight sanity check, not a replacement for real queue monitoring.