HTTPfy

Every 5 minutes during business hours

Every 5 minutes from 09:00 to 17:55, Monday to Friday: 108 runs a weekday.

*/5 9-17 * * 1-5 Open in Crontab Generator
28,188runs in the next 365 days
540runs per week
5 min / 63 h 5 minshortest / longest gap between runs
09:00next run, Wed 11 Nov UTC

What it is used for

Polling or alerting that only matters during working hours, saving API calls and noise at night and at weekends.

Field by field

FieldValueMatches
Minute*/50, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55
Hour9-179, 10, 11, 12, 13, 14, 15, 16, 17
Day of month*every value
Month*every value
Day of week1-5Monday, Tuesday, Wednesday, Thursday, Friday
 
*/5 9-17 * * 1-5 /path/to/job

Next 10 run times

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

#UTCYour local time
1Wed 2026-11-11 09:00
2Wed 2026-11-11 09:05
3Wed 2026-11-11 09:10
4Wed 2026-11-11 09:15
5Wed 2026-11-11 09:20
6Wed 2026-11-11 09:25
7Wed 2026-11-11 09:30
8Wed 2026-11-11 09:35
9Wed 2026-11-11 09:40
10Wed 2026-11-11 09:45

Things to watch with this schedule

  • The hour range 9-17 covers the whole 17:00 hour, so the last run is 17:55, not 17:00. To stop at 17:00 exactly, use two lines: */5 9-16 * * 1-5 and 0 17 * * 1-5.

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-5-minutes-during-business-hours
spec:
  schedule: "*/5 9-17 * * 1-5"
  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. 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: '*/5 9-17 * * 1-5'   # UTC

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

systemd timer

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

[Unit]
Description=Every 5 minutes during business hours

[Timer]
OnCalendar=Mon..Fri *-*-* 09..17:00/5: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(0/5 9-17 ? * MON-FRI *)

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 0/5 9-17 ? * MON-FRI

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