- How does this package differ from Laravel’s built-in `schedule:run` command?
- Unlike `schedule:run`, which relies on queue workers for async tasks, this package directly supervises cron-triggered processes (e.g., CLI commands) with retry logic and failure tracking. It’s designed for systems where queues aren’t available or overkill, offering granular control over process execution and concurrency.
- Can I use this to replace existing cron jobs in production?
- Yes, but test thoroughly first. Replace one or two low-criticality cron jobs with the supervisor, validate logging and retries, then incrementally migrate. Update your server’s cron to call `php artisan cronjob:run` instead of direct commands. Monitor logs for issues during rollout.
- What happens if a job fails repeatedly? Does it alert me?
- The package tracks job execution state and emits events (e.g., `JobFailed`) when failures occur. You can hook these events to trigger alerts (Slack, PagerDuty) via Laravel’s event system. Configure retry limits in the supervisor’s config to balance resilience and manual intervention.
- Is this package compatible with Laravel 9/10, or only 8.x?
- The package explicitly requires Laravel 8.x, but the lightweight design suggests compatibility with 9/10 if you test the service provider and event bindings. Check the GitHub repo for updates or fork the package to adapt to newer Laravel versions if needed.
- How does concurrency control work? Can I limit the number of parallel jobs?
- The supervisor enforces concurrency limits by tracking active process IDs (PIDs) via `ps`, `tasklist`, or `flock`. In your config, set a max concurrent processes value (e.g., `4`) for each job. If a job exceeds its runtime (e.g., 29 seconds in your example), new instances won’t spawn until slots free up.
- Does this integrate with Laravel monitoring tools like Horizon or Sentry?
- Not natively, but you can extend it. Use the `JobFailed` event to log failures to Sentry or push metrics to Prometheus. For Horizon, consider wrapping the supervisor in a custom queue worker if you later adopt queues. The package’s event system makes custom integrations straightforward.
- What’s the fallback if `ps` or `tasklist` fails (e.g., on unsupported systems)?
- The package defaults to `flock`, a cross-platform file-locking mechanism, to check process status. While less precise than PID checks, it ensures basic supervision works everywhere. For critical systems, test `flock` reliability in your environment or add custom process-check logic.
- How do I test this locally before deploying to production?
- Run `php artisan cronjob:run` manually to simulate the minutely cronjob. Mock process failures (e.g., with `sleep 61` to exceed timeouts) and verify retries, logging, and events. Use Laravel’s `Artisan::call()` in tests to validate command execution without hitting the server.
- Are there alternatives like this for Laravel? Why choose this package?
- Alternatives include `spatie/scheduled-task` (for queue-based scheduling) or custom scripts with `flock`. This package stands out for its **cron-centric supervision** (not queue-dependent) and built-in concurrency control. Choose it if you need lightweight process tracking without daemon dependencies or complex async workflows.
- What’s the risk of using a package with few stars or recent releases?
- Low-star packages may lack community support or documented edge cases (e.g., concurrent job conflicts). Mitigate risks by: 1) reviewing the codebase for robustness, 2) testing retry logic and failure paths, and 3) having fallback cron entries during migration. Monitor GitHub for updates or fork if needed.