Introduction

If you want a Kubernetes CronJob to run right now, the usual solution is not to wait for the next schedule. Instead, create a one-off Job from the CronJob template. That gives you the same pod spec immediately without modifying the CronJob schedule itself.

The standard command: create a Job from the CronJob

Kubernetes supports this directly:

kubectl create job --from=cronjob/nightly-report nightly-report-manual

That command copies the jobTemplate from the CronJob named nightly-report and creates a normal Job called nightly-report-manual.

The original CronJob keeps its schedule and will still run later according to its cron expression. The manual run is just an extra one-off execution.

If you need a unique name, add a timestamp:

kubectl create job --from=cronjob/nightly-report nightly-report-manual-20260311

This is the cleanest method for testing, emergency runs, and debugging.

Confirm the one-off job actually started

After creating the job, inspect it like any other Kubernetes job:

1kubectl get jobs
2kubectl describe job nightly-report-manual
3kubectl get pods --selector=job-name=nightly-report-manual
4kubectl logs job/nightly-report-manual

Those commands tell you whether the pod was created, whether it is failing image pulls or environment setup, and whether the container completed successfully.

Why this is better than editing the schedule

A common temptation is to temporarily change the CronJob schedule to something like every minute, wait for it to trigger, and then change it back. That works, but it is noisy, easy to forget, and can accidentally create repeated runs instead of one test run.

Creating a one-off Job is safer because:

• the original schedule stays untouched
• there is no risk of multiple accidental runs from a temporary cron expression
• the manual run has its own job name and logs

In most operational environments, that makes troubleshooting much cleaner.

If you need to change parameters for the manual run

Sometimes the CronJob template is almost right, but you want a small change for debugging, such as a different environment variable or command argument. In that case, export the manifest and create a custom job:

kubectl get cronjob nightly-report -o yaml

Then copy the jobTemplate.spec into a standalone Job manifest and adjust what you need:

1apiVersion: batch/v1
2kind: Job
3metadata:
4  name: nightly-report-debug
5spec:
6  template:
7    spec:
8      restartPolicy: Never
9      containers:
10        - name: report
11          image: my-registry/report:1.0
12          args:
13            - "--dry-run"

Apply it with:

kubectl apply -f nightly-report-debug.yaml

This is more work than kubectl create job --from=cronjob, but it is useful when you need a controlled variant of the scheduled workload.

Important behavior and cleanup notes

One subtle point is that the CronJob's concurrencyPolicy controls what the CronJob controller does with scheduled runs. It does not stop you from creating an extra manual Job. That means you can accidentally run a manual job while a scheduled run is already active.

Be careful with workloads such as backups, billing, or data imports where duplicate execution can be harmful.

It is also worth cleaning up manual jobs after testing if your cluster does not already use TTL cleanup:

kubectl delete job nightly-report-manual

Leaving lots of old manual jobs around makes troubleshooting harder later.

Common Pitfalls

The most common mistake is editing the cron schedule to force an immediate run. That often creates more than one run and leaves the CronJob in a modified state if someone forgets to revert it.

Another issue is assuming a manual job respects concurrencyPolicy automatically. It does not. A manually created Job is just another job.

Developers also forget to inspect pod logs and only look at kubectl get jobs. A job can exist while its pod is crash-looping or failing immediately.

Finally, remember that kubectl create job --from=cronjob/... copies the current template. If the CronJob spec is wrong, the manual job will faithfully reproduce that wrong configuration.

Summary

• The usual way to run a CronJob immediately is kubectl create job --from=cronjob/<name> <job-name>.
• This creates a one-off Job from the CronJob template without changing the schedule.
• Inspect the new job and its pod logs just like any other batch workload.
• Use a custom Job manifest if you need to tweak arguments or environment for debugging.
• Be careful with duplicate execution because manual jobs do not inherit CronJob concurrency protection automatically.