By default GitHub emails people with write, maintain or admin access to a repository about new Dependabot alerts. Notifications cover new critical and high severity vulnerabilities, and GitHub says it does not notify when existing vulnerabilities are updated. Plan for that gap in your advisory routine.
What you receive
GitHub's documentation lists these channels:
| Channel | Behaviour |
|---|---|
| Web notifications in your inbox | Sent when Dependabot is enabled, when a new manifest file is committed, and when a new critical or high vulnerability is found |
| The same events, by email | |
| Command line | Warnings appear when you push to repositories with insecure dependencies |
| GitHub Mobile | Web notifications on the phone |
You can also choose a daily or weekly digest email that summarizes alerts for up to 10 of your repositories, which cuts noise for people who watch many repos. Notifications for new vulnerabilities are sent per organization, while enabling and manifest events are per repository.
What you do not receive
Three gaps matter to operations.
- Updates. GitHub says it does not send notifications when vulnerabilities are updated. A severity change, a corrected affected range or a newly added fixed version will not ping anyone.
- Medium and low severity. The documented triggers name critical and high only. Lower severity alerts exist in the repository but may not reach an inbox.
- Unreviewed advisories. GitHub's advisory database says Dependabot does not create alerts for unreviewed advisories, which are imported from the National Vulnerability Database without a check for validity or completeness.
Also note who is notified: people with write, maintain or admin permission. If your security team has read access only, they will not receive the email unless you configure it differently.
Closing the gaps
- Review the alert list weekly, not only the inbox. Sort by age and by severity.
- Route notifications to a shared channel or ticketing queue through an integration, so alerts do not live in one person's mailbox.
- Decide who owns medium and low severity alerts. A monthly sweep is a reasonable floor.
- Re-open items when a repository's advisory changes. Since there is no notification, a periodic re-read of critical items is the safeguard.
- Use organization level views to see all repositories at once, instead of reading repo by repo.
A minimal routine
Day one: confirm Dependabot alerts are enabled across the organization and that the right team members have access. Week one: choose email or digest for each person. Every week after: spend 20 minutes on the alert list, close what is fixed, assign what is not. Our guide to Dependabot alert triage for small teams walks through the triage itself.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how the dependency inventory lists each component with its findings. That is the cross-repository view the inbox cannot give you.
Safeguard does SBOM and dependency scanning with policy gates across repositories. You can test it with a free scan.
Quick check
Will I be told when an existing alert changes severity?
GitHub says it does not send notifications when vulnerabilities are updated, so re-check open alerts yourself.
Can I get a weekly digest instead of individual emails?
Yes. GitHub offers daily or weekly digest emails covering up to 10 repositories.
Sources
- GitHub Docs, Configuring notifications for Dependabot alerts
- GitHub Docs, About the GitHub Advisory database
Last reviewed: 19 October 2026.
