Feature Request: Schedule a Future Workflow Run with User-Provided Inputs

[trikaldarshiii]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

Problem

Many deployment workflows require execution at a specific future date and time. Today, GitHub Actions allows manual execution through workflow_dispatch and recurring schedules through cron, but there is no native way to configure a one-time future execution with custom inputs.

As a result, teams must either:

• Wait until the desired time and manually trigger the workflow.
• Create temporary scheduled workflows.
• Use external schedulers or automation tools.
• Build custom logic inside workflows to delay execution.

This adds operational overhead for deployment and release management.

Proposed Solution

Add a "Schedule Run" option when manually dispatching a workflow.

Users would:

1. Open the workflow and click Run workflow.
2. Provide all required workflow inputs.
3. Choose a future date and time.
4. Submit the request.

GitHub Actions would then create a scheduled workflow run that automatically starts at the specified time with the provided inputs.

Example UI

Run Workflow
---------------------------------
Environment: Production
Version: v2.4.1
Region: US-East

[ Run Now ]

[ Schedule Run ]
Date: 2026-08-20
Time: 22:00 UTC

Benefits

• Simplifies deployment planning.
• Eliminates the need for external schedulers.
• Reduces operational effort during off-hours releases.
• Enables release managers to prepare deployments in advance.
• Improves scheduling consistency across teams.

Possible Enhancements

• Edit or cancel a scheduled workflow before execution.
• Display upcoming scheduled runs in the workflow UI.
• Send notifications before execution.
• Support recurring schedules with workflow inputs.

Use Cases

• Production deployments during maintenance windows.
• Scheduled certificate rotations.
• Infrastructure changes outside business hours.
• Planned release rollouts across regions.
• Data processing and migration activities at predefined times.

Expected Behavior

After providing workflow inputs and selecting a future execution time, GitHub Actions should automatically trigger the workflow at the scheduled time using the exact inputs supplied during scheduling.

This would make GitHub Actions significantly more useful for release and deployment orchestration without requiring additional automation tooling.

[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. ⭐

[tomm1990]

there’s still no native “run this workflow once at 14:00 next thursday with these inputs” button. workflow_dispatch is now, cron is repeating. that’s the gap.

workaround that usually works:

1. keep your real job on workflow_dispatch with the inputs you already have
2. store the future run as data (repo variable, gist, or a tiny json in the repo): time (utc) + the inputs
3. add a small scheduler workflow on cron (every 5 - 15 min is enough) that:
   • reads that payload
   • if now >= scheduled_at, calls gh workflow run your-real-workflow.yml -f param1=value1 ...
   • then deletes / marks the payload as done so it doesn’t fire twice

gh workflow run is the important bit - that’s how you pass the same inputs you’d type in the UI.

don’t sleep inside a job until the target time. you’ll burn minutes and still hit the 6h job timeout.

if this is a one-off, the even dumber version is: set a temporary cron for that exact utc minute, run once, then delete the workflow. messy, but zero extra infra.

so: +1 on the feature request. until github ships it, “dispatch now” vs “cron + stored inputs + gh workflow run” is the practical split.

[Zohaibcode740]

A practical approach would be to keep the actual deployment workflow unchanged and add a lightweight scheduler that triggers it at the requested time.

For example, the real workflow can continue using workflow_dispatch:

name: Deploy

on:
  workflow_dispatch:
    inputs:
      environment:
        required: true
        type: string
      version:
        required: true
        type: string

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy
        run: |
          echo "Deploying ${{ inputs.version }} to ${{ inputs.environment }}"

A separate scheduler workflow could periodically check whether a stored request is due and then dispatch the real workflow with the saved inputs:

name: Scheduled Dispatcher

on:
  schedule:
    - cron: "*/10 * * * *"

jobs:
  dispatch:
    runs-on: ubuntu-latest
    permissions:
      actions: write
    steps:
      - name: Check scheduled request
        run: |
          # Read scheduled_at and workflow inputs from the chosen
          # storage mechanism and dispatch when the time is reached.
          echo "Check whether a workflow run is due"

The important part is that the scheduler should store the requested execution time and inputs as data, rather than keeping a runner alive with sleep. Once the time is reached, it can use gh workflow run to trigger the actual workflow with those inputs.

This would also make cancellation and duplicate-run prevention easier to implement. A native "Schedule Run" feature would still be preferable because GitHub could manage the scheduling, UI, cancellation, permissions, and audit trail directly.

[energyzvolt-wq]

greate work @Zohaibcode740