Merge Scheduler vs Merge Freeze: blocking merges vs performing them

The two names sound alike and the jobs are opposite. One keeps merges from happening at certain times. The other makes a merge happen at a certain time and then watches what follows. This page describes Merge Freeze as its public listings do; check its current documentation for details.

Merge Freeze

A GitHub App that blocks merges into protected branches, either on demand or on a recurring schedule, for example outside working hours. It integrates with Slack and has an API so deployment scripts can check whether a repository is frozen.

Strong for: preventing merges on Fridays, during incidents or outside working hours.
It does not merge anything for you.

Merge Scheduler

You pick a pull request and a time. It merges the exact commit you approved, watches the GitHub Actions deploy, emails the result, and on paid plans reverts a failed deploy and runs ordered multi-repo releases.

Strong for: night or off-hours releases where you want the merge, the deploy watch and the rollback handled for you.
It does not enforce freeze windows for other people.

Quick comparison

	Merge Freeze	Merge Scheduler
Main job	Block merges in chosen windows	Merge at a chosen time
Merges for you	No	Yes
Watches the deploy	No (offers a status API for scripts)	Yes
Reverts a failed deploy	No	Yes (paid plans)
Slack	Yes	Notifications on paid plans

Using both

They do not compete. If you freeze merges outside working hours but release at night on purpose, schedule the merge for a time the freeze allows, or lift the freeze for that window. If a freeze tool blocks the merge, GitHub refuses it, and Merge Scheduler reports that the merge was blocked instead of merging anyway.