Can I run a GitHub Actions schedule more often than every 5 minutes?

GitHub's documented minimum interval is 5 minutes, and even schedules at that frequency are explicitly best-effort — high-frequency schedules are more likely to experience delays.

Why didn't my scheduled workflow run?

Check whether the repository has had any commits in the last 60 days (schedules auto-disable on stale repos), whether the workflow file is on the default branch, and the Actions tab's schedule history for delay or skip indicators.

Can I set a schedule to a specific timezone?

No — the cron field is always evaluated in UTC. Convert your desired local time to UTC when writing the expression (the Cron Timezone Converter tool can help with this).

CI/CD

GitHub Actions Cron Guide

GitHub Actions lets you trigger a workflow on a schedule using the `schedule` event with standard 5-field cron syntax in your workflow YAML. It's one of the most common ways teams run nightly builds, dependency checks, and periodic maintenance jobs without any external infrastructure.

Syntax Notes

Standard 5-field POSIX cron syntax inside the workflow's `on.schedule.cron` key, always evaluated in UTC — there's no way to specify a different timezone for a schedule trigger.

Examples

Nightly workflow at 2 AM UTC

on:
  schedule:
    - cron: "0 2 * * *"

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

Multiple schedules in one workflow

on:
  schedule:
    - cron: "0 6 * * 1-5"   # weekday mornings
    - cron: "0 18 * * 1-5"  # weekday evenings

Gotchas

GitHub explicitly does not guarantee schedules run at the exact minute — during periods of high load on GitHub's infrastructure, scheduled workflows can be delayed or, rarely, dropped entirely. Don't use scheduled workflows for anything with a hard timing SLA.
Scheduled workflows only run on the default branch, and only if the repository has had activity within the last 60 days — GitHub automatically disables schedule triggers on completely inactive repos.
The schedule is always UTC with no exceptions — a common mistake is writing a schedule assuming it'll run in the repo owner's local timezone, which silently produces the wrong local time year-round or seasonally around DST.

Best Practices

Add a manual `workflow_dispatch` trigger alongside `schedule` so you can test and manually re-run the workflow without waiting for (or faking) the schedule.
Compute your desired local time in UTC explicitly and leave a comment in the YAML noting the intended local time — future editors won't have to re-derive the UTC offset.
For anything genuinely time-critical, don't rely solely on GitHub Actions' scheduler — pair it with an external monitor that alerts if the expected run didn't happen within a reasonable window.

Frequently Asked Questions

Can I run a GitHub Actions schedule more often than every 5 minutes?: GitHub's documented minimum interval is 5 minutes, and even schedules at that frequency are explicitly best-effort — high-frequency schedules are more likely to experience delays.
Why didn't my scheduled workflow run?: Check whether the repository has had any commits in the last 60 days (schedules auto-disable on stale repos), whether the workflow file is on the default branch, and the Actions tab's schedule history for delay or skip indicators.
Can I set a schedule to a specific timezone?: No — the cron field is always evaluated in UTC. Convert your desired local time to UTC when writing the expression (the Cron Timezone Converter tool can help with this).

Related Tools

Platform Guides

Cron syntax for Linux, Kubernetes, AWS, and more

AWS EventBridge Scheduler Cron Guide

How cron and rate expressions work in AWS EventBridge Scheduler: 6-field Quartz-style syntax, UTC timing, and common Lambda trigger patterns.

Google Cloud Scheduler Guide

How to schedule jobs with Google Cloud Scheduler: standard 5-field cron syntax (unix-cron), timezone support, and HTTP/Pub/Sub targets.