# Dependabot Auto-Merge: What to Merge and What to Test First

> A policy for Dependabot and Renovate PRs: auto-merge the safe updates, run end-to-end checks on framework and UI upgrades, and keep security patches fast.

Source: https://qa.tech/blog/dependabot-auto-merge · Published: 2026-11-02

---
Developers merged more than 30 million Dependabot pull requests this year, about double 2025's pace, according to [GitHub's Octoverse 2026](https://github.blog/news-insights/octoverse/octoverse-commits-pushes-reach-new-highs-in-2026-as-developers-build-with-agents/).

Patch and minor updates to dev tooling can auto-merge on green CI without anyone looking. Updates to anything that changes what users see, like your UI framework, component library or runtime, need an end-to-end check on a running build first, because a passing unit test suite doesn't see a button that renders differently. Major versions need a person.

## What a Dependabot update can actually break

Rarely at the API level, and the breaks that do get through are the ones unit tests can't see.

The best large study is [Ochoa and colleagues' analysis of Maven Central](https://arxiv.org/abs/2110.07889): 119,879 library upgrades and 293,817 client projects. Most upgrades, 83.4%, complied with semantic versioning. Even so, the library introduced at least one breaking API change in 14.6% of patch upgrades and 37.9% of minor ones. The share of client projects that actually broke was much lower: 5.0% for patch updates and 7.8% for minor.

The study has two limits: it covers Java only, and it counts API breaks, the kind a compiler or unit test catches. A component library that changes its default padding breaks no API at all.

Visual breaks like that are the ones that reach users. A developer at a UK mobile-app company described an Expo upgrade: "everything all seemed to work. It went over to Qa and then we noticed that things like padding wasn't quite right … the way in which Expo renders buttons, for example, had changed." Their engineering head said they'd been holding off upgrades because "our Qa resource was on the new features. And we're worried about regression."

Speaking at CTO Craft in Amsterdam, our co-founder and Chief AI Officer [Vilhelm von Ehrenheim](https://www.linkedin.com/in/vilhelm-von-ehrenheim/) used Next.js to show why diff size says nothing here, since "if you update a library like Next.js, it probably touches your entire application, right?" The question afterwards is the one the PR has to answer: "If you did update Next.js, did the app actually work? Can I still execute all the different user flows that are important to us?"

## A policy for dependency pull requests

| Update | Example | What to run | Merge |
|---|---|---|---|
| Patch or minor, dev-only dependency | Linter, test runner, type definitions | Build and unit tests | Auto-merge on green |
| Patch, runtime dependency | Date library, HTTP client | Build, unit tests, end-to-end check on the flows the library reaches | Auto-merge on green, after a short release-age wait |
| Minor, framework or UI library | React, Next.js, Expo, component kit | End-to-end checks on every flow the library reaches | One reviewer |
| Major, anything that ships to users | Framework or runtime major version | Full flow coverage plus a read of the changelog | Two reviewers |
| Security update | Any Dependabot alert with a patch | As above by update type, but prioritised | Fast-tracked, never left in the queue |

Majors earn the stricter row because their changelogs say so. The Next.js 16 upgrade guide, for one, notes that [synchronous access to request APIs "is fully removed"](https://nextjs.org/docs/app/guides/upgrading/version-16). Expo's own upgrade guide tells you to [read the SDK changelogs](https://docs.expo.dev/workflow/upgrading-expo-sdk-walkthrough/) because they "contain important information about breaking changes, deprecations, and other changes that may affect your app."

## Dependabot auto-merge vs Renovate automerge: setup

Renovate auto-merges natively. Dependabot opens the PR and leaves merging to GitHub's auto-merge, switched on by an Actions workflow. Both wait on your required status checks, and that's the lever. An auto-merged update has to pass whatever you make a required check.

**Dependabot.** GitHub's docs show [auto-merge through a GitHub Actions workflow](https://docs.github.com/en/code-security/tutorials/secure-your-dependencies/automate-dependabot-with-actions) that reads the update type with `dependabot/fetch-metadata` and enables auto-merge for, say, `version-update:semver-patch`. GitHub recommends turning on "Require status checks to pass before merging" so nothing merges until the required checks pass. Use [groups](https://docs.github.com/en/code-security/tutorials/secure-your-dependencies/optimizing-pr-creation-version-updates) to batch related updates into one PR, so a set of five dev-tool bumps gets tested once. Dependabot's `cooldown` option is its release-age wait: with `semver-patch-days: 3`, a patch PR opens only three days after the release. Cooldown doesn't apply to security updates.

**Renovate.** Set `automerge: true` inside a `packageRules` entry with `matchUpdateTypes: ["minor", "patch"]`, and its [configuration docs](https://docs.renovatebot.com/configuration-options/) note that "most people would want to leave major dependency updates to a human." By default Renovate only auto-merges if every status check has succeeded. Add `minimumReleaseAge` to wait a few days before a new release is considered stable, which keeps you off a version that gets pulled. Renovate's docs point out that [npm packages under 72 hours old can still be unpublished](https://docs.renovatebot.com/configuration-options/#minimumreleaseage) and suggest three days.

**Security updates** follow the same rules but shouldn't sit. Dependabot opens a PR for [every open alert with an available patch](https://docs.github.com/en/code-security/concepts/supply-chain-security/dependabot-security-updates), and GitHub's [Octoverse 2025](https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/) found that projects with auto-merge rules "remediate vulnerabilities more consistently than those relying solely on manual review." With an automated end-to-end check as a required status, a security patch to a UI-facing package can merge the same day without anyone clicking through the app.

## Where the end-to-end check goes

Make it a required status check on dependency PRs that touch runtime or UI packages, running against a preview build of the PR. Then the auto-merge rules above wait for it without anyone remembering to.

Scope it to the flows the library can reach. A date-library patch needs the screens that format dates. A component-library minor needs every screen that uses its components. That scoping is [risk-based testing for pull requests](https://qa.tech/blog/risk-based-testing-pull-requests) applied to dependencies, and it picks end-to-end checks by flow, which [test impact analysis](https://qa.tech/blog/test-impact-analysis) handles poorly. A one-line lockfile bump to your framework puts every screen in scope.

## Using QA.tech on dependency pull requests

Triage has a real limit on dependency PRs. Rules read PR metadata and changed file paths, and nothing inside the diff. A linter bump and a React bump both change `package.json` and the lockfile, so their file paths look identical, and a rule has to match on the package or group name Dependabot puts in the title. With that in mind, write your [PR triage](https://docs.qa.tech/pr-testing/pr-triage) rules in QA.tech, an AI testing platform, around package and group names. Name your Dependabot groups, such as `dev-tooling` and `ui-framework`, and the rules can key off the group name. A policy matching the table above might read: skip pull requests opened by dependabot[bot] that only update dev tooling such as linters, test runners or type definitions; review updates to the UI framework, component libraries and runtime dependencies.

Dependency PRs that get through triage go to [dynamic PR testing](https://qa.tech/product/pr-testing). The agent traces which user flows the upgraded package can reach, re-runs the test cases on those flows against the preview build and adds test cases where a flow has none. Its pass, fail or unable-to-verify verdict lands as a GitHub check you can make required, so auto-merge waits for it. Skipped dependency PRs show the skip reason on the PR, so a bump that slipped past the rules is easy to spot.

## FAQ

**Should you auto-merge Dependabot pull requests?**
Yes for patch and minor updates to dev-only dependencies once CI is green. Runtime patches can auto-merge behind a required end-to-end check and a release-age wait. Framework and UI-library minors get one reviewer, and majors get two.

**How do you test a Dependabot pull request?**
Run the build and unit tests, then an end-to-end check against a preview of the PR on the user flows the updated library can reach. Make that check required so auto-merge waits for it.

**How often do dependency updates break applications?**
In a study of Maven Central, 5.0% of client projects broke on patch upgrades and 7.8% on minor ones. That only counts API breaks; visual and behaviour changes in UI libraries come on top.

**Renovate vs Dependabot: which is better for auto-merge?**
Renovate, if auto-merge is the main goal: `automerge`, `minimumReleaseAge` and per-rule matching are built into its config, and it [runs on GitHub, GitLab, Bitbucket, Azure DevOps and more](https://docs.renovatebot.com/). Dependabot is built into GitHub, ties security PRs to Dependabot alerts, and needs an Actions workflow to auto-merge. Both wait on your required status checks.

**Do Dependabot security updates need testing?**
Yes, the same as any update of that type. The difference is speed: an automated end-to-end check lets a security patch merge the same day instead of waiting in a queue.