Queue workers (Plesk Scheduled Tasks)
This is the recommended setup for the current ParcelPilot production deployment on Plesk.
Use Plesk Scheduled Tasks to start short-lived queue:work --stop-when-empty workers on the required cron cadence for each queue.
This guide is designed to match the current production setup:
QUEUE_CONNECTION=database- recurring Scheduled Tasks instead of long-running
systemdunits - keep the existing
defaultworker memory limit unchanged - add a dedicated
dispatch-snapshotsworker with a higher timeout andmemory_limit=512M
1) Confirm the exact worker commands
In Plesk, open the domain's Scheduled Tasks and confirm the active worker commands.
The current production pattern is a cron-scheduled worker per queue.
Required commands:
- default queue worker, unchanged:
/opt/plesk/php/8.3/bin/php /var/www/vhosts/parcelpilot.co.uk/httpdocs/3pl/artisan queue:work --stop-when-empty --sleep=2 --tries=1 --timeout=120
- dedicated Morning Board dispatch snapshot worker:
/opt/plesk/php/8.3/bin/php -d memory_limit=512M /var/www/vhosts/parcelpilot.co.uk/httpdocs/3pl/artisan queue:work database --queue=dispatch-snapshots --stop-when-empty --sleep=2 --tries=1 --timeout=300 >> /var/www/vhosts/parcelpilot.co.uk/logs/cron-dispatch-snapshots.log 2>&1
Do not add -d memory_limit=512M to the existing default worker unless another queue independently proves it needs more memory.
For the default worker, use worker recycling as defence in depth for long-running CLI state retention. A safe baseline is to add either --max-jobs=100 or --max-time=900 and keep Laravel's normal --memory guard enabled. Recycling is not a substitute for fixing a high-retention job, but it reduces the chance that a hot worker starts the next job near its memory ceiling.
2) Add the dedicated dispatch snapshot Scheduled Task
Create or update a Plesk Scheduled Task with these settings:
- Type:
Run a command - Schedule: every 5 minutes (
*/5 * * * *) - Command:
/opt/plesk/php/8.3/bin/php -d memory_limit=512M /var/www/vhosts/parcelpilot.co.uk/httpdocs/3pl/artisan queue:work database --queue=dispatch-snapshots --stop-when-empty --sleep=2 --tries=1 --timeout=300 >> /var/www/vhosts/parcelpilot.co.uk/logs/cron-dispatch-snapshots.log 2>&1
Why this command differs from default:
RefreshMorningBoardDispatchSnapshotJobalready routes onto thedispatch-snapshotsqueue- tenant-family refresh now completes successfully with
memory_limit=512M - the dedicated worker keeps the default queue worker unchanged at its current 120-second timeout and default memory limit
--timeout=300gives headroom above the job's 240-second budget without changing application logic
3) Keep the existing default worker unchanged
The existing default queue Scheduled Task should remain as-is:
/opt/plesk/php/8.3/bin/php /var/www/vhosts/parcelpilot.co.uk/httpdocs/3pl/artisan queue:work --stop-when-empty --sleep=2 --tries=1 --timeout=120 --max-jobs=100
Do not raise its memory limit as part of the Morning Board fix.
4) Optional imports worker note
If production also uses Scheduled Tasks for other queues, keep them separate by queue and size their timeout/memory to the job family they serve. Do not fold dispatch-snapshots back into default.
5) Verify the dispatch snapshot worker
After adding the Scheduled Task:
- run
php artisan morning-board:refresh-dispatch-snapshots --forceonce if you need to prime the queue after deployment - confirm new
dispatch-snapshotsjobs disappear from the queue after the next scheduled run - inspect
/var/www/vhosts/parcelpilot.co.uk/logs/cron-dispatch-snapshots.logfor worker output - confirm tenant-family snapshot rows advance
last_attempted_at,last_completed_at, andgenerated_at
6) Troubleshooting
Common issues:
- Jobs remain queued on
dispatch-snapshots: the Scheduled Task is missing, disabled, or not running every 5 minutes. - Worker still times out: confirm the exact command includes
--queue=dispatch-snapshotsand--timeout=300. - Worker hits memory exhaustion: confirm the command includes
-d memory_limit=512M. - No log output: confirm the log path is writable by the Plesk subscription user.
7) Deploy workflow note
After deploys:
- keep the default Scheduled Task unchanged
- keep the dedicated
dispatch-snapshotsScheduled Task enabled - use
php artisan queue:restartif you need currently running workers to pick up new code before the next scheduled dispatch-snapshots run
8) Confirm in-app heartbeats
If your System Status page includes the queue worker heartbeat widget, it should change to “recent/OK” shortly after the Scheduled Task starts succeeding.