Every Minute Cron – Free, Online, Private

The expression

* * * * * is a five-field cron expression: minute, hour, day of month, month, day of week. There is no seconds field and no year field. Every minute, every hour, every day The next five run times on this page are computed in your browser with the same expression, in UTC, so a reload later in the hour shows a later list. Edit the box if you want to nudge a field and watch the list change, or open the line in the cron parser.

What each field is doing

The minute field is an asterisk, so every value in the 0–59 range is allowed. This field is not what limits the schedule. The hour field is an asterisk, so every value in the 0–23 range is allowed. This field is not what limits the schedule. The day-of-month field is an asterisk, so every value in the 1–31 range is allowed. This field is not what limits the schedule. The month field is an asterisk, so every value in the 1–12 range is allowed. This field is not what limits the schedule. The day-of-week field is an asterisk, so every value in the 0–6, Sunday as 0 or 7 range is allowed. This field is not what limits the schedule.

When the day-of-month and day-of-week fields are both something other than *, many cron implementations run the job if either field matches. This preset leaves at least one of those two fields as *, so you do not have to resolve that rule to predict it. Names such as MON and JAN are readable and widely accepted. The snippets use numbers so a strict parser does not have to know the names.

Why this schedule

People reach for a one-minute schedule when a queue, a health check, or a lock renewal feels like it should be continuous. Cron is still a coarse timer. The process starts about once a minute, and a run that lasts longer than a minute will overlap the next one unless you add a lock. That overlap is the usual outage: two writers, one row, no error until the data is wrong.

A minute schedule fits a heartbeat that must notice a dead worker quickly, a metric scrape you do not want to run as a daemon, or a test of the scheduler itself. It is a poor fit for sending email, rebuilding a search index, or anything that calls a paid API.

Where it goes wrong

GitHub Actions refuses schedules more frequent than every five minutes, so this expression is valid crontab and an invalid workflow trigger. Kubernetes will accept it and start a Job every minute, which is a good way to exhaust the API server if the job is heavy. The next-run list on this page is computed in your browser from the expression, in UTC, and it will show sixty times an hour.

A sixth field is the seconds field used by Quartz, some Spring apps, and some Kubernetes setups that are not the classic CronJob schedule. Classic crontab, GitHub Actions, and the schedule field of a batch/v1 CronJob are five fields. If you paste a six-field line into those systems, the extra token shifts every field one place to the left and the job runs on a different day. L, W, and the # 'nth weekday' modifier are real in some daemons and rejected or reinterpreted in others. They are not used on this page. The English description and the next runs both refuse to guess at a token the calculator does not share with every target.

Crontab, GitHub Actions, and Kubernetes

GitHub Actions will not run this expression. Scheduled workflows are limited to every five minutes, and a star in the minute field is faster than that. The same line is still valid in a crontab and in a Kubernetes CronJob. Use those, or pick a five-minute step, if the trigger has to be a GitHub workflow.

A user crontab does not include the username. A system crontab, the kind in /etc/crontab, inserts the user between the expression and the command. The line below is the user form. Kubernetes CronJob has used spec.timeZone since 1.27. The manifest sets it to Etc/UTC so the schedule matches the next-run list. Remove the field on a cluster older than that, and know that the schedule then uses the controller's zone.

crontab* * * * * /usr/local/bin/job

GitHub Actionson:
  schedule:
    - cron: "* * * * *"

Kubernetes CronJobapiVersion: batch/v1
kind: CronJob
metadata:
  name: every-minute
spec:
  schedule: "* * * * *"
  timeZone: "Etc/UTC"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: job
              image: busybox:1.36
              args: ["echo", "every-minute"]
          restartPolicy: OnFailure

• Keep the command idempotent. Cron does not remember a failure and it does not skip a run that is already in progress.
• Write the timezone next to the expression. UTC in the file and local time in the ticket are how a job fires eight hours early.
• Offset the minute if several jobs would otherwise start at once.