GitHub Actions schedule delayed at the top of the hour: what to do

Move the cron minute off :00 (for example 17 past) and make the job idempotent, so a late or doubled start cannot spend twice. GitHub's own reference says scheduled workflows can be delayed during periods of high load, and it names the start of every hour as a high-load time. If the workflow only calls a Sume Scheduled run through the API, a delay costs you minutes, not money.

What does GitHub actually promise for schedule?

The page makes no on-the-minute promise. It also sets a few rules that matter for a paid pipeline.

Why does a delayed start matter when the job costs money?

A late run is harmless. A run that fires twice, or one that overlaps yesterday's run that is still going, is the expensive case. Two controls on the Sume side cover both.

• An Idempotency-Key built from the business date. The same key with the same payload returns the existing run instead of starting another.
• on_active_run set to reject, so a start while the previous run is still active gets a 409 action_run_in_progress instead of a second paid run. The default is skip, which returns 200 with status skipped and skip_reason previous_run_active.

What does the workflow look like?

The schedule lives in GitHub, the work lives in a Sume Scheduled agent with an API trigger. The key goes in a repository secret, never in the file. Keys need the actions:read and actions:write scopes, and service-account keys are refused.

name: nightly-sume
on:
  schedule:
    - cron: '17 3 * * *'
jobs:
  start:
    runs-on: ubuntu-latest
    steps:
      - name: Start the Sume scheduled run
        env:
          SUME_API_KEY: ${{ secrets.SUME_API_KEY }}
          ACTION_ID: ${{ vars.SUME_ACTION_ID }}
        run: |
          curl --fail-with-body -sS -X POST \
            "https://api.sume.com/v1/actions/$ACTION_ID/runs" \
            -H "Authorization: Bearer $SUME_API_KEY" \
            -H "Idempotency-Key: nightly-$(date -u +%F)" \
            -H "Content-Type: application/json" \
            -d '{"on_active_run":"reject"}'

What does Sume not do here?

Sume Scheduled has its own cron trigger with an IANA timezone, so GitHub is optional. Use the GitHub route only when the trigger has to follow a repository event or sit inside an existing pipeline. Schedules are created in the dashboard, not through the API, and the API trigger must be enabled on that schedule first. Read the API trigger reference before wiring it, and the scheduled agents guide for the spend cap, which defaults to $1.00 per run and can only be lowered per run.

Keep the GitHub workflow free of any logic that decides what to make. Put it in the agent, and pass the date as input. The input is data the agent reads, not instructions it obeys.