GitHub auto-merge, merge queue and scheduled merge: what each is for

Three features are often confused, because all of them merge a pull request without you pressing the button. They answer different questions: when the requirements are met, in what order, and at what time.

Auto-merge: merge when it is ready

With auto-merge on, GitHub merges the pull request as soon as the required reviews and status checks pass. It answers "merge this as soon as it is allowed". It does not know about the clock. The option appears on pull requests that cannot merge yet, and it must be enabled for the repository first.

Merge queue: merge in order, tested together

A merge queue checks each pull request against the latest base branch together with the pull requests already queued ahead of it, then merges them one after another. It answers "merge these safely, in order". It does not know about the clock either.

Scheduled merge: merge at a chosen time

A scheduled merge answers "merge this at 11 p.m." or "after the weekend". GitHub has no built-in feature for this, so teams use a workflow, a GitHub App or a person with an alarm.

How they fit together

Auto-merge decides when a pull request becomes allowed to merge. A schedule decides when you want it to happen. For "ready, and at 11 p.m." you need the schedule.
If your branch uses a merge queue, a scheduler can add the pull request to the queue at the chosen time and let the queue merge it in order.
None of the three watches the deploy after the merge or reverts it.

Quick comparison

	Auto-merge	Merge queue	Scheduled merge
Answers	Merge when requirements are met	Merge safely, in order	Merge at a chosen time
Knows the clock	No	No	Yes
Watches the deploy	No	No	Depends on the tool
Built into GitHub	Yes	Yes	No

Where Merge Scheduler fits

Merge Scheduler adds the clock, the commit pin, the deploy watching and the revert. When the base branch uses a merge queue, it adds the pull request to the queue at the scheduled time and then watches for GitHub to merge it.