Appearance
CronJobs
A Kubernetes CronJob creates jobs on a schedule. Use cronjobs on RemoteGPU for recurring batch work.
Typical examples include nightly data refreshes, periodic evaluation jobs, cleanup tasks, health reports, and scheduled inference preparation work.
Choose a workflow
Use the console when you want to create a scheduled workload quickly or review cronjob, job, pod, log, and event status in a namespace.
Use kubectl when your team manages scheduled work from manifests or CI. Apply full CronJob manifests through the namespace kubeconfig and Kubernetes exec API key auth.
When to use a cronjob
A cronjob is useful for:
- recurring tasks that follow a cron-style schedule
- schedules and job templates managed in version-controlled manifests
- recurring namespace maintenance such as cleanup, sync, or report generation
- workloads where each scheduled run should create a standard Kubernetes job
For one-time execution, use a Job instead.
Supported cronjob profile
| Area | Supported behavior |
|---|---|
| Resource type | batch/v1 CronJob |
| Access path | Console creation, plus kubectl for manifest create and update |
| Schedule format | Standard Kubernetes cron schedule syntax |
| Job template policy | The embedded job template uses the same plan and workload policy rules as other workloads |
| Namespace model | The cronjob and the jobs it creates stay inside the same namespace boundary |
Create a cronjob
Use Kubernetes > CronJobs when you want to launch a straightforward recurring batch workload without writing a manifest first.
The console create flow supports:
- namespace selection
- cronjob name
- plan selection
- container image
- schedule
- optional shell command
Use kubectl when you need manifest fields that are not exposed in the console form, such as concurrency policy, history retention, suspend, starting deadline, labels, annotations, environment variables, volumes, or advanced job template settings. The same namespace workload policy applies either way.
Operating cronjobs on RemoteGPU
- When managed with
kubectl, the job template inside the cronjob should include the RemoteGPU runtime SKU label. - Set
concurrencyPolicyintentionally so overlapping runs do not surprise you. - Set success and failure history limits so completed jobs do not accumulate indefinitely.
- CronJobs are batch resources. They do not replace the deployment-service-ingress model used for public HTTP apps.
What you can do from the console
The console is still useful whether the cronjob was created in the console or with kubectl:
- create the namespace
- create a cronjob from the console form
- download namespace kubeconfig
- review current cronjobs in
Kubernetes > CronJobs - inspect pods, events, and logs created by scheduled runs
- inspect related services or ingresses in the same namespace
Troubleshooting
| Symptom | What to check |
|---|---|
| CronJob does not create jobs | Confirm the schedule is valid Kubernetes cron syntax and the cronjob is not suspended |
| Scheduled jobs fail | Inspect the created job, pod events, and container logs; the job template follows the same rules as a normal Job |
| Runs overlap unexpectedly | Set concurrencyPolicy intentionally, such as Forbid when a new run should wait for the previous one to finish |
| Completed jobs accumulate | Set successfulJobsHistoryLimit and failedJobsHistoryLimit in the cronjob manifest |
| Console-created cronjob needs advanced fields | Use kubectl for fields such as concurrency policy, suspend, starting deadline, history limits, labels, annotations, environment variables, and volumes |
Read next
- Read Jobs for one-off batch work.
- Read Deployments for long-running services.
- Read Kubernetes overview for the full access model.
