Why the 39 minute wait? /5 * * *

[su-lewis]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

Schedule & Cron Jobs

Discussion Details

Is a 30+ minute delay on a 5-minute schedule expected?

name: Check for New Sends

on:
  workflow_dispatch:
  schedule:
    - cron: '*/5 * * * *'

    
jobs:
  scrape:
    runs-on: ubuntu-latest
    permissions:      
      contents: write   
    steps:
      - name: Check out repository
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.10'

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

[SaiSruthisri]

Yeah, that kind of delay is unfortunately expected with GitHub Actions cron schedules. The timing in the YAML (*/5 * * * *) just means the job is eligible to run every 5 minutes, but GitHub doesn’t guarantee exact execution. Jobs go into a global queue, and during heavy load it can take 30+ minutes (or more) before your runner actually picks it up.

If you really need accurate 5-minute intervals, GitHub does let us do following :

• Self-hosted runners – since they don’t go through the shared queue, they start right away.

• Or external scheduling – trigger the workflow via the API with an actual cron on your own server or cloud function.

So yeah, even though you’re seeing a 39-minute delay, that’s within what GitHub considers normal for hosted runners.