Updated 3 minutes ago

Share this article

Related News

GitHub’s agentic autofix can repair 25 code-scanning alerts in one draft pull request

Oct 16, 2026

GitHub’s agentic autofix can repair 25 code-scanning alerts in one draft pull request

GitHub’s generally available agentic autofix explores related files, proposes changes and reruns CodeQL before opening a draft PR. It works on default-branch alerts and uses AI Credits plus Actions minutes.

GitHubagentic autofixcode scanning

GitHub AI Scan is now generally available — but its findings cannot block merges

Oct 16, 2026

GitHub AI Scan is now generally available — but its findings cannot block merges

GitHub’s AI Scan can find pull-request vulnerabilities beyond CodeQL’s current language coverage. Its alerts are advisory, skip forks and Dependabot, and consume Code Security AI Credits.

GitHubAI Scancode scanning

GitHub Actions lockfiles pin the code behind workflow dependencies

Oct 14, 2026

GitHub Actions lockfiles pin the code behind workflow dependencies

GitHub Actions workflow lockfiles are in public preview for Enterprise Cloud. They pin direct and transitive action dependencies to reviewed commits while preserving readable workflow references.

GitHub Actionsworkflow lockfilessoftware supply chain

GitHub stopped repository push emails — the replacement moves consent, secrets and cost to you — Source: GitHub / official release page screenshot captured by OpenToolsSource image

Developer Operations

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

By OpenTools Team

GitHub no longer sends repository push‑event emails. Its suggested Actions replacement restores delivery, but repository owners must now manage recipients, SMTP credentials, failure handling and runner usage.

GitHub no longer sends email when a repository receives a push

As of October 15, 2026, GitHub has retired email notifications for repository push events. 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.

The suggested replacement is a push‑triggered Actions workflow

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 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.

Filter events before introducing a mail credential

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.

SMTP credentials become a repository security boundary

A replacement needs credentials for the chosen mail provider. GitHub’s Actions secure‑use reference 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.

Consent and observability are now part of the design

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.

Image: Documentary capture of GitHub’s official October 15 retirement notice, reproduced without generative alteration or artificial upscaling.

Sources

1.retired email notifications for repository push events (github.blog)
2.docs.github.com (docs.github.com)
3.docs.github.com (docs.github.com)

Tags

GitHubGitHub ActionsnotificationsSMTPdeveloper operations