By default, GitHub emails Dependabot alerts to people who have write, maintain or admin permission on a repository and are watching it with security alerts or all activity enabled. Alerts fire when a new advisory is added to the GitHub Advisory Database or when your dependency graph changes.
When alerts are sent
GitHub's documentation says Dependabot scans a repository's default branch and sends alerts in two cases:
- A new vulnerability is added to the GitHub Advisory Database.
- Your dependency graph changes, for example when you push commits that update packages or versions.
The first case matters for threat intelligence. Nothing in your code changed, but the world did, and the alert is how you hear about it.
Who receives the email
The documentation gives two conditions, and a person must meet both:
- They have write, maintain or admin permissions on the repository.
- They are watching the repository and have enabled notifications for security alerts or for all activity.
People can change this at their personal notification settings, choose a different notification type, or switch alerts off. So a repository can have alerts enabled and still reach nobody if no one with write access is watching it.
A detail that surprises teams
When Dependabot is first enabled, GitHub does not send notifications for every vulnerable dependency it finds at that moment. You are notified about new vulnerable dependencies identified after enabling, if your preferences allow it. So the alerts page may show a backlog that never arrived by email. Read the alerts tab once at the start.
Ownership and assignment
The documentation says people with write access or higher can assign alerts to collaborators or teams, so each alert has an owner, and you can filter by assignee. It also describes assigning alerts to supported AI agents, which then open a draft pull request. Treat any such pull request like any other change, with review.
A setup checklist
| Check | Why |
|---|---|
| Alerts enabled for the org or repo | Nothing runs without it |
| At least two people with write access watching security alerts | Avoids a single point of silence |
| A shared mailbox or chat integration | People change roles and leave |
| An assignee on each open alert | Prevents alerts from aging unseen |
| A monthly look at the alerts tab | Catches the backlog and anything missed |
Turning alerts into tasks
An alert is a prompt, not a decision. For each one, read the advisory, check the fixed version, and ask whether the vulnerable code is used. Then merge a fix, or record why it is not needed. See how to ignore a dependency advisory without hiding real risk for wording.
Try it yourself
Click through it at your own pace, or open it full screen. Look for how a monitor re-checks stored inventory when new advisory data arrives.
Where Safeguard fits
If you want advisory checks beyond a single hosting platform, Safeguard's SBOM and dependency scanning and its policies and gates can apply the same checks across repositories. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Why did I get no email when we turned alerts on?
GitHub does not send notifications for every existing vulnerable dependency at enablement. Check the alerts tab for the backlog.
Can a repo have alerts on and still notify nobody?
Yes. If nobody with write access is watching with security alerts enabled, no default email goes out.
Sources
- About Dependabot alerts, GitHub Docs, fetched 19 October 2026.
Last reviewed: 19 October 2026.
