Cron Jobs
Database cleanup, report generation, cache warming, sending that weekly email nobody reads. Scheduled tasks run as Kubernetes CronJobs in Lucity.
Add a Cron Job
Define a cron job under cronJobs in your project's values.yaml:
cronJobs:
cleanup:
schedule: "0 3 * * *"
image:
repository: registry.example.com/myapp/api
tag: latest
command: ["/bin/sh", "-c", "cleanup.sh"]
resources:
requests:
cpu: 50m
memory: 64Mi
limits:
cpu: 200m
memory: 128Mi
This runs cleanup.sh every day at 3 AM. The image is typically the same one your service uses, so your cleanup script is already baked in.
Configuration Options
| Option | Description | Example |
|---|---|---|
schedule | Standard cron expression (minute, hour, day, month, weekday). | "0 3 * * *" |
image | Container image to run. Usually the same image as your service. | { repository: ..., tag: latest } |
command | Entrypoint command. | ["/bin/sh", "-c", "cleanup.sh"] |
args | Arguments passed to the command. | ["--dry-run"] |
resources | CPU and memory requests/limits. | See example above. |
Common Schedules
| Schedule | Meaning |
|---|---|
"*/15 * * * *" | Every 15 minutes |
"0 * * * *" | Every hour |
"0 3 * * *" | Daily at 3 AM |
"0 0 * * 0" | Weekly on Sunday at midnight |
"0 0 1 * *" | First day of every month |
If cron syntax makes your eyes glaze over, crontab.guru is your friend.
How It Works
Kubernetes creates a Job on the specified schedule. The Job spins up a container with your image, runs your command, and exits. Completed jobs are retained for inspection (Kubernetes tracks success and failure history), and failed runs are visible in the dashboard and via kubectl.
Each run is independent: a new pod, a fresh container. No leftover state between executions.
What Happens on Eject
You get a standard Kubernetes CronJob manifest. It works on any Kubernetes cluster without modification. kubectl get cronjobs shows your schedules, kubectl get jobs shows execution history. The same tools you'd use with or without Lucity.