Skip to content
English
Customer portal
Contact us
  • There are no suggestions because the search field is empty.

13.03 Cron Jobs Reference

SimpleRisk uses 11 cron scripts under simplerisk/cron/ — a unified entry point (cron.php) plus 10 specialized scripts for notifications, audits, backups, queue processing, vulnerability management, assessments, and cleanup. Some run every few minutes, some hourly, some long-running. This reference catalogs each script's purpose and expected schedule.

Why this is a reference article

This article catalogs SimpleRisk's cron scripts. For the conceptual workflow of running cron, see The Cron Jobs. For troubleshooting cron-related issues, see Troubleshooting Common Issues.

Where the scripts live

All cron scripts are in simplerisk/cron/:

simplerisk/cron/
├── cron.php
├── cron_assessments.php
├── cron_audit.php
├── cron_backup.php
├── cron_notification.php
├── cron_promise_worker.php
├── cron_queue_loader.php
├── cron_queue_worker.php
├── cron_temporary_cleanup.php
├── cron_tfidf_recalculation.php
└── cron_vulnmgmt.php

11 scripts total. Each has a specific responsibility.

The orchestrator

cron.php

The unified entry point. Designed to be invoked by system cron at a regular interval (typically every 5-10 minutes); it then calls the relevant child scripts based on their schedules.

For installs that prefer to invoke each script independently, the child scripts can be called directly from system cron entries.

Typical schedule: every 5-10 minutes via system cron.

Notification and email

cron_notification.php

Processes the queued notifications (the notification_sent_log and related queues). For each pending notification, dispatches via SMTP using the configured mail settings.

Typical schedule: every 5-15 minutes. Faster cadence reduces notification latency; slower cadence reduces SMTP load.

Logs: notice level for successful sends; error for SMTP failures.

Failure mode: queued notifications accumulate without sending; users notice missing email.

Cycle / lifecycle automation

cron_audit.php

Manages compliance audit cycles. Handles cycle initiation, status transitions, audit-cycle-related notifications.

Typical schedule: hourly or daily.

Logs: notice for cycle-state changes; info for routine cycle processing.

cron_assessments.php

Manages assessment cycles (Assessments Extra). Handles assessment dispatch, response collection, completion processing.

Typical schedule: hourly.

Logs: assessment-cycle events.

Background work

cron_queue_worker.php

The general-purpose background job worker. Picks up queued jobs (workflow executions, AI jobs, large data operations) and processes them. Many installs run this continuously rather than on cron schedule; some invoke it from cron.

Typical schedule: continuous (long-running) or every 1-2 minutes from cron.

Logs: per-job pickup and execution; errors on job failure.

Failure mode: queued jobs accumulate; workflows don't fire; AI requests hang.

cron_queue_loader.php

Loads jobs into the queue based on schedule triggers. The loader is what makes scheduled workflows fire — it scans for time-based triggers and queues the corresponding executions.

Typical schedule: every 1-5 minutes.

cron_promise_worker.php

Processes promise-style asynchronous results. Specific to certain async patterns the application uses internally.

Typical schedule: continuous or every minute.

Maintenance

cron_backup.php

Performs scheduled database backups. Configurable in the SimpleRisk admin UI for backup frequency, destination, and retention.

Typical schedule: nightly.

Logs: notice for completed backups; error for backup failures.

Failure mode: backups stop; recovery from incidents becomes more painful.

cron_temporary_cleanup.php

Cleans up temporary files, expired tokens, stale cache entries.

Typical schedule: hourly or daily.

Logs: info for routine cleanup; notice if substantial cleanup occurred.

cron_tfidf_recalculation.php

Recalculates TF-IDF (term frequency / inverse document frequency) indices used by the search and recommendation features. The TF-IDF index becomes stale as documents and risks are added; periodic recalculation keeps search relevant.

Typical schedule: daily or weekly (it's expensive on large installs).

Logs: notice on completion.

cron_vulnmgmt.php

Vulnerability Management Extra processing. Handles vulnerability ingestion, deduplication, risk creation from vulnerabilities.

Typical schedule: hourly or per ingestion source's cadence.

Logs: vulnerability processing events.

Configuring the cron schedule

The cron schedule is typically configured in two places:

System cron (Linux)

A crontab entry invokes cron.php (or specific child scripts):

# Every 5 minutes, run the SimpleRisk orchestrator
*/5 * * * * /usr/bin/php /var/www/simplerisk/cron/cron.php >> /var/log/simplerisk/cron.log 2>&1

For specific scripts:

# Notification processing every 5 minutes
*/5 * * * * /usr/bin/php /var/www/simplerisk/cron/cron_notification.php

# Audit cycle hourly
0 * * * * /usr/bin/php /var/www/simplerisk/cron/cron_audit.php

# Backup nightly at 2 AM
0 2 * * * /usr/bin/php /var/www/simplerisk/cron/cron_backup.php

# TF-IDF weekly on Sunday at 3 AM
0 3 * * 0 /usr/bin/php /var/www/simplerisk/cron/cron_tfidf_recalculation.php

Application-level scheduling

SimpleRisk's admin UI under Configure → Settings → Backups (which despite the page name covers all cron-related schedules) configures the per-task interval expectations. The orchestrator (cron.php) reads these and decides which child scripts to run on each invocation.

For installs running the orchestrator pattern, the system cron just invokes cron.php frequently; the orchestrator handles per-task scheduling.

Continuous workers

Some scripts are designed to run continuously rather than on cron schedule:

  • cron_queue_worker.php — typically run as a long-running process via systemd, supervisord, or Docker container. Restarts on failure; processes jobs as they arrive.
  • cron_promise_worker.php — same pattern.

For continuous workers, monitor process health (process running, memory growth, restart count); systemd's standard service management handles most of this.

Verifying cron is working

# Check the cron history table
mysql -u simplerisk -p simplerisk -e "SELECT * FROM cron_history ORDER BY started_at DESC LIMIT 20;"

# Check the debug log for cron-related entries
mysql -u simplerisk -p simplerisk -e "SELECT timestamp, log_message FROM debug_log WHERE log_message LIKE '%cron%' ORDER BY timestamp DESC LIMIT 50;"

# Check the system cron is running (Linux)
systemctl status cron

# Check the SimpleRisk cron log file
tail -50 /var/log/simplerisk/cron.log

If cron_history shows no recent runs, the cron isn't actually running — check the system cron, the user invoking the cron, and the script's permissions.

Common pitfalls

A handful of patterns recur with cron jobs.

  • Multi-server deployments running cron on every server. Duplicate execution of notifications, AI jobs, backups. Pick one cron host.

  • Wrong cron schedule. A 60-minute notification cron means notifications can be 60 minutes late. Match cadence to operational requirements.

  • Cron user lacks permissions. The cron-user must be able to read/write the SimpleRisk directory and connect to the database.

  • PHP CLI version mismatch. The web server may use PHP 8.3 while system cron defaults to PHP 7.4. Specify the PHP version explicitly: /usr/bin/php8.3 instead of /usr/bin/php.

  • Long-running scripts conflicting with the cron schedule. A cron_backup.php that runs for 90 minutes overlaps with the next nightly invocation. Use file locks or check for in-progress execution.

  • Not redirecting stdout/stderr. Cron-failure output goes to email by default; without redirection, it spams the operator. >> log_file 2>&1 solves this.

  • Not monitoring cron failures. Silent cron failures produce silent feature degradation. Alert on cron_history gaps and error-level cron log entries.

  • Disabling cron during maintenance and forgetting to re-enable. Backup jobs stop; notifications stop; queues fill. Restore the cron after maintenance.

  • Running cron_queue_worker from cron without locking. Multiple instances racing for the same job. Use a single continuous worker or proper locking.

Related