GitHub stopped sending repository push-event emails on October 15. Its announcement points to a push-triggered Actions workflow and your own SMTP service or email provider as a replacement. GitHub attributes the retirement to spam and abuse concerns. Official announcement.
Before rebuilding that mechanism, find out what the old email did for your team.
Ask what decision the message supported
Was it an activity digest, a deployment signal, a reminder to review a branch, or simply an inbox habit? Each answer suggests a different message and audience.
For example, a release manager may need a confirmed deployment outcome. A push notification alone cannot establish that the deployed application passed its checks. Replacing the transport without examining the purpose can preserve that ambiguity.
Make delivery observable
For a replacement you control, I would record the triggering commit, workflow run, intended recipients and delivery outcome. Use a recognisable test event and ask one intended recipient to confirm arrival before expanding distribution.
Decide what happens when delivery fails. An error visible only inside the sender's workflow may go unnoticed by the people who expected the message. An explicit owner and a documented fallback are easier to evaluate than an assumption that somebody will notice silence.
Keep the message useful
Prefer a subject that names the repository and event. Include the relevant commit or run link, explain why the recipient receives the message, and avoid copying sensitive build output into an email body.
This is a suggested migration checklist, not a claim that another GitHub notification feature was removed. Check the specific dependency on repository push-event emails before making changes to an existing notification setup.
Top comments (0)