HTTPfy

Every minute

At every minute of every hour of every day: 1,440 runs a day.

525,600runs in the next 365 days
10,080runs per week
1 minbetween every run
02:24next run, Wed 11 Nov UTC

What it is used for

The smallest interval classic cron can express. Used for watchdogs, sending queued mail, and as a building block for sub-minute jobs (a script that loops with sleep).

Field by field

FieldValueMatches
Minute*every value
Hour*every value
Day of month*every value
Month*every value
Day of week*every value
* * * * * /path/to/job

Next 10 run times

Computed when this page loaded (2026-11-11 02:23 UTC), assuming the scheduler runs in UTC.

#UTCYour local time
1Wed 2026-11-11 02:24
2Wed 2026-11-11 02:25
3Wed 2026-11-11 02:26
4Wed 2026-11-11 02:27
5Wed 2026-11-11 02:28
6Wed 2026-11-11 02:29
7Wed 2026-11-11 02:30
8Wed 2026-11-11 02:31
9Wed 2026-11-11 02:32
10Wed 2026-11-11 02:33

Things to watch with this schedule

  • Cron cannot run anything more often than once a minute. For a 30-second job, use two lines: * * * * * job and * * * * * sleep 30; job, or a systemd timer with OnCalendar=*:*:00/30 / OnUnitActiveSec=30s.
  • 1,440 runs a day means 1,440 log lines and 1,440 possible cron mails. Redirect output (>/dev/null 2>&1 or to a log file) or MAILTO will flood the mailbox.
  • */1 * * * * is the same schedule; the step of 1 is redundant.

Kubernetes CronJob

Kubernetes uses the same five fields. Set spec.timeZone (stable since Kubernetes 1.27), otherwise the schedule follows the time zone of kube-controller-manager.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: every-minute
spec:
  schedule: "* * * * *"
  timeZone: "Etc/UTC"
  concurrencyPolicy: Forbid
  startingDeadlineSeconds: 300
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: job
              image: debian:bookworm-slim
              command: ["/bin/sh", "-c", "/app/run-job.sh"]

GitHub Actions

Workflow schedules use five-field cron in UTC and run only from the default branch. GitHub's shortest interval is 5 minutes, so runs closer together than that are not honoured; this schedule will fire less often than written. Runs at minute 0 are the most likely to be delayed or dropped when GitHub is busy; an odd minute such as 7 or 23 starts more reliably.

on:
  schedule:
    - cron: '* * * * *'   # UTC

jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./run-job.sh

systemd timer

The equivalent OnCalendar= value is *-*-* *:*:00. Check it with systemd-analyze calendar '*-*-* *:*:00', which prints the next elapse time. Persistent=true runs a missed job after downtime, which classic cron never does.

[Unit]
Description=Every minute

[Timer]
OnCalendar=*-*-* *:*:00
Persistent=true

[Install]
WantedBy=timers.target

AWS EventBridge

EventBridge rules take six fields (minute, hour, day-of-month, month, day-of-week, year) in UTC; EventBridge Scheduler can use a time zone. One of day-of-month and day-of-week must be ?, and day-of-week runs 1-7 from Sunday, so names are used here.

cron(* * * * ? *)

Quartz Scheduler (Java)

Quartz adds a leading seconds field and needs ? in either day field; days of the week are 1 (SUN) to 7 (SAT).

0 * * * * ?

Spring's @Scheduled(cron = ...) also uses six fields, but numbers days of the week 0-7 with Sunday as 0 or 7, like Unix cron; the names shown above work in both.

Related schedules