GitHub stopped repository push emails — the replacement moves consent, secrets and cost to you

As of October 15, 2026, GitHub has [retired email notifications for repository push events](https://github.blog/changelog/2026‑10‑15‑email‑notifications‑for‑repository‑push‑events‑have‑been‑retired/). GitHub says those messages are no longer sent and attributes the shutdown to spam and abuse: recipients did not have to consent before a repository could direct push emails at them. This is an immediate delivery change, not a future deprecation window. Teams that used the emails for deployment awareness, audit copies or operational handoffs should verify whether messages stopped rather than waiting for a warning banner. The removal does not affect every GitHub notification. It concerns the repository feature that emailed recipients on pushes. Issue, pull‑request, discussion and security‑notification behavior should be checked against their own settings and documentation.

GitHub recommends a GitHub Actions workflow triggered by `push` and connected to an organization’s own SMTP server or email provider. Its [workflow‑trigger documentation](https://docs.github.com/en/actions/reference/workflows‑and‑actions/events‑that‑trigger‑workflows) shows that `on: push` can run for every pushed branch or tag, and that branch, tag and path filters can narrow the events. That restores a technical path to email, but it changes ownership. GitHub no longer decides the recipient list, operates the sending infrastructure or absorbs the sending cost. The repository owner must define the event, recipient consent, content, credentials, rate limits and failure response. Start by asking what job the old message performed. A deploy pipeline may need a release or environment event rather than every commit. A human reviewer may need pull‑request status instead of raw push traffic. Recreating the old volume exactly can recreate the noise that made the feature easy to abuse.

A broad `on: push` workflow runs on pushes to any branch and tag unless filters narrow it. In a busy repository, that can produce duplicate or low‑value mail and consume Actions minutes. Define the smallest useful event set: for example, a protected deployment branch, a release tag or paths tied to a specific operational service. Add concurrency or deduplication where repeated pushes would create obsolete messages. Put the commit range, actor, repository and target ref in the body, but avoid dumping untrusted commit text into executable shell commands or HTML without safe handling. Test with a non‑production recipient list first. Confirm one qualifying push creates one message, excluded branches create none, retries do not duplicate delivery, and a provider outage leaves a visible failed workflow rather than a silent gap.

A replacement needs credentials for the chosen mail provider. GitHub’s [Actions secure‑use reference](https://docs.github.com/en/actions/reference/security/secure‑use) says sensitive values belong in secrets, credentials should have the least privileges required and `GITHUB_TOKEN` permissions should be minimized. It also warns that redaction is not guaranteed for every transformed value. Use a dedicated sender identity with constrained scope and an explicit rotation owner. Limit which repositories can access an organization secret, and consider an environment with required review if the workflow can contact a sensitive distribution list. Avoid personal mailbox passwords and credentials shared with unrelated automation. Treat third‑party actions as code in the delivery path. Pin reviewed dependencies, inspect what receives the credential and keep the mail secret out of command‑line output. A replacement that restores email while exposing a reusable SMTP token creates a larger incident than the missing notification.

Maintain a recipient source with an owner, purpose and unsubscribe process. A static address embedded in a public workflow can expose personal information; a broad distribution list can outlive the reason it was created. Record who approved the recipients and review the list on a fixed schedule. Monitor workflow success, provider acceptance and delivery separately. A green Actions job proves only what its steps checked. It does not establish that the provider accepted the message, that the mailbox received it or that a human acted on it. Use a bounded retry and an alternate alert for sustained failures so the email channel does not monitor itself. The retirement removes a convenient but consent‑light feature. Replacing it safely means sending fewer, more purposeful messages through infrastructure the organization can audit. Follow further GitHub platform changes on the [GitHub organization page](https://opentools.ai/organizations/github). *Image: Documentary capture of GitHub’s official October 15 retirement notice, reproduced without generative alteration or artificial upscaling.*