Merge Scheduler vs merge-schedule-action and Mergify schedules
These tools solve related but different problems. This page describes each as its own documentation does, and where they overlap. Details change, so check their current docs before deciding.
merge-schedule-action
An open-source GitHub Action. You add a /schedule line with a date to the pull request description, and a workflow that runs on a cron schedule merges the pull request once that date has passed. You can set the merge method, time zone and whether required checks must pass.
- Free, and everything lives in your repository.
- Timing depends on how often your workflow runs.
- It merges; watching the deploy and reverting are up to you.
Mergify schedule conditions
Mergify is a rules engine and merge queue for pull requests. Its schedule conditions restrict when its rules may merge, for example only on weekdays in working hours in a given time zone.
- Strong for merge queues and rule-based policies.
- Scheduling is a condition on rules (when merging is allowed), rather than "merge this one at 02:00 tonight".
Merge Scheduler
A GitHub App focused on the moment after you press merge. You pick a pull request and an exact time; it merges, watches the GitHub Actions deploy, and reverts automatically if the deploy fails.
- Exact time, re-checked conflicts, approvals and checks at merge time.
- Commit pinning: new pushes after scheduling are never merged unreviewed.
- Deploy watching, automatic revert, and a clear reason when something fails.
- Ordered releases across repositories (backend, then frontend).
- Free for small use; paid plans add auto-revert, groups, health checks and a dashboard.
Quick comparison
| merge-schedule-action | Mergify schedules | Merge Scheduler | |
|---|---|---|---|
| Type | GitHub Action | GitHub App, rules engine | GitHub App |
| Set up by | Workflow file + date in PR description | Rules file | Pick PR and time in the app |
| Exact-time merge | Depends on cron frequency | Condition on when merging is allowed | Yes |
| Watches the deploy | No | Not its focus | Yes |
| Reverts on failure | No | Not its focus | Yes (Pro) |
| Cost | Free | See their pricing | Free tier, paid per seat |
When to choose which
- Day-level scheduling for a few pull requests, and you like to own the workflow: merge-schedule-action.
- A merge queue and policy rules for a busy repository: Mergify.
- Night or off-hours releases where the deploy should be watched and reverted for you: Merge Scheduler.
- Many teams combine them: a merge queue for everyday work, Merge Scheduler for the releases that go out at night.
Related: How to schedule a GitHub pull request merge (4 ways) · How to automatically revert a failed deploy (and when not to)