On the repository page, open the Watch menu in the upper right, choose Custom, and select only the event types you want, such as releases and security alerts. You will still hear about threads you take part in or are mentioned in, but not every issue and pull request.
Why this matters for dependencies
If you depend on a library, you rarely care about each issue comment. You care when a new version ships and when a security problem is announced. GitHub's notification documentation says you can choose to be notified of only certain event types for a repository: issues, pull requests, releases, security alerts or discussions, when enabled. Ignoring the rest keeps your inbox usable, which is what makes people keep the watch in place.
Steps
- Open the repository on GitHub.
- In the upper right, select the Watch drop down.
- Click Custom.
- Tick Releases and Security alerts. Leave Issues and Pull requests off unless you contribute.
- Apply the selection.
GitHub Mobile offers similar choices. Its documentation lists issues, pull requests, discussions and new releases among the event types you can pick.
One detail from the docs is worth knowing. If you select Issues, you are notified about every issue, including ones that existed before you made the selection. Custom is additive to participating and @mentions, so a narrow selection really is narrow.
Decide where the notifications land
A personal inbox is a weak place for a team dependency. Consider three options:
- A shared mailbox or channel that the on-call engineer reads.
- A bot account that watches the repositories and forwards to chat.
- A scanner that matches new advisories to your SBOM and opens a ticket.
The first two catch announcements. The third catches the ones that actually affect the versions you run.
What watching will not do
Watching a repository does not tell you whether you are affected. A release notice might be a feature, not a fix. An advisory might cover a version you do not use. Treat the notification as a prompt to check your inventory, not as a verdict.
It also does not cover projects that announce elsewhere. Some projects use a mailing list. See our overview of where maintainers announce security fixes to decide which to add.
A small routine that holds up
Pick your top ten dependencies by exposure. Set Custom watches on all ten in one sitting. Add a calendar reminder each quarter to review the list, remove projects you dropped, and add new ones. The list takes about fifteen minutes to set up and prevents the usual failure, which is relying on someone remembering to check release pages.
Where Safeguard fits
Safeguard keeps a continuously updated inventory from SBOM and dependency scanning, so a new advisory is matched to the versions in your repositories rather than to a watch list. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a new finding appears without anyone re-running a scan by hand.
Quick check
Will Custom watch settings hide notifications where I am mentioned?
No. The GitHub documentation describes Custom events as in addition to participating and @mentions, so you still get those.
Is watching enough to know I am affected by an advisory?
No. It tells you something was published. You still need to check your own version and usage against the advisory.
Sources
Last reviewed: 19 October 2026.
