Confirm cron access, the correct CLI PHP path and your application timezone. Review each scheduled task for its resource use, overlapping execution and effect on customer data.

1. Define a small test schedule in the supported location for your Laravel version. Give it a harmless, observable outcome such as writing a specific private log message.

2. Use the panel scheduled-task feature to invoke php artisan schedule:run from the full project directory at the interval Laravel requires. Use an absolute PHP path when the server offers multiple runtimes.

3. Capture errors in a private log while testing. An incorrect working directory or CLI PHP version can fail even when the website itself runs normally.

4. Use the framework overlap and single-server controls where suitable. Their locks require a working cache backend and, for multiple servers, an appropriate shared store.

5. Remove the temporary test task, enable the real schedule and document the expected execution times. Review behavior around timezone and daylight-saving changes.

After confirming the actual PHP path and private log directory, a typical Laravel scheduler entry looks like this. Replace the paths with those assigned to your service and run the corresponding command manually in the same account before enabling the schedule.

* * * * * cd /home/ACCOUNT/apps/portal && /usr/bin/php artisan schedule:run >> /home/ACCOUNT/private/scheduler.log 2>&1

Use php artisan schedule:list from the application directory to inspect due times. The one-minute cron entry evaluates schedules; it does not mean every application task must run each minute. Choose supported overlap protection for long tasks and keep the scheduler’s environment consistent with the web application.

Expected result: A harmless scheduled staging task records the expected time and completes without duplicate runs. The private log captures a wrong interpreter or missing dependency during setup, instead of discarding all errors before the scheduler is verified.

Use the schedule listing command and check actual execution timestamps. Confirm a long task does not create multiple competing copies on successive cron runs.

If nothing runs, test the same command as the same account with the same environment. Check quota, execution permissions and log paths before changing the schedule frequency.

• Setting up a Laravel queue worker
• Using environment variables consistently across web and CLI
• Scheduling application jobs without overlapping runs
• Checking Laravel health without exposing private data

• Laravel task scheduling