Read a Dependabot pull request in this order: the title for what and which version, the files for scope, the checks for breakage, and the body for release notes and the commands section. Most take two minutes. Slow down for major versions, new install scripts, or unfamiliar publishers.
Step 1: the title
The title names the package and the version range. Note whether it is a patch, minor or major bump. Major bumps are where behavior changes, so they deserve more time. If you set a commit message prefix in your configuration, GitHub's documentation says Dependabot adds it to commit messages and pull request titles, which helps you filter by eye.
Step 2: the files
Open the Files tab. For a normal update you should see a manifest and a lockfile. Anything else is a question. For lockfile specifics, see how to review a lockfile only security pull request.
Step 3: the checks
Look at your required status checks. A green run is a signal, and only as good as your tests. If checks fail, work out whether the update broke something or whether the failure is unrelated. If the branch is stale, GitHub says Dependabot rebases automatically by default, and stops rebasing a pull request that has not been merged for 30 days.
Step 4: the body
Look in the body for any release notes or changelog excerpt the update includes, and for the section called "Dependabot commands and options", which GitHub's documentation says lists the commands you can use on the pull request. Skim whatever notes are there for words like breaking, removed, deprecated, security and minimum version.
Step 5: decide
| What you see | Reasonable action |
|---|---|
| Patch bump, checks green, no scripts | Merge |
| Minor bump, checks green | Skim release notes, then merge |
| Major bump | Read the migration notes, test locally |
| Checks red | Investigate before anything else |
| Unfamiliar publisher or new install script | Pause and verify the release |
Useful commands
Comment @dependabot rebase to rebase. Comment @dependabot recreate to recreate the pull request, which overwrites any edits you made. Comment @dependabot ignore this dependency to close it and stop further pull requests for that dependency unless you reopen it. The full list is in Dependabot comment commands: a maintainer cheat sheet.
Security update or version update
Both look alike in the list. Security updates respond to an alert and raise the pull request to the minimum version that includes the patch, per GitHub's description. Version updates keep dependencies current whether or not there is a vulnerability. If you are not sure which you have, the alert link in the body of a security update tells you. For the difference in detail, see Dependabot alerts versus security updates versus version updates.
Where Safeguard fits
Safeguard's reachability analysis can tell you whether the vulnerable code in a security update is actually used, which helps you prioritize your two minutes. Try the free scan at https://gold.safeguard.sh/scan.
Quick check
Should I merge a green patch bump without reading anything?
For well tested projects with a trusted publisher, many maintainers do. A quick look at the files still costs little.
Why did Dependabot stop updating my old pull request?
GitHub's docs say it stops rebasing after 30 days without a merge, or once someone pushes extra commits to the branch.
Sources
- Managing pull requests for dependency updates, GitHub Docs
- Dependabot pull request comment commands, GitHub Docs
- About Dependabot security updates, GitHub Docs
- Dependabot options reference, GitHub Docs
Last reviewed: 19 October 2026.
