Filament Job Manager Laravel Package

Getting Started

Install and publish config

composer require adrolli/filament-job-manager
php artisan vendor:publish --tag="filament-job-manager-config"

Check the README for the exact publish tag and plugin class name — they follow Filament conventions but confirm before copy-pasting into a production panel provider.

Register the plugin in your panel provider (app/Providers/Filament/AdminPanelProvider.php). This is the standard Filament plugin pattern and is the same shape in v3 and v4:

use Adrolli\FilamentJobManager\FilamentJobManagerPlugin;

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

Verify prerequisites before expecting data to appear. The package reads Laravel's own queue tables, so:

php artisan queue:failed-table   # creates failed_jobs
php artisan queue:batches-table  # creates job_batches (Laravel 8+)
php artisan migrate

The "pending/running" views only show meaningful data when your queue driver persists jobs to the jobs table (i.e. database). With Redis or SQS those views will be empty or misleading — see Gotchas.

Where to look first

1. config/filament-job-manager.php — navigation label/group, polling interval, authorization callback, and whether widgets are registered.
2. The plugin class in vendor/adrolli/filament-job-manager/src — exposes the fluent configuration methods.
3. src/Pages / src/Resources — the Jobs and Batches screens you'll be extending.

First real use case: failed-job triage. Open the Failed Jobs page, filter by queue/connection, click a row, read the exception and payload side by side, fix the underlying bug, then retry the job. That single loop — inspect, fix, retry without shelling into the server — is the day-to-day value of this package.

Implementation Patterns

Triage workflow (the core loop). Filter failed jobs by connection and queue, sort by failed_at, open the payload to see the serialized arguments, then retry individually or use a bulk action. For "poison" jobs that will always fail (deleted model in a SerializesModels job, removed class), delete rather than retry — retrying just re-queues the same failure.

Post-deploy bulk retry. The most common operational pattern: deploy the fix, php artisan queue:restart, then bulk-retry all jobs that failed in a known window. Scope the retry by queue and time so you don't re-run unrelated failures from weeks ago.

Role separation via authorization. Wire the config's authorization callback to a Gate rather than leaving it open:

// config/filament-job-manager.php
'authorization' => fn () => auth()->user()?->can('manage-queues'),

Then grant manage-queues to ops/admin only. Support staff often need read access to exceptions but should not be able to delete or retry — configure that as two gates if the package exposes separate view/manage callbacks, otherwise keep the whole resource admin-only and use Filament's read-only table config.

Multiple panels. Register the plugin only on the ops/admin panel. If you have a customer-facing panel, do not add it there — the payload inspector exposes serialized job properties. If you need it on two panels with different scopes, create two plugin instances with different navigation groups rather than one shared registration.

Coexistence with Horizon. Horizon is better for throughput graphs, supervisor health, and long-term metrics. Use this package for the interactive "what failed and can I fix it now" workflow inside the admin panel. They read the same failed_jobs table, so retries made in the UI show up in Horizon and vice versa — no duplicate work, just two views. Don't try to make this package replace Horizon's metrics.

Embedding widgets. If the package ships a failed-jobs count widget, register it on your main dashboard so failures are visible without navigating. For a team-specific dashboard, register the widget in your own panel's ->widgets([...]) and scope it to the queues your team owns via config.

Custom actions. Extend the package's page classes when you need a "retry with modified payload" or "re-dispatch on a different queue" action. Override the table's actions array and add a custom Action that reads $record->payload, mutates it, and dispatches manually. Keep this in your app, not in vendor/.

Gotchas and Tips

Retrying does not reload your code. A failed job retried after a deploy still runs the new code only if workers were restarted. If you retry before php artisan queue:restart, long-running workers keep the old code in memory and the job fails again identically. Always restart workers first, then retry.

The pending-jobs view is driver-dependent. jobs table only exists for the database driver. With Redis/SQS you'll see an empty pending list and may conclude the queue is idle when it isn't. Communicate this to whoever uses the panel, or hide that page for non-database drivers via config if supported.

Payloads leak secrets. Serialized job constructors can contain API keys, tokens, model attributes, and PII. Restrict access tightly and never expose this page to customers or low-trust roles. If the package offers payload redaction or a "hide payload" toggle in config, enable it for broad-audience panels.

Deleting a job doesn't stop an in-flight worker. If a worker has already reserved the job, deleting the row removes the record but the job may still execute. Deleting is for failed jobs you've decided not to run — not a kill switch for running work.

Batch tracking requires that you use batches. The Batches page only shows rows in job_batches, i.e. jobs dispatched via Bus::batch(). Jobs dispatched with plain dispatch() will never appear there, no matter how many fail.

Large failed_jobs tables choke bulk actions. Bulk retry/delete runs one query per record in many Filament implementations. Add indexes on failed_at and queue, keep the table pruned (php artisan queue:prune-failed --hours=168 in the scheduler), and fall back to php artisan queue:retry all / queue:flush from the CLI if the UI times out.

Polling cost. A short polling interval on the jobs table hammers the DB on busy queues. Set it to 10–30 seconds in config, and don't enable polling on all three pages simultaneously if you have heavy traffic.

Retried jobs that immediately fail again usually aren't a queue problem. Read the exception: ModelNotFoundException means a SerializesModels job whose model was deleted; Class not found means the job class was renamed or removed. Neither is fixed by retrying — inspect the payload and fix or delete.

Config changes need a cache clear. After editing the config or plugin registration, run php artisan config:clear (and optimize:clear in production) or you'll debug a change that never took effect.

Pin the major version. Filament v3 and v4 differ in plugin/page APIs; this package's 5.x line targets a specific Filament generation. Check the README's compatibility table before upgrading either package, and lock the major in composer.json to avoid a surprise Filament upgrade breaking the admin panel.