Cron Jobs & Scheduled Tasks

Running scheduled tasks with standard crontab works fine for a single server. At scale, it becomes a liability. If you have a fleet of 20 identical application servers and you define a crontab entry on all of them to process daily reports, all 20 will execute simultaneously — corrupting your data, hammering your database, and generating duplicate outputs.

RasnuOS lifts cron scheduling entirely out of the individual servers and into the Control Plane, giving you fleet-aware, guaranteed execution with complete visibility.

Defining a Scheduled Task

You define your scheduled tasks directly in the RasnuOS dashboard. The configuration is simple:

• Command: The exact command to execute on the server (e.g., python /app/scripts/daily-report.py, node /app/workers/cleanup.js, ./bin/process-queue, or any binary or script on your server).
• Schedule: A standard cron expression (e.g., 0 2 * * * for 2:00 AM daily).
• Target: The Server Group this task is assigned to.
• Execution Mode: Either run on all nodes simultaneously (e.g., for cache-warming tasks) or run on exactly one elected node (see below).

Singleton Execution (Distributed Mutex)

For tasks that must only run once across the entire fleet — such as database migrations, billing scripts, or report generators — RasnuOS provides a Singleton Execution mode.

When Singleton mode is active, the Control Plane performs a leader election at the scheduled time. It selects exactly one healthy server from the group to receive the execution intent. The other servers in the group are not contacted at all.

If the elected leader goes offline in the seconds before execution, the Control Plane automatically re-elects a different healthy node and proceeds. The task is guaranteed to run once and only once, even in the presence of infrastructure failures.

Execution Logs & History

Every scheduled task execution is logged permanently. You can see:

• Whether the task succeeded or failed.
• The exit code returned by the process.
• The full stdout and stderr output.
• The exact server that ran the task (in Singleton mode).
• The precise start and end timestamps.

This gives your team a complete, auditable history of all automated work happening across your infrastructure, without having to SSH into servers to parse log files manually.