Skip to content
Latchkey

Every-minute cron rejected or dropped (minimum interval) in CI

A * * * * * (every minute) schedule is not honored reliably. GitHub does not guarantee runs more frequent than roughly every 5 minutes; sub-5-minute crons are throttled, coalesced, or skipped, so many of your minute ticks never run.

What this error means

You set cron: '* * * * *' expecting 60 runs an hour, but only a handful of runs appear, spaced irregularly at 5 minutes or more apart.

.github/workflows/poll.yml
# cron: '* * * * *'   intended: every minute
# reality: runs appear roughly every 5+ minutes, most ticks skipped

Common causes

GitHub throttles high-frequency schedules

The scheduler does not guarantee intervals shorter than about 5 minutes, so most every-minute ticks are dropped.

Overlap and load protection

Very frequent crons that overlap or queue under load are coalesced, further reducing how often the job actually runs.

How to fix it

Use an interval of 5 minutes or more

  1. Change the cron to a step of at least 5 minutes.
  2. Confirm the actual run cadence in the Actions tab.
  3. If you truly need sub-minute polling, move it out of cron.
.github/workflows/poll.yml
on:
  schedule:
    - cron: '*/5 * * * *'   # every 5 minutes, the practical minimum

Move sub-minute work to a long-running job

For true high-frequency polling, run a single job on a loop, or use an external scheduler, instead of relying on per-minute cron.

.github/workflows/poll.yml
jobs:
  poll:
    runs-on: ubuntu-latest
    steps:
      - run: |
          for i in $(seq 1 10); do check.sh; sleep 30; done

How to prevent it

  • Do not schedule crons more often than every 5 minutes.
  • Loop inside one job for sub-minute cadence.
  • Use an external scheduler for strict high-frequency needs.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →