How to edit cron jobs

Editing cron jobs is mostly about knowing which crontab you're changing and how your scheduler loads it. On traditional Linux systems, you'll usually use crontab -e. On Kubernetes, GitHub Actions, or EventBridge, you'll edit YAML or infrastructure configuration instead.

Editing your user crontab with `crontab -e`

SSH into the server that actually runs your cron jobs.
Run crontab -l to view existing jobs.
Run crontab -e to edit your user crontab.
Add, update, or comment out lines as needed.
Save and exit the editor (e.g. :wq in Vim).

# Example: run a backup at 02:00 every day
0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Each Unix user typically has their own crontab. Jobs run with that user's permissions and environment.

Editing the system crontab and cron directories

System-wide jobs are often defined in /etc/crontab or /etc/cron.d/*.conf. These files add an extra user column that controls who the command runs as.

# /etc/crontab (example)
# m h dom mon dow user  command
0 0 * * * root  /usr/local/sbin/rotate-logs

Editing these files usually requires root access. Always keep a backup and be careful not to break existing jobs.

Editing cron jobs in Kubernetes, GitHub Actions, and EventBridge

Managed platforms store their schedules in configuration files rather than OS crontabs. You'll edit those configs and redeploy or re-apply them.

Kubernetes: update the spec.schedule field of a CronJob manifest and apply with kubectl apply.
GitHub Actions: edit the on.schedule.cron field in a workflow YAML file.
AWS EventBridge: update the ScheduleExpression (often with Quartz syntax).

Our expression pages include ready-to-paste snippets for these platforms, so you can tweak the schedule and copy it directly.

Safely changing cron schedules

Test the expression first. Use a tool that shows upcoming run times so you can verify the schedule visually.
Keep a backup. Save the old crontab or config somewhere so you can roll back quickly.
Log output. Redirect stdout/stderr to a log file so you can confirm the job is still running after the change.
Coordinate with other jobs. Avoid overlapping jobs that contend for the same resources.

Quick links