Why does my macOS cron job fail even though the syntax is correct?

The most common cause is TCC/Full Disk Access — macOS silently blocks cron from reading certain user folders unless it's been explicitly granted permission in System Settings, and the failure often produces no obvious error in your script's own logging.

Should I use cron or launchd on macOS?

For anything long-term or system-critical, launchd is Apple's recommended and actively maintained mechanism. Cron remains fine for quick personal scripts, but be aware it's a legacy compatibility layer, not a first-class citizen on macOS.

Does crontab -e work the same as on Linux?

Yes, the command and editing experience are identical (both use vi by default on macOS unless EDITOR is set) — it's the runtime permission environment that differs, not the crontab syntax or editing workflow.

Operating System

macOS Cron Guide

macOS ships with a BSD-derived cron for backward compatibility, but Apple has steered developers toward launchd (via launchctl and .plist files) as the native scheduling mechanism since Mac OS X 10.4. Cron still works today, but it runs into macOS-specific permission restrictions that don't exist on Linux.

Syntax Notes

Standard 5-field cron syntax, same as Linux. The differences that matter on macOS are entirely about permissions and process management, not the schedule format itself.

Examples

Edit your crontab

crontab -e

launchd alternative: a user LaunchAgent plist

<key>StartCalendarInterval</key>
<dict>
  <key>Hour</key><integer>2</integer>
  <key>Minute</key><integer>0</integer>
</dict>

Gotchas

macOS's Transparency, Consent, and Control (TCC) privacy system requires cron itself to be granted Full Disk Access in System Settings before cron jobs can read files in Documents, Desktop, Downloads, or other protected folders — without it, jobs fail silently with permission errors.
cron is not guaranteed to run if the Mac is asleep at the scheduled time, and unlike some launchd configurations, it won't automatically run a missed job on wake.
Apple could remove cron in a future macOS release since it's officially considered legacy — Apple's own documentation has recommended launchd since 2005, so cron on macOS should be treated as a compatibility feature, not a long-term guarantee.

Best Practices

Grant Full Disk Access to /usr/sbin/cron (System Settings → Privacy & Security → Full Disk Access) immediately if your cron jobs touch anything outside /tmp or your home directory's non-protected paths.
For anything you plan to rely on long-term, prefer launchd LaunchAgents (per-user) or LaunchDaemons (system-wide) — they integrate properly with macOS's power management and don't hit the same permission walls.
Test cron jobs manually first (run the exact command cron would run, in a clean shell) since GUI-launched Terminal sessions have a different environment than cron's.

Frequently Asked Questions

Why does my macOS cron job fail even though the syntax is correct?: The most common cause is TCC/Full Disk Access — macOS silently blocks cron from reading certain user folders unless it's been explicitly granted permission in System Settings, and the failure often produces no obvious error in your script's own logging.
Should I use cron or launchd on macOS?: For anything long-term or system-critical, launchd is Apple's recommended and actively maintained mechanism. Cron remains fine for quick personal scripts, but be aware it's a legacy compatibility layer, not a first-class citizen on macOS.
Does crontab -e work the same as on Linux?: Yes, the command and editing experience are identical (both use vi by default on macOS unless EDITOR is set) — it's the runtime permission environment that differs, not the crontab syntax or editing workflow.

Related Tools

Platform Guides

Cron syntax for Linux, Kubernetes, AWS, and more

Windows Task Scheduler vs Cron

Compare Windows Task Scheduler and Unix cron: syntax, GUI vs config file, trigger types, and how to translate a cron expression into a scheduled task.

Kubernetes CronJob Guide

How to schedule recurring jobs in Kubernetes with CronJob resources: YAML manifest syntax, concurrency policy, and common gotchas.