- How do I install workerman/crontab in a Laravel application?
- Install it with composer require workerman/crontab, which pulls in workerman/workerman as its only dependency. You then start a Workerman worker process, bootstrap Laravel once inside it, and register your jobs against the scheduler before the event loop starts. Because it is not a Laravel package, there is no service provider or config file to publish; the wiring is your own code. Pin at least v1.0.7 if you run PHP 8.4.
- Does workerman/crontab support seconds in cron expressions?
- Yes. Alongside standard five-field cron expressions it accepts an optional leading seconds field, so jobs can fire at sub-minute intervals such as every five seconds. This is the main capability Laravel's own scheduler cannot provide, since that is minute-granularity only.
- Should I use workerman/crontab instead of Laravel's built-in scheduler?
- For a conventional Laravel application, no. The framework scheduler is a functional superset, offering onOneServer, withoutOverlapping, runInBackground, before and after hooks, output capture, schedule:test and schedule:list. workerman/crontab provides scheduling primitives only, with no locking, persistence or failed-job store. Reach for it only when you already run a Workerman process, genuinely need second-level ticks, or have no dependable system cron.
- How do I stop duplicate cron jobs when running multiple Workerman workers?
- The package has no distributed lock or leader election, so every Workerman worker process registers its own copy of the crontab. If the worker count is greater than one, the same job fires once per process simultaneously. The practical mitigation is to run the scheduler in a single dedicated worker with a count of one on a single host, enforced at the deployment level rather than in code.
- Can workerman/crontab run alongside Laravel Octane or PHP-FPM?
- It needs a long-lived Workerman event loop, so it does not run inside PHP-FPM requests or as an Octane worker hook. The usual pattern is a separate supervised daemon next to your web and queue processes. That daemon requires the pcntl and posix extensions and a POSIX host, so Windows only works inside containers.
- Which PHP and Laravel versions does workerman/crontab v1.0.7 support?
- The package is framework-agnostic, so there is no hard Laravel version constraint; bootstrapping Laravel 10, 11 or 12 inside a Workerman worker works if you manage process state correctly. On PHP, v1.0.7 is the minimum usable pin for PHP 8.4 because it fixes runtime errors that broke earlier releases. If you standardise on PHP 8.4 images, treat v1.0.6 and below as non-starters.
- What happens if a scheduled callback is slow or throws an exception?
- Callbacks run on the event loop, so a slow or blocking job delays or skips subsequent ticks. The library has no retry, backoff or failed-task store, and exception behaviour inside a callback depends on Workerman's restart semantics, which you should verify before relying on it. Keep callbacks short and push anything heavy or CPU-bound onto a queue.
- Does workerman/crontab keep run history or retry failed jobs?
- No. There is no persistence layer, no run history and no audit trail, so you cannot inspect or replay missed and failed executions from the package itself. If compliance or incident review requires a record of runs, use the Laravel scheduler with a queue or add your own logging and instrumentation around each callback.
- Can I schedule Artisan commands with workerman/crontab?
- Jobs are plain PHP closures or callables, so you can call Artisan::call or invoke a console command class inside the callback. There is no first-class Artisan scheduling API, and long-running commands should be dispatched to a queue rather than run inline. Wrap the call so failures are logged and reported by your application instead of being lost in the worker.
- Is workerman/crontab actively maintained and safe for production use?
- Adoption is very low, at roughly 71 GitHub stars and no dependents, and the bus factor is effectively one. The mitigating factor is that the maintainer also authors Workerman, making this first-party in practice, and v1.0.7 is a community-contributed compatibility patch, which is a small positive signal. For production-critical scheduling, prefer the Laravel scheduler and keep a fork-or-vendor contingency ready.