How to schedule a GitHub pull request merge (4 ways)

You have reviewed a pull request and it is ready, but it should not go live until tonight, or after the weekend, or outside business hours. GitHub does not have a built-in way to say "merge this at 2 a.m.", so teams use one of a few workarounds.

Option 1: merge it yourself at the time

The simplest option, and still the most common. You set an alarm, open the pull request and press the button.

Good: no setup, you are watching when it happens.
Bad: someone has to be awake and available, and it is easy to forget or get delayed.

Option 2: a scheduled GitHub Actions workflow

A workflow with a cron schedule can look for pull requests that are due and merge them. The open-source merge-schedule-action works this way: you add a line such as /schedule 2026-06-08 to the pull request description, and a workflow that runs on a schedule merges it once the date has passed.

Good: free, lives in your repository, you control everything.
Bad: scheduled workflows run on a cron, so timing is rough (often hourly, and GitHub notes scheduled runs can be delayed at busy times).
Bad: you maintain it, and it only merges. Nothing watches the deploy or undoes a bad release.

Option 3: a GitHub App that merges on a date

Apps such as PR Scheduler and agba-merger let you comment on or tag a pull request with a date, and merge it for you. As far as their public descriptions say, they focus on the merge itself, at date level.

Good: nothing to maintain in your repository.
Bad: usually a date rather than an exact time, and no awareness of what happens after the merge.

Option 4: Merge Scheduler

Merge Scheduler merges at an exact time you choose, then keeps going: it watches your GitHub Actions deploy and, if the deploy fails, opens and merges a revert pull request and tells you which step failed and why.

Re-checks conflicts, approvals and checks at merge time.
Pins the commit you reviewed: if someone pushes afterwards, the merge is skipped instead of shipping unreviewed code.
Can release several repositories in order, for example backend first and then frontend.
Installs as a GitHub App on the repositories you choose; no workflow files to add.

What to check before you schedule any merge

Will required reviews and status checks still be valid at merge time?
Could someone push new commits to the branch before it merges?
Which time zone is the schedule in?
Which merge method does the repository expect (merge, squash or rebase)?
Who is on call if the deploy fails, and can the change be reverted? Database migrations often cannot.

Which should you pick?

If you only need day-level scheduling for a handful of pull requests and are happy to maintain a workflow, the Actions approach is free and fine. If you release at night or outside working hours and want the deploy watched and reverted automatically, that is what Merge Scheduler is built for.