Ship release PRs on your team's schedule — without chasing them

Tell Zero once when to ship release PRs and which ones to skip. It runs the check on your cadence, skips risky changes, and merges the rest — so you stop being a human cron job.

Zero connects:

Why chasing release PRs drains the on-call engineer

A new release PR opens whenever your main branch picks up enough commits — on most teams that's once or twice a day. Someone has to glance at the diff, confirm CI is green, decide whether the changelog contains anything scary, click Merge, and then babysit the deploy. If they are in a meeting, asleep, or on another continent, the release sits. Commits keep stacking on top, the changelog grows, and the merge gets riskier. You tell Zero once — run the release check once a workday, skip the risky ones, merge during work hours, post to the release channel — and from then on, shipping happens on its own, on your team's clock.

How to ask Zero to ship release PRs

@Zero every weekday at 3pm, check our repo for an open release PR. If it has no DB migration files, enable auto-merge with squash so it ships the moment CI passes — then post an update in #release-notify.

try it

How Zero merges your release PRs

Zero checks for release PRs on your cadence

Zero runs on whatever schedule you set — once a workday for most teams, hourly for high-velocity ones — and queries GitHub for open release PRs on your default branch. Outside that window, it does nothing. No after-hours merges, no weekend surprises.

Zero vets each PR against your safety rules

Zero reads the file list on the PR. If any file matches a sensitive path you flagged (migrations, infra, billing), it skips the merge and pings the channel so a human decides. Otherwise it confirms the required CI checks are passing.

Zero enables auto-merge and reports the outcome

For PRs that pass the policy, Zero runs `gh pr merge --auto --squash` so the PR lands the moment CI turns green. When the merge lands, Zero posts a compact status line back to your release channel.

Tighten the policy, escalate the risky ones, or crank up the cadence

Tighten the policy on the fly

Layer in new rules without touching code.

@Zero from now on, skip any release PR whose changelog mentions `infra` or `billing`.

try it

Escalate the risky ones

Have Zero flag — not merge — PRs it would otherwise skip.

@Zero when you find a release PR with a migration file, open a thread in #dev tagging @oncall with the diff link.

try it

Crank up the cadence when you're ready

Move from daily to multiple times a day once the policy has proven itself.

@Zero starting next week, run the release auto-merge check twice a day — once in the morning, once after lunch — instead of just at 3pm.

try it

Required integrations: GitHub and Slack

GitHub

GitHub — Zero lists release PRs, inspects file changes, confirms CI status, and enables auto-merge. Repository write access is required so Zero can trigger the merge.

Required

Slack

Slack — Zero uses your Slack connection to announce merges, flag skipped PRs, and escalate risky ones. Without Slack, Zero can still merge but has nowhere to report.

Required

Best practices for autonomous release merging

●Start with one check a day and increase the cadence only after the policy has earned trust. Daily gives the team a predictable shipping rhythm without feeling surveilled.

●Encode your unwritten release rules in the prompt. 'Skip migrations' is obvious; 'pause merges during demo windows' or 'never ship on Friday afternoons' are the quiet rules Zero should know about.

●Chain it with a daily engineering brief so your morning report opens with 'yesterday's release shipped, N commits in it, M PRs still queued'. Pair autonomous shipping with visible reporting.