GitHub Push Emails Stopped: Can Notification Settings Bring Them Back?
PR comment emails still reach your inbox, but the commit emails your team relied on stopped on October 15. What replaces them if you still want a message for every push?
- GitHub retired repository push emails on October 15, 2026.
- A push-triggered workflow with a separate email sender is one replacement option.
- Release and PR subscriptions remain distinct notification paths.
The repository push email feature has ended
Re-entering a recipient address will not restore the retired repository push email feed. GitHub ended the feature on October 15, citing spam and abuse enabled by sending messages without recipient consent.
The scope matters: this was the repository feature that emailed designated recipients when code was pushed. It is not the end of every GitHub email or every PR conversation notification. Identify which event the missing message used to report before changing settings.
Actions runs the job; a mail service sends the message
GitHub suggests a push-triggered Actions workflow that sends through your own SMTP server or email provider. That involves creating a delivery step, rather than transferring an address to another built-in notification field.
The push event can start a workflow for a commit or tag push. A branch filter narrows the scope. This event configuration targets main; it is not a complete email workflow.
on:
push:
branches:
- mainThe job still needs recipients, message content and an integration with the sender. Store an SMTP password or provider API key in Actions secrets, then pass it to the relevant step. Repository secrets can be added under Settings → Secrets and variables → Actions.
Operationally, separate three checks: whether the event occurred, whether the matching job ran, and whether the provider handled delivery. A single GitHub email preference no longer covers that whole chain.
Choose between branch activity, releases and PR conversations
If you only want to know when an open-source project publishes a version, a custom sender may be unnecessary. GitHub’s Watch settings support event selections such as Releases. Personal notification settings control whether those updates reach email.
| What you need | Route | Important distinction |
|---|---|---|
| Changes pushed to a branch | A push workflow and separate email sender. | You maintain filters and delivery. |
| Published project releases | Watch → Custom → Releases. | This does not report every commit push. |
| PR comments, reviews and changes | PR participation or subscriptions plus personal preferences. | This is separate from the retired repository feed. |
The personal notification documentation still includes Pull request pushes. That label is not interchangeable with repository push emails. If a release or PR notification is missing, investigate that subscription and its email preferences rather than assuming this retirement explains it.
A GITHUB_TOKEN push will not launch the follow-up workflow
Teams tracking automated commits need one additional check. Under GitHub’s workflow triggering rules, code pushed by a workflow using the repository’s GITHUB_TOKEN does not start a separate push-triggered workflow. This prevents recursive runs.
Before changing SMTP credentials, establish whether the notification job actually ran. The team can then decide whether delivery belongs in the original automation or needs a separate execution path.
The replacement starts with the information you need. Release subscribers can keep a narrower feed. Teams that need branch-change emails must configure both the event conditions and the delivery service.