Scheduled tasks and cron

The Schedules tab runs commands on a cron expression. It is the panel's answer to “do this every night” — git pulls, restarts, backups, deploys.

Creating a schedule

New schedule, choose a frequency, and give it a command. Commands run in the container with the same user and working directory as your application.

A git pull that updates your code is the most common first task:

cd /home/container/repo && git pull --ff-only && npm ci --omit=dev

Three details matter here:

• --ff-only makes the pull fail rather than create a merge commit if local changes conflict. A cron task that silently merges will eventually produce a working tree nobody can reason about.
• npm ci instead of npm install installs exactly what the lockfile specifies, so the container matches the repository.
• The install must succeed before anything restarts, which is why the restart belongs in a separate task or at the end of a chained command.

Restart after updating, not before — restarting first means the container runs new code against old dependencies for the duration of the install.

The execution time limit

Scheduled tasks have a maximum runtime. A task killed partway through stops mid-operation, and for a git pull that can leave the working tree in a state that is neither the old commit nor the new one.

Keep tasks short. A pull and install should take seconds. If something takes minutes — a large install, a build — it is a deployment, not a scheduled task, and it belongs in a script you run deliberately.

Common uses

# Daily dependency refresh — catches upstream releases
cd /home/container/repo && git pull --ff-only

# Nightly restart — clears accumulated memory pressure
# (only worth doing if you have not fixed the underlying growth)

# Periodic health check that logs to the console
curl -fsS http://127.0.0.1:3000/healthz || echo "health check failed"

Be honest about scheduled restarts. They hide a memory leak rather than fixing one, and they produce a brief interruption every time. If a service needs a daily restart to stay alive, the fix is a leak fix or a plan with more memory — see Performance and memory tuning.

Logging and failure

Task output is recorded, and it is the only place you will find out that a task has been failing silently for three weeks. Check it after creating anything important.

Make the command report failure explicitly. A cron task that exits zero when it did nothing will never alert you, and “the nightly pull silently stopped eight weeks ago” is a bad morning to discover that.

Timezone

Schedules run on a cron expression in a fixed timezone, so confirm which one before assuming a job fires when you expect. An off-by-a-few-hours backup that you never see in the log is usually a timezone mismatch rather than a task that did not run.