Cron Manager Filament Laravel Package

Getting Started

v1.0.0 is the initial stable release of zpm-packages/cron-manager-filament, a Filament plugin for inspecting and managing Laravel’s scheduled tasks from a panel UI. Start by installing it into a Laravel app that already uses Filament (v3+ is the common target; confirm the constraint in composer.json).

composer require zpm-packages/cron-manager-filament

Then register the plugin in the relevant Filament panel provider (typically app/Providers/Filament/AdminPanelProvider.php):

use Zpm\CronManagerFilament\CronManagerPlugin;

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

If the package ships migrations or publishable config/assets, run the publish step and migrations:

php artisan vendor:publish --tag="cron-manager-filament-config"
php artisan migrate

First use case: open the new “Cron Manager” navigation item in your Filament panel, review registered scheduled commands, and use the UI to enable/disable or trigger a task. Treat this as a developer/ops convenience panel rather than a replacement for your system crontab.

Implementation Patterns

• Use it as a read-first operations panel. Wire it into a non-public admin panel and restrict access with Filament’s authorization (canViewAny, policies, or panel access middleware). Day-to-day, developers use it to confirm which tasks are registered, their cron expressions, and last run status.
• Keep php artisan schedule:list as the source of truth. If the UI differs from the CLI output, suspect schedule caching or a different runtime context. Add php artisan schedule:clear-cache to deploy scripts when schedule definitions change.
• Pair it with Laravel’s schedule definition. Define tasks in routes/console.php or app/Console/Kernel.php as usual; the plugin should reflect those definitions. Avoid duplicating schedule metadata in two places.
• Use it for ad-hoc “run now” checks in staging. Triggering a job from the panel is useful for smoke-testing a new scheduled command. In production, require explicit confirmation and log who triggered it.
• Integrate with existing observability. If the package exposes run history, link it to your log aggregator or Sentry. Don’t rely solely on the panel for alerting on failed schedules.
• Multi-panel setups. Register the plugin only on the panel where it belongs. If you need different access rules per panel, use separate panel providers or gate the plugin’s visibility with ->visible() / authorization callbacks.
• Custom navigation. Adjust navigationGroup, navigationLabel, navigationIcon, and sort order in the plugin registration to fit your admin’s information architecture.

Gotchas and Tips

• Schedule cache is the usual suspect. If a newly added task doesn’t appear, run php artisan schedule:clear-cache and verify the scheduler is running with the same codebase and environment as the panel.
• Web user vs. cron user. The panel runs as the web server user (e.g. www-data); the scheduler runs as the crontab user. Permission differences can make a “run now” action succeed in the panel but fail from cron (or vice versa). Check storage/log permissions and environment variables.
• Timezone drift. Laravel evaluates schedules in the app timezone unless a task specifies otherwise. The panel may display times in the user’s timezone. Confirm both before concluding a task is misconfigured.
• Overlapping jobs. A manual trigger from the UI can overlap with a cron-triggered run. Use withoutOverlapping() on long-running tasks and avoid triggering production jobs casually.
• Authorization is not automatic. Filament resources are only as secure as your panel access and policies. Add explicit gates for the Cron Manager page, especially if the panel is reachable outside a trusted network.
• Version compatibility. v1.0.0 is new; pin the package version in composer.json and verify compatibility with your Filament major version before upgrading. Check the changelog for breaking changes in future releases.
• Extension points. Prefer publishing config and overriding via the plugin’s fluent API rather than editing vendor files. If the package exposes custom pages or widgets, keep local overrides in app/Filament and document them for your team.
• Production safety. Consider disabling destructive actions (delete, disable) in production via authorization or a config flag, and keep an audit trail of who changed schedules.