Releasing outside business hours: a checklist for small teams

Many teams release when fewer people are online, because a bad release then costs less. The trade-off is that fewer people are awake to notice and fix a problem. A little preparation makes the quiet hours safe.

Before the release

Confirm approvals and required checks are still valid at the time of the merge, not only when you scheduled it.
Pin the exact commit you reviewed, so a late push cannot slip in.
Write down the rollback: which commit gets reverted, who can approve it, how long it takes.
Check for changes a revert cannot undo: database migrations, infrastructure changes, third-party contracts.
Tell the team in one message what is going out and when.

During the release

Watch the deploy, not just the merge: a merge is not finished until the deploy is green.
Add a health check after the deploy if your app has a health URL.
Have one person on call, with alerts that will wake them.

Automate the boring parts

The steps that cause missed releases are the manual ones: remembering to merge, watching a pipeline, opening a revert pull request half asleep. Scheduling, deploy watching and revert are good candidates for automation. Keep the decision to release with a person; give the timing and the watching to a tool.

What to leave for the morning

Finding the real cause of a failed deploy: revert first, investigate later.
Anything involving data repair.
Cleanup such as removing feature flags.

A simple rule

If you would not be comfortable being woken up for the rollback, do not release at that hour.

Where Merge Scheduler fits

Merge Scheduler handles the timing and the watching: it merges the exact commit you approved at the time you choose, follows the GitHub Actions deploy, emails the result, and on paid plans reverts a failed deploy and tells you which step failed.