Schedule Jobs with Cron
Run a command on a schedule inside your container — including one that sleeps between visits.
The Cron tab on any container runs a command on a schedule: a nightly database dump, a health check every five minutes, log rotation on Sundays. Anything you would put in a crontab.
SparkCloud keeps the timetable rather than a crontab inside the box. That is worth knowing because of what it buys you: the schedule survives restarts, hibernation and node moves, you get a run history with the command's output, and — the important one — jobs still run on a dynamic container that is asleep.
Creating a job
- Open your container, go to the Cron tab, and click New Job.
- Give it a name and pick a schedule — the presets cover most cases, or write a standard five-field cron expression.
- Check the preview: it shows the next few times the job will actually run, in the timezone you chose. This is the fastest way to catch a schedule that does not mean what you assumed.
- Enter the command. It runs through /bin/sh inside the container as root, and multiple lines are fine.
- Save. The job starts running on its own from the next matching time.
# a nightly backup, at 03:00
pg_dump -U postgres mydb | gzip > /backups/db-$(date +%F).sql.gz
find /backups -name "db-*.sql.gz" -mtime +7 -delete Dynamic containers
A dynamic container sleeps when nobody is visiting, which would normally mean a scheduled job never fires. Here it does: when a job comes due, SparkCloud wakes the container, runs the command, and puts it straight back to sleep.
- You pay for the seconds the job actually takes, not for staying awake between runs.
- "Wake it to run this job" is on by default. Turn it off and the job is skipped whenever the container happens to be asleep — recorded as skipped, so you can see it happened.
- "Put it back to sleep afterwards" is also on by default. Turn it off if your job starts something that should keep running in the background, otherwise it gets stopped along with the container.
- If a visitor arrives while the job is running, the container stays awake — you will not be logged out mid-request.
Watching a job
Every run is recorded with its exit code, how long it took, and the combined output of the command. Click History on a job to read them. "Run now" executes immediately without waiting for the schedule — the quickest way to check a new job does what you meant before you leave it alone.
If a job starts failing you get one notification, and no more until it succeeds again — a job that breaks every night at 3am should not become a nightly alarm.