Timing and retries

How fast runs are sent

Cronkick aims to send each run within 30 seconds of its scheduled time. You can see the send delay of each run on your dashboard, and what we’ve measured of GitHub’s own scheduler on the lateness page.

Runs due exactly on the hour are spread over 0–15 seconds per workflow, so thousands of workflows don’t hit GitHub in the same instant.

What counts as on time

A run is on time when GitHub accepted the request within 30 seconds of its scheduled time. The clock stops at the send that succeeded, not the first try: a run whose first try failed and whose retry got through 2 minutes later counts as late.

Before 2026-11-11 the dashboard counted from the first try, so a few older runs may have moved from on time to late.

When GitHub fails

If GitHub is down, throttling or returning errors, Cronkick retries until the slot’s deadline: 5 minutes after its time, or the next scheduled time if that’s sooner. After the deadline it gives up rather than run late, and the slot shows Gave up.

If GitHub refuses the request (for example, the workflow or branch no longer exists), retrying won’t help, so Cronkick stops. The slot shows Refused with GitHub’s reason.

When the outcome is unclear

If a request’s outcome is unclear, for example a timeout after GitHub may already have received it, Cronkick does not send it again. The slot shows Unconfirmed.

When Cronkick is down

Cronkick plans each run up to 2 hours ahead. If it stops and comes back:

• After a restart Cronkick may still send a run if its deadline hasn’t passed, so it may show as late. After the deadline it gives up rather than run it late, and the run shows as Gave up, with the note “Cronkick didn’t send it before its deadline”.
• If planning stopped for more than 2 hours, the outage is recorded as one window, from the last planning pass to when planning resumed. Runs due then may not have been sent; any that were sent are listed in the history. The window shows as a banner on your dashboard and workflow history, and neither the overview nor the workflow page shows an on-time verdict while the window is in the last 24 hours.
• Pro and Team accounts with an alert address get one email per outage window, plus a summary of the runs Cronkick didn’t send, at most one an hour, not an email per run.

There is no automatic fallback to GitHub’s scheduler. To move a workflow back, see Go back to GitHub’s scheduler.

After sending

Once GitHub accepts the request, the job waits in GitHub’s own queue for a runner. Your dashboard shows that wait separately (“GitHub started the run 4 s later”), so you can tell Cronkick’s part from GitHub’s.