How I stopped babysitting late-night releases

Piyush Soni — Fri, 16 Oct 2026 23:15:40 +0000

For a long time my release process looked like this: build a feature, test it well on staging, and then be told it should go live after business hours. So I'd stay up, merge the pull request at the right time, watch the deploy, and be ready to roll it back.

That's a boring job for a person. Here is what I automated, and the traps I found.

1. Merge the commit you approved, not whatever is on the branch

If you schedule a merge for 11 pm and someone pushes at 10:50, a naive scheduler merges code nobody reviewed. The fix is to pin the PR's head commit when you schedule. At merge time, if the head changed, skip the release and say so.

2. Check again at merge time

Required checks, conflicts and approvals can change in the hours between scheduling and merging. Run the prechecks twice: when you schedule, and right before you merge.

3. Watch the deploy, not just the merge

A merge isn't done until the deploy is green. After merging, find the workflow run that the push triggered (workflow_run webhooks make this reliable) and follow it to the end. Capture the failed job and step, plus a few lines around the error, so the email says why it failed.

4. Revert only if it's safe

The riskiest part is the automatic revert. If the branch has moved on since your merge, reverting would also undo other people's work. So: revert automatically only when your merge is still the tip, open it as a normal revert pull request (no history rewriting), wait for the redeploy, and otherwise just tell a human.

5. Know what you can't undo

Database migrations and infrastructure changes deployed outside the push workflow can't be rolled back by reverting a commit. Detect pull requests that touch those paths and warn before scheduling.

The tool

I put this together as Merge Scheduler, a GitHub App that does all of the above: mergescheduler.gentlesoni.online. There is a free plan with no time limit. It only touches the repositories you pick and doesn't keep your code (what it asks for and why).

If you handle after-hours releases differently, I'd like to hear how in the comments.