Based on your description, I can identify several potential issues with your GitHub Actions scheduled workflows:

Main Issues:

1. Daylight Saving Time (DST) Change

ET recently switched to EST (Daylight Saving Time ended on Nov 3, 2025). This changes the UTC offset:

• EDT (summer): UTC-4
• EST (winter): UTC-5

Your cron schedules might still be using EDT calculations. For EST, you need to add 5 hours, not 4.

2. Cron Syntax Issues

Looking at your evening schedules:

cron: '8,23,38,53 0-3 * * 2-6'  # Weekday evenings

This runs Tuesday-Saturday (days 2-6) at UTC 00:08-03:53. But if you want Monday-Friday evenings in ET:

• Monday 7 PM ET = Tuesday 00:00 UTC (day 2)
• Tuesday 7 PM ET = Wednesday 00:00 UTC (day 3)
• etc.

The day-of-week crossover at midnight UTC is tricky.

3. Workflow Registration

GitHub Actions requires the workflow file to be on the default branch AND you must push a commit after schedule changes for GitHub to re-register the cron schedule.

Solutions:

For EST (current):

Weekdays 2:08-5:38 PM EST (19:08-22:38 UTC):

cron: '8,38 19-22 * * 1-5'

Weekdays 6:08-10:53 PM EST spans midnight UTC:

• Before midnight: 23:08-23:53 UTC Monday-Friday
• After midnight: 00:08-03:53 UTC Tuesday-Saturday

# Before midnight portion
cron: '8,23,38,53 23 * * 1-5'
# After midnight portion  
cron: '8,23,38,53 0-3 * * 2-6'

Debugging Steps:

1. Verify default branch: Your workflow must be in .github/workflows/ on your repository's default branch (usually main or master)

2. Test with simple schedule: Try this simple test:

on:
  schedule:
    - cron: '*/10 * * * *'  # Every 10 minutes

Commit, push, and wait 15 minutes to confirm scheduling works at all.

1. After ANY schedule change: Make a commit (even just adding a comment) and push to trigger re-registration:

# Updated schedule - 2025-11-13
on:
  schedule:
    - cron: '...'  

1. Check Actions tab: Go to your repository → Actions → Click your workflow → Look for any error messages or disabled workflows

2. Repository settings: Ensure Actions are enabled: Settings → Actions → General → Allow all actions

Alternative Approach:

If cross-midnight schedules keep failing, split into two separate workflow files:

workflow-daytime.yml:

on:
  schedule:
    - cron: '8,38 19-22 * * 1-5'      # 2:08-5:38 PM EST
    - cron: '8,23,38,53 23 * * 1-5'   # 6:08-6:53 PM EST

workflow-evening.yml:

on:
  schedule:
    - cron: '8,23,38,53 0-3 * * 2-6'  # 7:08-10:53 PM EST

Known GitHub Actions Limitations:

• Scheduled workflows can be delayed up to 15 minutes during high load
• If a repository has no activity for 60 days, schedules are automatically disabled
• Free tier repos have usage limits

After making changes, commit and push, then monitor the Actions tab for the next scheduled time. If it still doesn't trigger after the UTC time passes, there might be a GitHub-side issue requiring support escalation (which is available even for free accounts via GitHub Community or support tickets for Actions-related issues).

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

+1 to the DST + UTC crossover points in the other reply.

Two additional practical gotchas with GitHub schedules:

• Schedules are best-effort and can be delayed/dropped under load (especially right at :00). If you can, avoid scheduling exactly on the hour and use e.g. 8,23,38,53 (like you’re doing) or another “random-ish” minute.
• When you span midnight UTC, the day-of-week field gets confusing fast. A simpler approach is often:
  1. schedule in UTC only (ignore local time),
  2. or use an external scheduler in your local timezone that triggers workflow_dispatch.

If the workflow stops triggering entirely after a schedule edit, a trivial commit to the workflow file on the default branch can force re-registration.

(And if you need an alert when it doesn’t run, an external dead-man’s-switch monitor is the only reliable way.)

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬