Download the PHP package edwardtich/laravel-failed-jobs-manager without Composer

Laravel Failed Jobs Manager

Laravel package for working with the standard failed_jobs table.

Features:

• standalone Laravel UI;
• optional Filament page;
• single failed job retry;
• bulk retry by selected IDs;
• single failed job delete;
• readable payload and exception summaries;
• English and Russian translations.

Bulk retry uses Laravel's native command format:

Table Of Contents

• Requirements
• Installation
• Publishing Files
• Configuration
• Standalone Laravel UI
• Filament Integration
• Filament Navigation
• Filament Cluster Menu
• Filament Shield And Permissions
• Localization
• Pagination
• Retry Key
• Actions
• Security
• Changelog

Requirements

• PHP 8.2+
• Laravel 11 or 12
• configured failed_jobs table
• configured Laravel queue failed job provider
• Filament is required only for Filament integration

Installation

Install the package:

For local package development through packages/, add a path repository to the host project's composer.json:

Then require the package:

Publishing Files

The package works without publishing the config file because the service provider recursively merges default settings during registration.

Publish the config only when you need to override routes, middleware, pagination, or Filament settings:

Publish Blade views:

Publish translations:

Configuration

After publishing, the config file will be available at:

The package should not automatically create this file in the host application during normal boot. This is standard Laravel package behavior.

Default configuration:

Standalone Laravel UI

The standalone UI is enabled by default.

Default URL:

By default, the route uses these middleware:

In production, do not leave access protected only by auth. This page can retry jobs, delete records, and show payload / exception, so access should be restricted to admins or a dedicated permission.

Example with role middleware:

If you use only the Filament page, disable the standalone UI:

Filament Integration

Filament is optional. The package does not require filament/filament in composer.json, so projects without Filament can still use the standalone Laravel UI.

Register the package page in your Filament panel provider:

If your panel path is /admin, the page will be available at:

Filament Navigation

Menu settings are configured in config/failed-jobs-manager.php:

Hide the page from the sidebar:

The page will still be accessible by URL if the current Filament user passes canAccess().

Filament Cluster Menu

If the project uses Filament clusters and a manually composed sidebar, configure the page as a clustered page.

Example:

The page must still be registered in the panel provider:

If the sidebar is composed manually through a parent item array, add the page there too:

Filament Shield And Permissions

If the project uses Filament Shield or Spatie Permission, prefer permission-based access instead of hardcoded role checks.

The package does not create permissions in the database by itself. This is intentional: permissions should be generated and assigned inside the application where Shield, roles, and guards are already configured.

Example:

If permission is null and Filament Shield is installed, the package will try to read the page permission generated by Shield automatically.

For production, it is better to define the permission explicitly. This keeps package behavior independent from Shield generation settings in each project:

If you want to set a permission manually, use the exact key generated by Shield. For example, with Shield settings separator => ':', case => 'pascal', and prefix => 'view', the generated page key is:

The package then checks:

roles is only used as a fallback. This is useful for roles like super_admin before Shield permissions are generated or assigned, but production access should preferably be permission-based.

After registering the page, generate Shield permissions:

Then open the Filament roles page and grant the required permission:

For example:

If Shield uses another separator, case, or prefix, the permission name will be different. In that case, check the actual permission name on the Shield roles page and set it in failed-jobs-manager.filament.permission.

Localization

The package contains English and Russian translations.

Laravel uses the current application locale:

Translation namespace:

Pagination

By default, the page displays 20 records:

The package always uses pagination to avoid loading the full failed_jobs table.

Search is limited before querying the database:

The search filter checks payload and exception with a wildcard LIKE query. Keep it for operational inspection, not for high-volume analytics.

Retry Key

Different Laravel versions can retry failed jobs by different identifiers. Older projects usually use numeric id, while newer projects may use uuid.

Retry key configuration:

Available values:

• auto - use uuid when it exists, otherwise use id;
• id - always call queue commands with the failed job ID;
• uuid - call queue commands with UUID, fallback to ID when UUID is empty.

The UI still selects rows by internal id. The retry_key setting is applied when calling Laravel queue commands for retry and delete actions: queue:retry and queue:forget.

Actions

Retry One Job

The package calls Laravel's queue:retry command with the configured retry key.

Retry Selected Jobs

The package collects selected IDs, resolves them to configured retry keys, and calls Laravel's native command:

When retry_key is auto or uuid, the command can look like this:

Delete One Job

The UI deletes one failed job through Laravel's native command:

The package is intended for Laravel's standard failed job storage and does not implement custom deletion adapters for non-standard failed job providers.

Bulk delete is intentionally not implemented. Failed jobs are operational data, and bulk deletion is too easy to misuse.

Security

The package exposes operational actions:

• retry failed jobs;
• delete records from failed_jobs;
• inspect payload;
• inspect exception messages.

Do not expose this functionality to every authenticated user. auth only means that the user is logged in; it is not an administrator check.

Recommended production setup:

• standalone UI: web, auth, and admin/permission middleware;
• Filament UI: Filament auth plus Shield/permission access;
• if you use only Filament, disable the standalone UI.

Standalone middleware example with permission:

Example with a project-specific admin middleware:

If the page is used only inside Filament, disable the standalone UI:

Changelog

See CHANGELOG.md.

License

MIT © Edward Tich