Skip to main content
By default a person merges the fix pull requests SRE Agent opens, and that review is your gate. An organization admin can turn on Merge fix pull requests by themselves once required checks pass for a repository. SRE Agent then asks GitHub to merge a fix pull request once the checks its branch requires pass, or merges it itself when those checks had already passed when it looked. Business plan
Nobody reviews a merge made this way. Your organization’s admins take that risk. The setting is off until an organization admin turns it on, and turning it on needs a confirmation.

Turn it on

A repository whose fix pull requests open as drafts merges nothing by itself, because a draft never merges by itself. When you turn auto-merge on in the table, the prompt offers Also open them ready for review, ticked, and writes both settings in one change. You can also set Pull requests to Ready for review in the same row, or choose Ready for review for Open pull requests as drafts in the repository’s settings. Where auto-merge is on for a repository that opens drafts, the table and the repository’s settings form show “Opens as drafts, so nothing merges by itself.” See Draft or ready for review. Only an organization admin can change it. An API key needs mcp:admin or api:admin. Your plan must include GitHub integrations. A support administrator who is viewing as an organization admin can turn it off but never on, on the page or anywhere else, because whether pull requests merge with nobody reviewing them is your own admins’ choice. Turning it on needs a confirmation on every door: the tick on the page, and confirm: ["auto_merge"] over MCP and the configuration API. So does anything that makes a branch start reading it as on: a default turned on, a repository put back on a default that says on, or an all-branches entry that branch entries follow. Turning it off needs nothing. Every change is on the audit log as repo_settings.auto_merge_changed. It is one more repository setting, so it follows the rules in Set repository defaults for your organization: a repository’s entry for a branch beats its all-branches entry, which beats the organization default, and the default is off. A pull request merges by itself only when every reading of its base branch says on.

Auto-merge only what SRE Agent verified

This is a choice for the whole organization, under Integrations, GitHub. Over MCP it is auto_merge_requires_verification on update_github_settings, and it is part of the github_settings resource of the configuration API. It is off by default.
  • Off. A fix that SRE Agent’s own checks did not run for (the verifier is switched off, paused or busy, the request ran on your own runner, or nothing verifies it) can still merge by itself once the checks its branch requires pass. A change pushed onto a pull request afterwards merges on those checks alone.
  • On. Only a fix whose exact commit SRE Agent’s checks ran on and passed merges by itself. A change pushed onto it afterwards is not asked for again, because nothing verifies a change.
In both positions, a fix whose checks failed, a fix whose checks ran and could not judge it, and a fix with an open self-review blocker never merges by itself.

Which pull requests

SRE Agent asks for a merge only for a pull request that:
  • a person or an integration your organization set up asked for in words: a fix request, a card, Slack, MCP, an approved code finding, a request sent to the fix-requests webhook, or a ticket that carries the opt-in tag in the Jira or Zoho Sprints webhook. A self-healing pull request also counts when its area is at full autonomy; an area at any lower tier never merges by itself. An automatic revision merges by itself only when the self-healing pull request it revises would;
  • opens ready for review. A draft never merges by itself, and a failing verification, an open self-review blocker and a change to CI configuration all make one;
  • changes no CI configuration, no IAM policy and no Kubernetes manifest, and is not a revert;
  • has no card approval still pending, and no holding approval that was turned down, withdrawn or expired after the request;
  • is in this repository (not from a fork), is still at the commit SRE Agent checked, and is still aimed at the base branch the setting was read for.

What GitHub must have

SRE Agent does not turn on a repository’s Allow auto-merge setting, and it cannot. For each pull request it reads GitHub. It does not ask for a merge, and says why on the pull request and the card, when:
  1. the repository does not allow auto-merge (Settings, General, Allow auto-merge on GitHub);
  2. the base branch requires no status check, through a branch protection rule or a ruleset. A rule that only requires a review is not enough: with no check to wait for, GitHub would wait for a review indefinitely;
  3. SRE Agent’s GitHub App can bypass the rules that require the checks, because it is in a ruleset’s bypass list;
  4. the base branch merges through a merge queue, so a person merges there;
  5. the pull request is behind its base under a rule that requires it to be up to date, because nothing would update it;
  6. the repository and the branch’s rules allow no merge method SRE Agent can ask for. It takes the first of squash, rebase and merge commit that the repository and every rule allow.
Branches protected by a classic rule that the installation cannot read get “a person merges it”. Nothing is changed in GitHub’s own settings, and the App asks for no new permission. It uses Contents (write) and Pull requests (write), which every fix pull request already needs, on a token narrowed to the one repository.

What SRE Agent does, and what it cannot promise

  • Checks still running. SRE Agent asks GitHub to merge the pull request when its required checks pass (GitHub’s auto-merge, pinned to the commit SRE Agent checked). It does not say a merge will happen: GitHub merges only when every required check passes.
  • Checks already passed. GitHub does not accept auto-merge for a pull request that is already mergeable, so SRE Agent merges it itself, with the same method and the commit it checked as the guard. GitHub refuses that call if the branch moved.
  • A pull request GitHub left alone. One that stays mergeable with auto-merge on for 10 minutes is merged by SRE Agent the same way.
  • A push is not stopped by GitHub. GitHub’s guard on the commit holds only at the moment of the request. A push to the branch by someone with write access leaves auto-merge on, and GitHub then merges the new commit too once the checks pass on it. SRE Agent turns auto-merge off when it sees such a push. That takes seconds, and it is not in time when the checks pass first. The pull request description says so.

Stop one pull request

Any of these turns auto-merge off, and SRE Agent does not ask for it again on that pull request:
  • Comment /hold (or hold, or @sre-agent hold) on the pull request. Anyone who is not a bot can, outside contributors included, because turning auto-merge off only ever stops automation. Only a new comment counts, not an edit or a review body.
  • Submit a review that asks for changes.
  • Convert the pull request to a draft.
  • Turn auto-merge off on GitHub.
SRE Agent also turns it off when a commit it did not make is pushed (or the pull request is reopened with a new commit), when the repository’s setting reads off, the plan lapses, a card approval is asked, the base branch changes, a self-healing action stops running unattended, the organization is no longer active, or the organization stops reaching the GitHub connection the pull request was opened through. Auto-merge that a person turned on is left on when only the repository’s own rules end, and the comment says whose it is.

When a stop takes effect

A stop is made at GitHub first and written down second, and it is retried until GitHub confirms, so a pull request never reads “off” while GitHub holds it on. Most stops are queued the moment they are made:
  • A comment, a review, a draft conversion, a push, a reopen with a new commit or a base change on GitHub: seconds, from the delivery.
  • A card approval asked on a card that links the pull request, a self-healing pause or policy change, a repository setting or the organization defaults turned off, and the organization’s choice to auto-merge only what SRE Agent verified turned on.
  • A change asked for on the pull request, from the moment the change is claimed. It also waits for GitHub’s confirmation before it pushes anything, and pushes nothing onto a pull request that is already merged.
  • A child organization that stops using its parent’s GitHub connection or is unlinked from it, a GitHub installation removed in SRE Agent, and an organization that is deleted, all before the connection goes.
What waits for the pass that runs every five minutes: a plan that lapsed, the platform’s own pause of self-healing, a card approval that was turned down, withdrawn or expired, an organization suspended by SRE Agent’s operators, and anything a delivery or a setting change missed. A GitHub installation that GitHub itself removed, because the App was uninstalled there, cannot be reached at all. GitHub keeps whatever was on, and the pull request’s own checks decide. A pull request that stays on and unmerged for seven days is said once on the pull request and its card (SRE Agent says it is no longer managing auto-merge on it), and the five-minute pass stops reading it at GitHub. A stop still reaches it, and so does anyone turning it off on GitHub.

A change pushed onto the pull request

When a person asks SRE Agent for a change on its pull request (@sre-agent change, Slack, a card, MCP, or an automatic revision), SRE Agent turns auto-merge off when it takes the request, so the pull request cannot merge without the change. It pushes nothing if GitHub does not confirm that auto-merge is off. After the push:
  • A change a person asked for, with no CI file in it, asks for auto-merge again for the new commit when the organization’s choice to auto-merge only what SRE Agent verified is off.
  • An automatic revision never asks again, and neither does a change that touches CI configuration.
See Change a pull request from a comment. A repository that is renamed or transferred while a pull request is set is still found, by GitHub’s own ids for it, which SRE Agent keeps once GitHub has answered for the pull request.

What you see

  • The pull request. The description says whether auto-merge was asked for, and why not when it was not. One comment says when GitHub did not agree, when auto-merge was turned off and why, and when SRE Agent merged it.
  • The card. A line for each of those, also in the card’s Slack threads (a line that says a person has to merge it is always posted), and a badge on the fix request. The Slack lines follow the card events you choose.
  • The Control Tower. The request drawer shows Auto-merge: asked for, on, not set (with the reason), turned off (with who or what did it) or merged.
  • MCP. get_ticket answers auto_merge for each pull request of a card, with the state, the reason, the method and a sentence. get_fix_queue with request_id answers the same for one request, and needs the self-hosted runner plan, so an organization on SRE Agent’s runner alone reads it through get_ticket.
  • The audit log. fix_pr.auto_merge_set, fix_pr.auto_merge_not_set, fix_pr.auto_merge_turned_off and fix_pr.auto_merge_merged.

On your own fix runner

The runner opens the pull request as usual and never turns auto-merge on. SRE Agent decides after the runner’s report, or after the GitHub delivery that adopts its pull request, reads GitHub, and asks with its own App. The job your runner collects carries auto_merge, a boolean that says SRE Agent may ask, and the brief says the same in its Environment section. See Run fixes on your own machine.