Github action - new timezone feature....not working?

[JoeDittmer]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

Pasted below is the scheduled time I implemented with the new timezone feature (5:33AM). Previously, I had been using UTC time with caused the action to be triggered at 6:30 or 5:30 depending on time of year......but after pushing this new .yml to my main, the action is being ran at 7:00AM ish.... any reasons why? Has anyone else switched from UTC to using your local timezone and ran into a similar issue?

on:
schedule:
- cron: '33 5 * * *'
timezone: 'America/Los_Angeles'
workflow_dispatch: # Allow manual runs

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[Julianv3534]

@JoeDittmer this could be a real issue, but the first thing I’d check is the YAML shape. GitHub’s current docs still say on.schedule cron runs at specific UTC times, while GitHub’s troubleshooting docs also say scheduled workflows can run late under load.

Likely cause
In GitHub Docs examples that show the new timezone support, timezone appears attached to the same schedule item as cron, not as a separate sibling under on.

Try:

on:
  schedule:
    - cron: '33 5 * * *'
      timezone: 'America/Los_Angeles'
  workflow_dispatch:

I think that in your version timezone is outside the schedule item, so GitHub is much less likely to treat it as the timezone for that cron expression.

[JoeDittmer]

Thanks for the reply. The way I pasted my YAML in the original post was misleading.....I do have it in that format (see below). It ran at 6:45 this morning, which I understand actions may be delayed due to load, but when using UTC format, I never experienced this lag.
on: schedule: - cron: '33 5 * * *' timezone: 'America/Los_Angeles' workflow_dispatch:

[Gecko51]

The timezone feature itself isn't broken, and your YAML is correct. What you're hitting is the scheduler lag.

GitHub runs schedule: triggers on shared infrastructure, and during peak hours the actual trigger time can be anywhere from 15 minutes to 2+ hours behind. This was always the case with UTC, it just wasn't as noticeable if your cron happened to fire during a low-traffic window.

With America/Los_Angeles and 33 5 * * *, GitHub converts that to roughly 12:33 UTC internally. Mid-day UTC is one of the busier windows, which explains the consistent drift you're seeing.

There's no direct fix for this. If you need the trigger to fire close to the scheduled time, a common workaround is to use an external cron service (cron-job.org, Zapier, etc.) that hits the workflow_dispatch API endpoint at the exact time you want. That bypasses the shared scheduler queue entirely.

If the drift is inconsistent rather than constant, also worth checking the GitHub status page to rule out a broader incident.

[dpobel]

I'm maybe hitting the same problem and while I understand the drifting issue, I think the whole thing would be a bit more understandable if the interface would display the time at which the job is scheduled (to see if the timezone is taken into account) in addition to the time it was actually run. Roughly something like:

without that, it's impossible (or maybe I'm missing something) to understand if it's a load issue or I wrote something wrong in the YAML.