Cron is the scheduler that runs tasks on a server at fixed times. On hosting it handles backups, notification emails, exchange-rate updates and cleanup jobs. The catch is that cron fails silently: the task simply doesn't happen, and you notice days later when the result is missing. So the first rule is simple — send every job's output to a log file, then work through the mistakes below.
Redirect output to a log first
Appending a redirect to the command lets you read what the script said. >> appends to the file and 2>&1 sends error messages there too; without it a PHP fatal error or "command not found" just vanishes.
*/15 * * * * /usr/bin/php /var/www/user/data/www/example.uz/cron/rates.php >> /var/www/user/data/logs/rates.log 2>&11. Relative paths
In a browser the script runs from its own folder, but cron starts it from the user's home directory. Relative paths such as include 'config.php' then point elsewhere and the file is not found. Use PHP's __DIR__ constant, or cd into the folder in the command itself.
*/15 * * * * cd /var/www/user/data/www/example.uz && /usr/bin/php cron/rates.php >> /var/www/user/data/logs/rates.log 2>&12. A minimal PATH
Commands like php, wp or composer that work in your terminal may return "command not found" under cron, because cron starts with a bare environment and doesn't load your shell profile. Always use full paths; which php tells you the right one.
3. The wrong PHP version
Hosting servers often have several PHP versions. Your site may run on PHP 8.2 while a plain php in cron calls an older system binary, so modern syntax fails with "syntax error". Point to the exact binary and check it with /opt/php82/bin/php -v; paths differ between servers, so confirm them in the panel or with support.
4. No execute permission or Windows line endings
A script called directly needs the execute bit. A bash script edited on Windows also keeps CRLF line endings, which Linux rejects with "bad interpreter".
chmod +x /home/user/backup.sh
sed -i 's/\r$//' /home/user/backup.sh5. Unescaped percent signs
In a crontab line % means newline, so date +%Y-%m-%d gets cut into pieces. Escape each one as \%, or move complex commands into a separate script file.
6. Misread schedule
The five fields are minute, hour, day of month, month, day of week. * 3 * * * runs every minute from 3:00 to 3:59, not once at 3 a.m.; you want 0 3 * * *. Also check the server time zone with date — it may not be Tashkent time.
7. Overlapping runs
If a job takes 10 minutes but starts every 5, copies pile up, sending duplicate messages or causing database lock errors. flock skips a run while the previous one is still active:
*/5 * * * * /usr/bin/flock -n /tmp/sms.lock /usr/bin/php /var/www/user/data/www/example.uz/cron/sms.php >> /var/www/user/data/logs/sms.log 2>&18. Memory and time limits
Large exports or backups can hit the plan's memory or CPU limits and die halfway. If the log shows "Allowed memory size exhausted" or "Killed", process the work in batches — say 500 records per run — and schedule heavy jobs at night.
Example: a Tashkent online shop
An appliance shop scheduled a script at 2 a.m. to reprice products by the dollar rate. For a week nothing changed, though the panel showed the job as active. Once output went to a log, it read "Failed opening required 'config.php'" — a relative path. After adding cd, the next night brought "syntax error": cron was using old PHP. A full path fixed it, and both problems were found in ten minutes thanks to the log.
Test under cron-like conditions
Before scheduling, run the script with an almost empty environment to expose PATH and variable issues:
env -i /bin/sh -c 'cd /var/www/user/data/www/example.uz && /usr/bin/php cron/rates.php'On sayt.uz hosting, cron jobs are added in the Scheduler section of the ISPmanager panel, opened from your sayt.uz cabinet. If the log stays empty and the job never seems to start, open a support ticket with the command line so the server-side cron log can be checked.