Feature Request: Scheduled workflow dispatch

[PatrickDiallo23]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

General

Discussion Details

Hello Team,

I am opening this discussion to propose a Github Action feature that I would like to have.

It is about a new trigger event called ‘workflow_dispatch_schedule’ that combines the behaviors of workflow dispatch and schedule events. From UX perspective, I would like to have at the bottom of the dispatcher window a little calendar window where I can set the schedule for this job.
In my team, we update our workflows quite often and sometimes we have some configuration for schedule event and other configuration for workflow dispatch event (that are not matching). And sometimes the scheduling actions are failing because they are not configured properly. So instead of wasting time to solve actions implementation, we can dispatch a scheduled action that takes proper configuration. Also, this scheduled dispatcher could also cancel the already scheduled action (from schedule trigger event if that is making any sense).

Please let me know what do you think. Thanks!

[github-actions[bot]]

🕒 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! 💬

[iamwujiabao]

This is a great feature request. While GitHub doesn't currently have a native "Scheduled Dispatch" UI with a calendar picker, you can achieve the exact behavior you're looking for by centralizing your logic and using Workflow Inputs.

The Current Problem:
Having separate configurations for schedule and workflow_dispatch often leads to "configuration drift," where one works and the other fails because they aren't using the same parameters.

The Solution: Unified Workflow Logic
Instead of maintaining two separate paths, you can define your variables in one place and allow the workflow_dispatch to override the defaults.

Here is a pattern you can use today:

on:
  schedule:
    - cron: '0 0 * * *' # Runs daily at midnight
  workflow_dispatch:
    inputs:
      environment:
        description: 'Environment to run against'
        required: true
        default: 'production'

jobs:
  unified_job:
    runs-on: ubuntu-latest
    steps:
      - name: Set Configuration
        run: |
          # Use input if it exists (manual), otherwise use default (scheduled)
          ENV=${{ github.event.inputs.environment || 'production' }}
          echo "Running in $ENV"

Why this helps your team:

1. No More Drift: By using the || (OR) logic in your steps, the scheduled run and the manual run always use the same core logic.
2. Testing Schedules: You can "manually dispatch" the exact same logic that the scheduler uses to verify it works before the cron job triggers.
3. Single Source of Truth: You only have one set of steps to maintain.

Regarding the UI Request:
A calendar picker for one-off scheduled runs is a popular request in the community. Until that is implemented, some teams use a "Delayed Dispatch" pattern where a manual trigger starts a job that simply runs a sleep command (or a wait action) before executing the main logic.

[PatrickDiallo23]

The option with sleep doesn’t sound that bad, but if I am triggering the job and I am putting a ‘sleep’ for 8 hours, wouldn’t it eat some of the resources? I don’t want to wake up with a higher bill.

[PatrickDiallo23]

I would prefer a true native delayed dispatch. Where can I fill in the feature request exactly?

[PatrickDiallo23]

@Gecko51

[andifry7]

workflow_dispatch_schedule_mockup.html

💡 Proposal: New trigger event workflow_dispatch_schedule
What problem does this solve?
In teams that iterate frequently on workflows, it's common to have diverging configurations between schedule and workflow_dispatch triggers — different branches, different env values, sometimes even different job conditions. When a scheduled run fires against a stale config, it fails silently and wastes debugging time that has nothing to do with the actual code.

Proposed feature
A new trigger event: workflow_dispatch_schedule
This combines the manual control of workflow_dispatch with the time-targeting of schedule. The idea is: you dispatch a workflow as you normally would, but instead of it running immediately, you set a future datetime directly from the dispatcher UI.

UX proposal (dispatcher window)
Extend the existing "Run workflow" modal with a collapsible "Schedule this run" section at the bottom, containing:

A calendar date picker to select a target date
A time selector (UTC)
A recurrence option (once / daily / weekly)
A toggle to enable/disable the scheduled dispatch
A conflict warning if there's already a pending schedule trigger for the same workflow — with an option to cancel it

This way, the dispatched run inherits the exact inputs and ref configured in the UI, eliminating the config drift issue entirely.

Bonus behavior: cancel conflicting schedule triggers
If a workflow has an active pending run queued from a schedule trigger, the dispatcher could surface a warning and offer to cancel it before scheduling the new one. This prevents duplicate or conflicting runs.

Example use case:
on:
workflow_dispatch_schedule:
inputs:
environment:
description: 'Target environment'
required: true
default: 'staging'

Dispatching this would open the standard inputs form plus the calendar picker — giving full control over both what runs and when it runs, in a single action.

Why not just edit the cron?
Editing schedule cron requires a commit, a PR (in protected branches), and re-syncing your team. For one-off or adjusted runs, that's unnecessary overhead. workflow_dispatch_schedule would be a zero-commit, zero-PR solution for time-targeted runs.

Would love to hear if others have hit similar pain points. Happy to draft a more detailed spec if there's traction here. 🙏

[PatrickDiallo23]

@andifry7 Indeed, I need something like this, but simpler. A simple and old-school calendar date and time picker below the input fields would suffice. The way I would add the trigger event is the same as you described. I was also told to add sleep logic to the workflow_dispatch workflow type, but I don't think it is best practice.

Do you know who can take this request in consideration or where we should address this?

[github-actions[bot]]

🕒 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! 💬