No assurance on scheduled jobs?

This is a re-post, as I just realized I started the thread in the wrong forum. (And, don’t see any functionality to move it.)

Is there no assurance on execution of scheduled jobs? I mean if they aren’t executed with in n time (window) of their scheduled time are they abandon? Could there have been some sort of GitHub Actions resource contention issue that caused them not to run/fire and then the window was passed?

Was there an infrastructure issue a few days ago that prevented scheduled jobs from running?

I’m asking because I don’t see any evidence of this scheduled job being run on the 18th.

Workflow:, as you can see it hasn’t been changed in 22 days. The schedule is set for midnight:

    - cron:  '0 0 * * *'

But there’s no “3 days ago” run at all:

1 Like

@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 #56 and #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 :frowning:

@kingthorin ,

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", ).

Looks like, the scheduled workflow indeed was not triggered on 18th.
I noticed a GitHub incident reported on 17th (see here). Maybe the issue is related to this incident.

I wrote a quick blog post with some additional information about this issue: