Getting Started

Schedule cron jobs

5 min readUpdated April 2026

Cron services in StackBlaze run on a schedule you define. They are one-shot containers that spin up, run your command, and exit, not long-running servers. Under the hood StackBlaze creates a Kubernetes CronJob resource that the kube-controller-manager fires on your chosen schedule, spinning up a Job (and therefore a Pod) each time.

Because each run is a fresh container, cron jobs are stateless by design. Any state that needs to persist between runs, counters, cursors, processed-record IDs, should live in a database or object storage, not in the container filesystem.

Cron syntax cheat sheet

cron expression reference

# ┌────── minute (0-59)

# │ ┌──── hour (0-23)

# │ │ ┌── day of month (1-31)

# │ │ │ ┌─ month (1-12)

# │ │ │ │ ┌ weekday (0-6, Sun=0)

# │ │ │ │ │

0 2 * * * # daily at 02:00 UTC, DB cleanup

0 9 * * 1 # weekly Mon 09:00 UTC, report email

*/15 * * * * # every 15 minutes, queue sweep

0 * * * * # top of every hour, cache warm

30 23 L * * # last day of month at 23:30

Example run commands

run commands

# Daily database cleanup (Node.js)

node scripts/daily-cleanup.js

# Weekly report email (Python/Django)

python manage.py send_weekly_report

# Queue sweep every 5 min (Bun)

bun run src/jobs/sweep-queue.ts

How a cron job runs

firescreates Jobexit 0
Cron Schedule

0 2 * * *

daily 02:00 UTC

CronJob Controller

kube-controller

Forbid overlap

Pod (one-shot)

runs command

then exits

Log Aggregator

stdout captured

retention 30 d

Under the hood

StackBlaze creates a Kubernetes CronJob resource in your project namespace. A few things worth knowing:

  • concurrencyPolicy: Forbid: if a previous run is still in progress when the next trigger fires, the new run is skipped. This prevents runaway parallel jobs from overwhelming your database.
  • successfulJobsHistoryLimit: 3: only the last three successful runs are retained in the cluster. Older runs are pruned automatically to prevent etcd bloat.
  • CRON_TZ environment variable: set this to any IANA timezone string (e.g. America/New_York) and the CronJob schedule is interpreted in that timezone instead of UTC.
  • Log streaming: container stdout/stderr is shipped to the StackBlaze log aggregator in real time. Logs are available in the dashboard for 30 days after each run, even after the Pod is deleted.

Step by step

01

Create a new service and choose Cron Job

In the StackBlaze dashboard click "Add Service" and select the "Cron Job" type. Unlike web services, cron jobs are never assigned a public URL, they run on a schedule, complete their task, and exit cleanly.

02

Connect your repo and set the build command

Pick a GitHub repository (or reuse the same repo as an existing service). Set your build command, for example "npm ci && npm run build". StackBlaze builds a Docker image on every deploy and stores it in the internal registry.

03

Set the schedule using standard cron syntax

Enter a cron expression in the Schedule field. StackBlaze accepts the standard five-field POSIX cron syntax. Timezone is UTC by default; set CRON_TZ in your environment variables to override (e.g. CRON_TZ=America/New_York).

04

Set the run command

The run command is executed inside the container each time the job fires. For example: "node scripts/daily-report.js" or "python manage.py clearsessions". Keep it focused, one job, one responsibility.

05

View run history and logs in the dashboard

Every execution appears in the Runs tab with status (Succeeded / Failed), start time, duration, and exit code. Click any run to stream the full container logs. Failed runs send a notification to your configured alert channels.