PC::PerlCoders
Search About Submit a question GitHub

Operations guide · reviewed 22 Aug 2026

Cron jobs that survive production.

The schedule is the easy line. The real job is making repeated execution safe, observable and boring — including the run that starts twice and the run that never starts.

Independently written9 minExamples not CI-tested

Use host cron whenOne known machine owns the task, its timezone is controlled, and a missed run can be diagnosed from that machine.
Use a platform scheduler whenThe application already runs on a managed platform and the task needs its deployment, secrets and logs.
Use Kubernetes CronJob whenThe workload belongs in a cluster and you need cluster scheduling controls. A cluster is not justified by one recurring command.

01

Write the run contract first

Before choosing a schedule, write down what one run owns: its input window, output, maximum duration, retry rule and the person or system that notices failure. “Every night” is not a contract.

Idempotency
Running twice for the same window must either produce the same result or detect that the work is already complete.
Overlap
Choose explicitly: prevent overlap with a lock, queue the next run, or allow safe concurrency.
Time
Name the timezone. If the business rule means “midnight in Berlin”, document how daylight-saving changes are handled.
Failure
Return a non-zero exit status, retain useful logs and alert on the absence of an expected success marker.

02

A small host-owned job

A POSIX crontab entry consists of a schedule followed by a command. Cron does not give the process your interactive shell assumptions. Use absolute paths, set the working directory deliberately and keep secrets out of the command line.

crontabexample · not CI-tested
# 02:15 every day; wrapper owns locking, logs and exit status
15 2 * * * /srv/reporting/bin/run-daily-report

Keep the crontab thin. Put environment validation, locking and the actual command in a versioned wrapper that can also be run manually. Redirecting everything to a forgotten file is not monitoring.

03

When the job belongs to a cluster

Kubernetes CronJob creates Jobs on a repeating schedule. Its documentation is explicit that scheduling is approximate: under some circumstances a schedule can create more than one Job or none. The workload therefore still has to be idempotent.

Do not delegate correctness to the schedulerConcurrency policy, deadlines and retained job history help operations. They do not turn a non-idempotent payment, email or import routine into a safe one.

04

The handoff checklist

  1. The command works from a clean, non-interactive environment.
  2. The job has an explicit timezone and input window.
  3. A lock or concurrency rule is tested.
  4. Retries cannot duplicate irreversible side effects.
  5. Logs contain a run identifier, start, finish and outcome.
  6. An alert detects both failure and missing execution.
  7. A manual runbook explains replay and rollback.

05

Why this URL exists

The former PerlCoders site published a crontab tutorial at /main/crontab.html. A live external citation still points there. This is a new guide for the same scheduling intent; it does not copy the archived tutorial or its code.