@kingthorin ,

Many times, there is a delay when triggering the scheduled workflow.
Generally the delay time is about 3 to 10 minutes. Sometimes it may be more time, even dozens of minutes or more than one hour. However, if the delay time is too long, the scheduled workflow may be not triggered at that day.

In your case, you can try to use the “Get a workflow run” API to get the details of runs #56 and #57 respectively. From the response of the API, you can see when the runs were triggered (created_at).

• If time interval between References from discussions in issues/PRs and visa-versa #56 and Go To File #57 is more than but close to 24 hours, the scheduled workflow should have been triggered but just has a relatively long delay time.

• If the time interval is close to (event more than) 48 hours, the scheduled workflow indeed was not triggered at that day. This may be caused by some issues on GitHub.

Thanks @brightran

I’m okay with delays, I think I’ve seen that regularly, but it totally being skipped caught me off guard.

Does anyone know if there are any plans to increase assurance that things run, or to implement some sort of notification(s) if they don’t?

Edit: Just in-case anyone come across this later. The “run id” for the API mentioned above isn’t just 56 or 57 it’s the one you see in the URL when viewing the run in the GitHub web UI.

Edit2: It seems 56 was created on the 17th ("created_at": "2020-09-17T00:32:30Z",), while 57 was created on the 19th ("created_at": "2020-09-19T00:32:40Z",). So there really does appear to have been no attempt to run it on the 18th 😦

I wrote a quick blog post with some additional information about this issue: https://upptime.js.org/blog/2021/01/22/github-actions-schedule-not-working.