Filament Plugin Schedule Monitor Laravel Package

Technical Evaluation

Architecture Fit

• Leverages Spatie’s Schedule Monitor: The package integrates seamlessly with Spatie’s laravel-schedule-monitor, a battle-tested solution for tracking Laravel scheduled jobs (commands, queues, events). This ensures alignment with Laravel’s core scheduling ecosystem.
• Filament v3 Plugin: Designed as a Filament plugin, it fits neatly into Filament’s modular architecture, allowing for clean UI integration without polluting the main application codebase.
• Observability-First: Enhances visibility into job execution (success/failure, duration, retries) via a dedicated Filament panel, addressing a critical gap in Laravel’s native scheduling tools.

Integration Feasibility

• Low Coupling: The plugin is self-contained, requiring only:
  • Spatie’s laravel-schedule-monitor (for data collection).
  • Filament v3 (for UI rendering).
• Minimal Boilerplate: Installation involves:
  1. Installing dependencies (spatie/laravel-schedule-monitor + plugin).
  2. Publishing migrations/config (optional).
  3. Registering the plugin in AdminPanelProvider.
• No Core Laravel Modifications: Operates as a layer on top of existing systems, reducing risk of conflicts.

Technical Risk

• Dependency on Filament v3: Hard requirement for Filament v3 may limit adoption in legacy Filament v2 projects or non-Filament applications. Mitigation: Assess Filament version alignment early.
• Spatie Monitor Overhead: The underlying laravel-schedule-monitor adds database writes and query overhead. Mitigation: Evaluate performance impact in staging (e.g., high-frequency jobs).
• Plugin Maturity: Low GitHub stars (15) and no dependents suggest limited real-world testing. Mitigation: Review Spatie’s monitor (1.5K stars) for stability proxies.
• Customization Limits: Plugin may lack hooks for deep UI/UX tweaks. Mitigation: Check if Filament’s plugin system allows overrides (e.g., via modify methods).

Key Questions

1. Filament Version: Is the team using Filament v3? If not, what’s the upgrade path?
2. Monitoring Scope: Are all critical jobs tagged for monitoring? (Spatie’s monitor requires explicit job tagging.)
3. Performance: How many jobs run hourly/daily? Could monitoring queries impact DB load?
4. Alerting: Does the team need alerts (e.g., Slack) for failed jobs? This plugin is UI-only.
5. Retention: How long should job logs be stored? (Configurable via Spatie’s monitor.)
6. Permissions: Should access to the monitor be role-restricted in Filament?

Integration Approach

Stack Fit

• Laravel + Filament v3: Native fit; no architectural conflicts.
• Database: Requires MySQL/PostgreSQL/SQLite (Spatie’s monitor dependency). Ensure the DB supports the schema.
• Queue Drivers: Works with all Laravel queue drivers (database, Redis, etc.), but monitoring accuracy depends on driver reliability.
• Deployment: Stateless plugin; no changes to deployment pipelines needed beyond dependency installation.

Migration Path

1. Pre-Installation:
   • Audit existing scheduled jobs to ensure they’re tagged for monitoring (Spatie’s monitor requirement).
   • Verify Filament v3 compatibility (check filament/filament version).
2. Installation:

   composer require spatie/laravel-schedule-monitor
   php artisan vendor:publish --provider="Spatie\ScheduleMonitor\ScheduleMonitorServiceProvider" --tag="schedule-monitor-migrations"
   php artisan migrate
   composer require mvenghaus/filament-plugin-schedule-monitor:"^3.0"
   

3. Configuration:
   • Register the plugin in app/Providers/Filament/AdminPanelProvider.php:

     ->plugin(\Mvenghaus\FilamentScheduleMonitor\FilamentPlugin::make())
     

   • Publish config (optional) for customization:

     php artisan vendor:publish --tag="filament-schedule-monitor-config"
     

4. Post-Installation:
   • Test job monitoring in staging (verify logs appear in Filament).
   • Set up job tags for untracked jobs (if needed).

Compatibility

• Filament Plugins: Follows Filament’s plugin system, so it coexists with other plugins (e.g., notifications, settings).
• Laravel Versions: Compatible with Laravel 9/10 (check Spatie’s monitor for LTS support).
• Customization: Limited but possible via:
  • Overriding plugin views (Filament’s resource views).
  • Extending Spatie’s monitor config (e.g., config/schedule-monitor.php).

Sequencing

1. Phase 1: Install and configure Spatie’s monitor (data layer).
2. Phase 2: Integrate the Filament plugin (UI layer).
3. Phase 3: Validate with a subset of jobs, then expand.
4. Phase 4: (Optional) Add alerts or integrations (e.g., webhooks for failures).

Operational Impact

Maintenance

• Dependencies:
  • Spatie’s monitor (actively maintained; ~10 releases/year).
  • Plugin (less frequent updates; monitor for Filament v3 compatibility).
• Updates:
  • Minor updates: Run composer update and test Filament panel.
  • Major updates: Check changelogs for breaking changes (e.g., Filament v3.x → v4.0).
• Backups: Monitor migrations are schema-only; no data loss risk, but back up DB pre-migration.

Support

• Troubleshooting:
  • Jobs Not Appearing: Verify jobs are tagged ($schedule->command(Command::class)->tag('monitored')).
  • Performance Issues: Check Spatie’s monitor queries (EXPLAIN ANALYZE on schedule_jobs table).
  • UI Bugs: Report to plugin’s GitHub issues (low activity; expect community-driven fixes).
• Documentation: Minimal but sufficient for basic setup. Spatie’s monitor docs cover advanced use cases.

Scaling

• High-Volume Jobs:
  • Database: Monitor table growth; archive old logs via Spatie’s prune command.
  • Queries: Index schedule_jobs table on created_at and job columns if slow.
• Multi-Tenancy: Spatie’s monitor is tenant-agnostic; Filament access can be scoped via Filament’s policies.
• Horizontal Scaling: Stateless plugin; no changes needed for Laravel Forge/Forge scaling.

Failure Modes

Ramp-Up

• Onboarding Time: 1–2 hours for installation; 0.5–1 hour for configuration.
• Training:
  • Developers: Teach job tagging and Filament plugin registration.
  • Ops: Explain monitoring data interpretation (e.g., "failed" vs. "timed out").
• Key Metrics to Track Post-Deployment:
  • % of jobs monitored (coverage).
  • False positives/negatives in failure detection.
  • DB query performance (e.g., schedule_jobs query times).