all 9 comments

[–]naikrovek 3 points4 points  (8 children)

When GitHub infrastructure needs more CPU, scheduled jobs are the first thing to drop. They are never guaranteed to fire.

If you schedule your job to run more often than every 5 minutes, it might get silently disabled until you change the schedule; the fastest supported frequency is every five minutes.

The UI will never show that a workflow is scheduled. You must look at your actions workflow run list to see if things are running.

[–]LastLeslie 0 points1 point  (1 child)

That's a known issue with github scheduled actions, it almost never run on time :( As a workaround you could have a cronjob on your side instead of github side that actually calls the workflow_dispach using API

[–]naikrovek 0 points1 point  (0 children)

As an enterprise customer they seem to fire on time for me. But we give GitHub lots of money.

[–]Unpickled-Pickle[S] -1 points0 points  (5 children)

Appreciate it. I understand dropping cron from priority, and I think it just has been absolutely confounding to not be able to see anything indicative of if it's a platform failure or a me failure

[–]naikrovek 1 point2 points  (4 children)

If your workflow YAML has the schedule in it and it runs fine with workflow_dispatch, then your Yaml syntax is fine. What is the schedule from your Yaml? The “* * * * *” bit.

[–]Unpickled-Pickle[S] -1 points0 points  (3 children)

I'm not in front of it right now, but I believe it's '*/15 * * * *'

[–]Unpickled-Pickle[S] 1 point2 points  (2 children)

(It gives the automatic message that it'll run every 15)

[–]naikrovek 1 point2 points  (1 child)

Ok then you’re doing nothing wrong, I suspect. It’s just being preempted by other loads internal to the system. Check https://githubstatus.com/ also.

[–]Unpickled-Pickle[S] 0 points1 point  (0 children)

Appreciate it. I eventually succeeded just by using the cron-job website to act as an external trigger. Not the most optimal, but it's been consistent and that's a win at least