- Does this package work with Filament v3, v4, or v5?
- Yes, but version compatibility is strict. Use `croustibat/filament-jobs-monitor:4.x` for Filament v5, `3.x` for v4, and `2.x` for v3. Check the [version matrix](https://github.com/ultraviolettes/filament-jobs-monitor#installation) before installing. Upgrades between major versions may require manual adjustments.
- Can I monitor jobs across multiple queue drivers (Redis, database, sync)?
- Absolutely. The package supports all Laravel queue drivers out of the box. However, you must manually define your queues in the config file (`queues` array) since Laravel lacks a universal way to discover them dynamically.
- How do I enable multi-tenancy support for job monitoring?
- Set `tenancy.enabled = true` in the config and define a `tenant_id` column in your jobs. The package extracts tenant IDs from job payloads automatically. If jobs lack this property, monitoring will skip tenant filtering. Enforce job standards via CI checks or documentation.
- Will this work with my existing Filament admin panel without breaking anything?
- Yes, it integrates as a Filament plugin and won’t disrupt your existing setup. The resource appears under your Filament navigation (configurable via `navigation_group`). No architectural changes are required—just install, publish migrations, and configure queues.
- How do I handle large queues or old jobs to avoid database bloat?
- Enable pruning by setting `pruning.enabled = true` in the config. Default retention is 7 days, but you can adjust `retention_days`. Monitor the `queue_monitors` table growth and consider adding database indexes if performance degrades under heavy load.
- Can I customize the UI (e.g., add columns, change actions) or extend functionality?
- Basic customization is possible via the published config (e.g., labels, icons). For deeper changes, extend the `QueueMonitorResource` or override Filament’s resource methods. The package doesn’t expose a public API for column overrides, so manual model extensions may be needed.
- What happens if my jobs contain non-serializable data (e.g., closures) or custom payloads?
- The package relies on Laravel’s job payload serialization. If jobs include non-serializable data (like closures), monitoring may fail silently for those jobs. Validate job payloads during development and avoid non-serializable data. Use `try-catch` blocks in job handlers if needed.
- Is real-time monitoring supported, or is this polling-based?
- This is a polling-based UI, not real-time. Failed jobs are checked every `polling_interval` (default: 10 seconds). For real-time updates, consider pairing this with Laravel Echo or a dedicated queue monitoring service like Horizon.
- Do I need Redis for this package, or does it work with database queues?
- No Redis dependency is required. The package works with all queue drivers, including database queues. However, payload inspection (e.g., for tenant IDs) relies on serialized job data stored in the database or Redis, so ensure your jobs are properly serializable.
- Are there alternatives to this package if I need Horizon-like features (e.g., job throttling, supervisor integration)?
- For advanced features like job throttling or supervisor integration, Laravel Horizon is the gold standard. This package focuses on a lightweight, Filament-compatible UI for monitoring jobs across all drivers. If you need Horizon’s full feature set, stick with it—but this is a great alternative for Filament users.