epochkit

Cron expression for every minute

The cron expression * * * * * runs every minute. Every field is an asterisk, so nothing restricts the match and the job fires on every tick. That works out to 1,440 runs per day.

* * * * *
Edit this schedule in the cron builder Read the cron cheat sheet

Field breakdown

Field-by-field meaning of the cron expression * * * * *
Field Value Meaning
Minute * Every minute (0–59)
Hour * Every hour (0–23)
Day of month * Every day of the month (1–31)
Month * Every month (1–12)
Day of week * Every day of the week (0–6)

Next runs

Next 5 runs Timezone: UTC
  1. —
  2. —
  3. —
  4. —
  5. —

Run times are calculated in your browser timezone. The scheduler that executes the job uses its own — always UTC on Vercel Cron, UTC by default on GitHub Actions, the host clock on crontab.

How this schedule works

Cron evaluates the five fields of * * * * * — minute, hour, day of month, month, day of week — against the clock once a minute and starts the job on any minute where all five match, which cronstrue reads as "Every minute": 1,440 runs per day.

When to use every minute

Reach for minute-level scheduling when a late detection costs more than 1,440 daily invocations do: liveness probes, heartbeat writes, and short queue drains that must not sit idle. It is a poor fit for anything that talks to a rate-limited third-party API, and a poor fit for work that occasionally overruns a minute, because cron will start a second copy while the first is still going. If you find yourself wanting a shorter interval, the job has outgrown cron and belongs behind a queue consumer.

Common mistakes with every minute

The classic mistake is reaching for this expression when the minute field was meant to be pinned. 0 * * * * runs 24 times a day, * * * * * runs 1,440, and the two look nearly identical in a diff. The second mistake is assuming cron will wait: it starts a new process on every match whether or not the last one finished, so a job that occasionally takes 90 seconds quietly runs two copies at once, and a job that hangs accumulates them until the box runs out of memory. Take a lock, and give the job a timeout it cannot exceed.

Platform snippets

The same expression, ready to paste into the four schedulers that read five-field cron. The notes below each snippet are the ones that follow from this schedule; the cron expression generator lists every caveat for every platform.

GitHub Actions

yaml

GitHub Actions ignores schedules shorter than 5 minutes. The minimum supported interval is once every 5 minutes (e.g. */5 * * * *). 

name: Scheduled workflow
on:
  schedule:
    - cron: '* * * * *'
  workflow_dispatch:

jobs:
  scheduled:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run job
        run: echo "Running scheduled job"

Kubernetes CronJob

yaml 
apiVersion: batch/v1
kind: CronJob
metadata:
  name: my-cron-job
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: job
              image: my-image:latest
              command: ["/bin/sh", "-c", "echo Running"]
          restartPolicy: OnFailure

Vercel Cron

json

Hobby plan limitation: cron jobs can only run once per day. Schedules more frequent than daily will fail to deploy on Hobby. Use Pro plan or above for higher frequency. 

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "crons": [
    {
      "path": "/api/cron",
      "schedule": "* * * * *"
    }
  ]
}
  • • Pro plan and above: invocations occur within the specified minute (e.g. "5 8 * * *" runs between 08:05:00 and 08:05:59).

crontab

bash 
# Edit your crontab: crontab -e
* * * * * /path/to/command

# With logging:
* * * * * /path/to/command >> /var/log/cron.log 2>&1

Variations

Frequently asked questions

How do I read the cron expression * * * * *?

Read the five space-separated fields left to right as minute, hour, day of month, month, and day of week. In * * * * * the minute is *, hour is *, day of month is *, month is *, day of week is *. Of the operators cron defines, this expression uses only the ones that matter here: an asterisk matches every value in its field. Put together, cronstrue reads the whole thing as "Every minute", and a scheduler that checks all five fields once a minute will start the job 1,440 runs per day.

What timezone does * * * * * run in?

Less than you would think. Because the hour field is unrestricted, the cadence is the same in every timezone — 1,440 runs per day, wherever the scheduler's clock is set. The zone changes the labels on the run times rather than the schedule. It still matters at the edges. GitHub Actions evaluates schedules in UTC unless the workflow adds the optional timezone key beside cron; Vercel Cron is UTC-only; a Kubernetes CronJob follows the kube-controller-manager's zone unless spec.timeZone is set; and a crontab follows the host clock or CRON_TZ. The edge that bites is daylight saving: in a zone that shifts its clocks, the spring-forward hour never arrives and the fall-back hour arrives twice, so a schedule like this one loses or repeats a whole block of runs on those two days a year. Scheduling in UTC avoids it.

Can a cron job run more often than every minute?

Standard cron resolves down to one minute and no further, so a five-field expression cannot express a sub-minute schedule. To run a task every 30 seconds, keep the minute-level schedule and loop inside the job, use a supervisor such as systemd timers with an OnUnitActiveSec interval, or run a long-lived worker with its own timer. Hosted schedulers add their own floors on top of that: GitHub Actions ignores anything shorter than 5 minutes, and Vercel Cron on the Hobby plan allows one run per day. Anything approaching real time belongs in a queue consumer rather than a cron schedule.

Related cron schedules

Build a custom schedule in the cron expression generator, or browse every epochkit tool.