Cron expression for every 5 minutes

Field breakdown

Next runs

How this schedule works

Cron evaluates the five fields of */5 * * * * — 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 5 minutes": 288 runs per day. Within every hour it fires at :00, :05, :10, :15, :20, :25, :30, :35, :40, :45, :50, :55. Sixty divides by 5 without a remainder, so the gap between runs stays constant as the hour rolls over.

When to use every 5 minutes

Five minutes is the practical floor for hosted schedulers, and it is the interval most polling jobs settle on: 288 runs a day keeps an external feed or a cache reasonably fresh without hammering the upstream. It suits sync jobs whose source changes slowly and whose consumers tolerate a few minutes of staleness. Before committing to it, check that a single run finishes comfortably inside five minutes — overlapping invocations are the usual failure mode at this cadence, and cron will not hold one back to wait for the last.

Common mistakes with every 5 minutes

Two things go wrong at this cadence. The first is expecting */5 to mean "five minutes from now" — it means minutes 0, 5, 10 and so on, anchored to the top of the hour, so a crontab installed at 12:03 fires at 12:05 rather than 12:08. The second is drift into overlap. A five-minute job that grows into a six-minute job never announces itself; it just starts running two copies. Log the duration of every run and alert when it crosses half the interval, long before it crosses the whole one.

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.

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

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

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

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "crons": [
    {
      "path": "/api/cron",
      "schedule": "*/5 * * * *"
    }
  ]
}

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

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

Variations

• */10 * * * * Every 10 minutes The same pattern at half the load: 144 runs a day instead of 288. Reach for it when the upstream starts rate-limiting.
• */15 * * * * Every 15 minutes Quarter-hourly, at :00, :15, :30 and :45. A third of the invocations, and still fresh enough for most dashboards.
• */5 9-17 * * 1-5 Every 5 minutes, between 09:00 AM and 05:59 PM, Monday through Friday Keeps the five-minute resolution but only during working hours on weekdays, which is 108 runs a day rather than 288.
• 5 * * * * At 5 minutes past the hour A single run each hour at five past. Worth contrasting: dropping the asterisk turns a step into a literal, and 288 runs a day into 24.