Check that your plan permits the selected queue backend and persistent processes. Obtain the correct project path, queue names and process-management method. Ordinary cron access alone is not the same as a supervised worker.

1. Choose a supported queue connection and configure its credentials privately. Create the required queue or failed-job storage using the procedure for your application version.

2. Submit a harmless test job that produces an observable result. Confirm it is queued rather than unexpectedly running synchronously in the web request.

3. Start a worker as the hosting account user through the approved supervisor. Set the required queue names, memory limit, job timeout and retry behavior deliberately.

4. Coordinate the worker timeout with the backend retry or visibility timing so a job is not unnecessarily processed twice. Design payment, mail and provisioning jobs to tolerate retries.

5. Configure the supervisor to replace workers after a deployment or unexpected exit. Monitor failed jobs and queue delay, not only whether a process exists.

On a protected staging application with the database queue connection already configured, place one harmless log-only job on a dedicated kb-test queue. Confirm no real customer notifications or provisioning work share that queue before running the worker.

php artisan queue:work database \
  --queue=kb-test --stop-when-empty --tries=1 --timeout=30

The worker processes that named queue and exits when it becomes empty. For this test, the backend retry timing must exceed the 30-second worker timeout by a suitable margin. Inspect the job result and private log rather than assuming an empty queue means successful completion. Failed jobs need their own review.

Expected result: The test job runs once and produces the expected log entry. This proves the queue connection and worker environment before you configure a durable supervised production worker with the application’s real retry and idempotency policies.

Submit another job, observe it leave the pending queue and verify its real outcome. Restart the application through the supported method and confirm the worker returns.

If jobs accumulate, compare the worker connection and queue names with the producer configuration. Review the failed-job record and application log before repeatedly retrying an operation with external effects.

• Refreshing Laravel configuration after environment changes
• Scheduling Laravel tasks through cron
• Using a queue for slow exports and notifications
• Checking Laravel health without exposing private data

• Laravel queues
• Laravel deployment