GitHub release notifications: every way to get notified

On any repository's main page, open the Watch dropdown in the upper right and choose Custom. That opens a list of event types you can subscribe to independently, including Issues, Pull requests, Releases, Discussions, and Security alerts. Check Releases, uncheck anything you do not want, and confirm - you will get a GitHub notification every time that repo publishes a release, without picking up its issue and pull request traffic too.

This creates a normal GitHub notification, which shows up in your notifications inbox at github.com/notifications, in the GitHub Mobile app, or by email if you have routed watching notifications to email in your notification settings. It is the right choice when you personally want to track a handful of repos, including ones you do not maintain yourself.

The URL pattern is https://github.com/<owner>/<repo>/releases.atom. We verified this against microsoft/vscode's feed (https://github.com/microsoft/vscode/releases.atom) on 2026-07-28, which returned a valid Atom feed (HTTP 200, content-type application/atom+xml) with no login, no API token, and no authentication of any kind for a single anonymous fetch. Point any feed reader, or a script, at that URL for any public repo and you get its release history, newest first.

This is the cleanest option when you want release notifications outside GitHub's own notification system entirely: in a feed reader, an internal dashboard, or a script that polls the feed on a schedule. It is polling, not push - something has to fetch the URL periodically to notice a new entry, unlike a webhook, which is pushed to you the moment a release publishes.

GitHub's notification settings, under your account's Settings > Notifications, let you choose how to receive notifications for the things you watch: through the notifications inbox at github.com/notifications, in the GitHub Mobile app, through email, or a combination of these. If you route watching notifications to email and you set a repo to Custom > Releases as described above, a release publish reaches your inbox as an email.

This is convenient if you do not check github.com/notifications regularly, but it is still the same underlying watch subscription - it does not add a new source of release information, it just changes the delivery channel for the one you already set up.

GitHub's release webhook event fires on seven actions: created, deleted, edited, prereleased, published, released, and unpublished, per GitHub's webhook events and payloads documentation. For an announcement use case, published is almost always the one you want - it fires when a release, or pre-release, goes live, whether it started as a draft or not.

The payload's top-level keys are action (which of the seven actions triggered this delivery), release (the full release object: tag, name, body, author, and URLs), repository, and sender, plus organization, enterprise, and installation when applicable. A webhook receiver just needs to check that action equals published and then read the release object for the details.

Setting this up means configuring a webhook on the repository (under Settings > Webhooks) pointing at a URL you host and control, which is real infrastructure - unlike the Atom feed, you need something running to receive the POST. This is the path CI systems, chatops relays, and custom automation use, and it is exactly what a GitHub Actions workflow triggered on release: types: [published] is doing under the hood, without you hosting anything yourself.

A GitHub Actions workflow can trigger on the same release event as the webhook, without you hosting a receiver - GitHub runs it for you. Scoped to types: [published], it fires only when a release goes live, and from there the workflow can do anything: call an API, post to a chat tool, update a status page, or trigger a downstream build.

The release's fields (tag, name, body, URL) are available directly from the github.event.release context, the same context our GitHub-to-Slack and GitHub-to-Discord recipes read from - this is the shared mechanism behind both.

Every method above answers: how do I, or my automation, find out a release happened? None of them answer: how does someone who is not already watching my repo find out? Watch, the Atom feed, and email only reach people who chose to watch. The webhook event and GitHub Actions only reach whatever you build - and by default that is still an internal system, not a public announcement.

Turning a release into something that reaches people beyond your existing watchers - a changelog readership, LinkedIn, X, a public Discord, Bluesky - needs the release translated into channel-appropriate copy and published to platforms outside GitHub's notification system entirely. That is a separate job from detection, and it is the one S2P is built for: it uses the same release event described above as its trigger, drafts channel-native posts for the destinations you connect, and routes them through approval before anything goes out publicly.

If your need really is detection - you or your team finding out the moment something ships - the five methods on this page cover it completely and for free. If your need is announcement, see our GitHub-to-Slack and GitHub-to-Discord recipes for that half, or start from what building in public means if the audience you want to reach is the one following your public shipping story.