How to run a cron job every minute. Use * * * * * to execute a command every 60 seconds. Examples for Unix, Quartz, and AWS.
The cron expression * * * * * runs a command every single minute of every hour, every day. All five fields are set to the wildcard asterisk (*), which means "match every possible value" for minutes (0-59), hours (0-23), day of month (1-31), month (1-12), and day of week (0-6). This results in 1,440 executions per day (60 minutes × 24 hours). It is the most frequent standard cron schedule possible. Common use cases include real-time monitoring scripts, polling external APIs for changes, queue processing workers that need immediate responsiveness, and watchdog processes that restart failed services. When using this schedule, ensure each run completes within 60 seconds to prevent overlapping executions. Use a lock file mechanism (for example, flock in Linux) to prevent duplicate runs if a job takes longer than expected. On Quartz Scheduler, the equivalent is 0 * * ? * * (7 fields, starting with seconds). On AWS EventBridge, use rate(1 minute) for simplicity. On Kubernetes CronJob, the standard format works: schedule: "* * * * *", but note that K8s does not guarantee sub-minute precision. Running a job every minute generates significant log volume and system load. Consider whether every-5-minutes (*/5 * * * *) or every-minute-during-business-hours (* 9-17 * * 1-5) would suffice for your use case. For monitoring, tools like Prometheus, Nagios, or Datadog often provide better built-in scheduling than cron.
The expression * * * * * means: at minute *, hour *, day-of-month *, month *, day-of-week *. Each field in the cron expression controls a different time component: minute, hour, day of month, month, and day of week.
Run crontab -e in your terminal to open your crontab editor. Add a new line: * * * * * /path/to/your/script.sh. Save and exit. Verify with crontab -l. Make sure your script is executable (chmod +x script.sh) and uses full paths for all commands.
Quartz Scheduler: 0 * * * ?. AWS EventBridge: cron(* * ? * * *). Kubernetes CronJob: schedule: "* * * * *" (standard 5-field format). Each platform has slight syntax differences — use our dialect switcher above to get the exact expression.
Common pitfalls: (1) Cron uses a minimal PATH — always use full paths to commands and scripts. (2) Percent signs (%) must be escaped with backslash in crontab. (3) Cron runs in the system timezone — set CRON_TZ=UTC at the top of your crontab for consistent UTC scheduling. (4) Redirect output to prevent email spam: * * * * * /path/command >> /var/log/myjob.log 2>&1. (5) Test your cron expression with crontab.guru or our validator above before deploying.
The cron expression * * * * * has different syntax on various scheduling platforms. Here is the equivalent expression for each:
| Platform | Expression |
|---|---|
| Unix / Linux crontab | * * * * * |
| Quartz Scheduler (Java) | 0 * * * ? |
| AWS EventBridge | cron(* * ? * * *) |
| Kubernetes CronJob | * * * * * |
| Vercel Cron | * * * * * |
| GitHub Actions | * * * * * (UTC) |
Key differences across platforms: Quartz uses 7 fields starting with seconds and supports L (last) and W (weekday) modifiers. AWS EventBridge requires a 6th year field and uses ? instead of * in day fields when the other day field is specified. Kubernetes uses standard 5-field Unix cron. Vercel Cron uses the same format but schedules are defined in vercel.json. GitHub Actions uses standard cron but runs in UTC timezone only, so adjust the hour field for your local timezone offset.
Follow these tips when setting up cron jobs in production: