Cron Expression That Never Runs — Disable Without Deleting

A "never-run" cron expression is valid syntax that the scheduler accepts without error but never actually triggers — because it targets a date that doesn't exist. The standard pattern is 0 0 30 2 *: midnight on February 30th, a date that has never occurred and never will.

This pattern is useful in IaC templates, feature flags, and configuration-as-code where removing a schedule entry is a larger change than disabling it. Build valid expressions with our cron generator and verify the intent with the visualizer (it will show no upcoming runs).

Standard Never-Run Cron Expressions

Use an impossible calendar date. The most universally recognized options:

Expression	Why it never runs	Platform support
0 0 30 2 *	February 30 — never exists	Most Linux cron, GitHub Actions, node-cron
0 0 31 2 *	February 31 — never exists	Same as above
0 0 31 4 *	April 31 — April has 30 days	Same as above
0 0 31 6 *	June 31 — June has 30 days	Same as above

Recommended: 0 0 30 2 * — February 30 is the most universally understood impossible date. Other developers reading your crontab immediately recognize the intent.

Paste any of these into the crontab visualizer — it will show "no upcoming runs" confirming the expression never fires.

When a Never-Run Expression Is the Right Choice

Infrastructure as Code (Terraform, Pulumi, Ansible): If a scheduled job is defined in a template that gets applied across environments, you may want the job active in production but disabled in staging. A never-run expression in the staging variable is cleaner than conditionally omitting the resource entirely.

# terraform.tfvars — staging
schedule = "0 0 30 2 *"  # disabled

# terraform.tfvars — production
schedule = "0 2 * * *"   # daily 2 AM

Feature flags in application config: Externalizing a cron expression to application.properties or environment variables lets you disable a job by setting the variable to a never-run expression without redeploying the application.

Temporary disable during incidents: Faster than removing and re-adding a crontab entry during an incident. Change the expression to 0 0 30 2 *, resolve the issue, then restore the original expression.

Sell Custom Apparel — We Handle Printing & Free Shipping

Platform-Specific Ways to Disable a Scheduled Job

Not all platforms accept impossible dates silently — some validate and reject them. Use the platform-native disable mechanism instead:

Kubernetes CronJob: Don't use an impossible date. Use the suspend flag instead:

kubectl patch cronjob my-job -p '{"spec":{"suspend":true}}'
# Re-enable:
kubectl patch cronjob my-job -p '{"spec":{"suspend":false}}'

GitHub Actions: Disable the entire workflow from the Actions tab (Settings → Disable workflow). For schedule-only workflows, removing the on: schedule trigger in a branch is the clean approach.

Spring Boot @Scheduled: Use the never-run expression via externalized config (@Scheduled(cron = "${job.schedule}")) and set the property to 0 0 30 2 *. Spring accepts this without error.

AWS EventBridge: Disable the rule directly in the console or via CLI: aws events disable-rule --name my-rule. Don't use an impossible date — EventBridge validates dates and may reject them.

Linux crontab: Comment out the line with # for the cleanest approach. The never-run expression is useful when you want the line to remain syntactically active (for templating) but not execute.

Verifying Your Expression Actually Never Runs

Before relying on a never-run expression, confirm it behaves as expected on your specific platform. Paste 0 0 30 2 * into the crontab visualizer — the calendar will show no highlighted dates, confirming no upcoming runs.

Also test at the platform level before a critical disable:

• Linux: Check logs after the supposed run time with journalctl -u cron --since "1 hour ago" — no entry confirms the job didn't fire.
• Kubernetes: kubectl get jobs -l job-name=my-cronjob — no jobs created after the schedule time confirms suspension.
• Spring Boot: Enable DEBUG logging for org.springframework.scheduling — you'll see the scheduler evaluate the expression without triggering.

Some cron implementations (notably Quartz) throw a parse error on impossible dates. If your platform rejects the expression, fall back to the platform-native disable mechanism.

Frequently Asked Questions

What cron expression means "never run"?

"0 0 30 2 *" is the standard never-run expression — it targets February 30th, a date that doesn't exist. The scheduler accepts it as valid syntax but never triggers it. Alternative impossible dates: "0 0 31 4 *" (April 31), "0 0 31 6 *" (June 31). February 30 is the most universally understood and recommended.

Will cron throw an error for an impossible date like February 30?

Most Linux cron implementations (Vixie cron, cronie) silently accept impossible dates — they parse the expression as valid and simply never find a matching date. However, some platforms validate calendar dates and reject them: AWS EventBridge raises an error, and some Quartz implementations throw a parse exception. Always test on your specific platform.

What is the cleanest way to disable a crontab job temporarily?

Comment out the line in the crontab file with a # prefix — this is the clearest signal to future developers. The never-run expression ("0 0 30 2 *") is better when you need the line to remain syntactically active for templating or IaC reasons, or when you want to be able to restore it by changing only one value.