Cron Jobs for a PHP Script

Cron is what runs without a browser. Mail queues, expired VIP removal, counter recalculation, temporary-file cleanup. Without cron the site may open, but some features quietly die: notifications do not arrive, VIP never expires.

The script package usually says which URL or PHP file to call and how often. Below is how to configure it on shared hosting and VDS so it actually runs.

What is usually scheduled

• Email and notification queue: every minute or every 5 minutes.
• Expiration of paid services and publications.
• Cleanup of cache, old sessions, temporary uploads.
• Exchange rates or quote imports if the product supports them.
• Sitemap or service recalculations at night.

Do not run a heavy full recalculation every minute "just in case". Load grows and benefit is small.

Path to PHP

Cron needs the CLI binary, not "the site opened in the browser". On shared hosting the path is often:

/usr/bin/php
/opt/php82/bin/php
/usr/local/bin/php

Check Beget/Timeweb/ISPmanager help for the selected version. Important: CLI must be the same 8.x branch as the website. Otherwise web runs on 8.2 while cron runs on 7.4, and Parse error appears only in the cron log.

Check:

/usr/bin/php -v
/usr/bin/php /path/to/cron.php

Job format

Classic form:

*/5 * * * * /usr/bin/php /var/www/site/cron/queue.php >> /var/log/site-cron.log 2>&1

Or call through wget/curl if the script expects HTTP:

*/5 * * * * curl -fsS https://example.com/cron/secret-key >/dev/null

A secret in the URL or key is required; otherwise bots can call the job themselves. Do not expose the key in public repositories.

Shared panel

In the panel scheduler / Cron, create a line with schedule and command. Sometimes the interface asks only for a URL; then use the HTTP variant from the product manual.

On shared hosting:

• the minimum interval may be 5 minutes, not every minute;
• there is no system crontab access, only a web form;
• cron logs may be awkward to read, so write output to your own file in the home directory.

VDS

Use the site user's crontab or root, preferably the site user:

crontab -e

Task file paths and PHP path must be absolute. Relative paths break in cron because the working directory is not what you expect. Inside PHP scripts, use absolute paths or a correct chdir at the start.

If PHP runs through FPM pools, CLI is still a separate php-cli package. Without it, cron has nothing to start.

How to know cron is alive

1. Add a log entry at the start of the cron script.
2. Run the same command manually from SSH.
3. Check the product effect: email sent, VIP removed.

Silence in the log when "it was added in the panel" usually means a path typo or another user's crontab.

Errors and environment

Cron often lacks the environment variables of an SSH session. PATH is short. That is why the full php path is mandatory. Database errors in cron jobs are the same: 1045, connection refused; see database error.

If the job calls an HTTPS URL, the certificate must be valid or curl -f will fail. About SSL: site SSL.

Load

Do not schedule five heavy tasks for the same minute. Spread them out: queue every 5 minutes, cleanup at night, reports hourly. On a small VDS, parallel php-cli processes can eat RAM along with php-fpm and MySQL.

Environment requirements: PHP/MySQL. Product installation: installation. Monitoring "site alive but cron dead" is separate, though home-page uptime is still useful: monitoring.

Locks and overlapping runs

If a job scheduled every 5 minutes sometimes runs 7 minutes, parallel starts happen. Some scripts tolerate it; others duplicate emails and race the database. Use flock:

*/5 * * * * flock -n /tmp/site-queue.lock /usr/bin/php /var/www/site/cron/queue.php

If the lock cannot be acquired, the iteration is skipped. That is better than two heavy imports at once on 2 GB RAM.

Schedule from a human view

Five jobs at minute :00 create a load spike. Spread them: queue on */5, cleanup on 15 3 * * *, recalculation on 30 * * * *. Shared hosting has stricter process limits; do not copy settings from a powerful VDS.

Cron logs

Write stdout/stderr to a file with rotation. An empty file for two weeks while "the task is added" means another user's crontab or a schedule typo. In a shared panel, check which account owns the job.

SQLSTATE errors in cron logs are handled the same as in web requests: database error. After changing the database password, update config; web and CLI usually use the same file, though separate env setups exist.

HTTP cron and protection

If the product gives a URL like /cron.php?key=..., the key must be long and not dictionary-based. Restrict access by IP in Nginx if cron is called only from localhost:

allow 127.0.0.1; deny all;

for the cron location. Otherwise scanners will find the URL in access.log and hammer it. About Nginx: manual.

Windows and local development

MicroServer has no full Linux cron. For local testing, run the PHP file manually or through Windows Task Scheduler. Configure production schedules on the server. Local stack: MicroServer.

Post-deploy checklist

1. Task list from the product readme.
2. Path to php of the same version as web.
3. Absolute paths.
4. Manual test run.
5. Scheduler writes to log.
6. Old cron disabled after migration: migration.

Task file permissions: chmod. Shared server: VDS, root. If the whole site returns 500, start here: 500 error.

In ISPmanager and similar panels, cron may be enabled through a "URL" checkbox without showing errors. Add your own log inside the PHP task, or you will not see Fatal errors. After changing PHP version in the panel, recheck the cron command: /opt/php74/... may still point to the old binary. Version requirements: PHP/MySQL. Product installation reminds you about cron at the end: installation.