What does enabling auto-merge on a GitHub pull request do, and when is that option available?

## What it is for On a repository with slow or numerous required checks, the last hour of a pull request's life is usually a human refreshing the page waiting for a green tick. Auto-merge removes that wait. You approve the intent once, and GitHub executes the merge when the conditions are satisfied — which might be at three in the morning, after the last check finally finishes. ## Enabling it Three things must line up. First, a repository administrator must turn on **Allow auto-merge** in the repository's pull request settings; it is off by default. Second, you need write access to the repository. Third, the pull request must be in a state where auto-merge is meaningful: not a draft, and with at least one requirement still unmet — if everything already passes there is nothing to wait for and you simply merge. When you enable it, GitHub asks which merge method to use, restricted to the methods the repository allows, and lets you edit the resulting commit message up front. That is the moment your judgment is recorded; from then on the merge is mechanical. ## What it waits for Auto-merge waits for the repository's own gates. In practice that means required status checks reporting success, the required number of approving reviews, any required review from code owners, resolution of conversations if the repository requires it, and the absence of blocking states such as a requested change that has not been resolved. Auto-merge grants no exemptions: it is the same merge a person with the same permissions would perform, executed by GitHub on their behalf. If a required check fails, nothing merges. Auto-merge stays armed and simply keeps waiting, so a re-run that turns green later will still trigger the merge — which is convenient when a check is flaky and dangerous if you have stopped paying attention to the pull request. ## When it turns itself off The important cancellation to remember is that a push to the head branch by someone **without write access** disables auto-merge. The rationale is straightforward: the person who armed it consented to merging the code they had reviewed, and an unprivileged contributor pushing new commits afterwards changes what would be merged. Closing the pull request also clears it, and anyone with write access can disable it manually. ## Interaction with a merge queue Where a repository routes merges through a queue, enabling auto-merge does not bypass it. The pull request is added to the queue when it qualifies, and the queue's own mechanics decide when it lands. Conceptually auto-merge answers "should this merge without me", while the queue answers "in what order and against what other pending changes". ## Operational judgment Auto-merge is safest where required checks genuinely mean what they say. Two failure modes show up on real teams: - **Stale approval.** Auto-merge is armed, then someone with write access pushes further commits. Unless the repository dismisses stale approvals on new commits, the merge can proceed against code nobody re-read. That is a rule you set in branch protection, and auto-merge makes the consequence of *not* setting it visible. - **Silent late merges.** A change that lands hours later can surprise an on-call engineer. Teams that deploy on merge often pair auto-merge with a deployment window or a queue rather than letting arbitrary changes land unattended. The corresponding benefit is real: it removes babysitting, shortens the time between approval and delivery, and cuts the human error of merging the wrong pull request while tab-switching. ## How to answer Define it as a deferred merge with the method chosen up front, list the preconditions (repository setting, write access, not a draft, something still outstanding), state clearly that it enforces exactly the same requirements as a manual merge, and finish with the cancellation rules and the stale-approval caveat. That progression shows both the mechanism and the operational awareness an interviewer is checking for.