After GitHub Repository Push Emails Stop in 2026, How Do You Verify Actions Notifications?

As of October 15, 2026, GitHub no longer sends its native repository Push event email notifications. If your team still needs them, use a push-triggered GitHub Actions workflow and verify delivery in a controlled inbox. This applies to your own repositories or repositories you are authorized to test; it does not restore GitHub’s built-in notification feature.

This is for independent developers replacing Push emails with a custom notification path.
It is also for repository maintainers configuring triggers and sending credentials, and QA or release owners who need evidence of actual receipt.

Last updated October 27, 2026. We checked the retirement date and replacement guidance against the GitHub Changelog notice, plus the current GitHub Actions workflow and security documentation.

After the retirement, keep the notification paths separate

GitHub’s change is specific: its Changelog says native email notifications for repository Push events were retired on October 15, 2026. It does not say that GitHub stopped sending every kind of email. GitHub’s suggested replacement is a push-triggered Actions workflow that sends mail through your own SMTP server or email service. That is a workflow you maintain, not a reactivation of GitHub’s native notification.

For the migration, treat the result as three separate checkpoints:

• Trigger: Did the intended push start the intended workflow?
• Sending: Did the workflow’s mail step hand the message to your configured sending service?
• Receipt: Did the message reach the test inbox you intended to monitor?

A green Actions run only addresses the workflow’s overall result. It does not, by itself, show that the correct branch matched, that the sending service accepted the message, or that a recipient mailbox received it. This distinction is the core of testing GitHub Actions notifications after GitHub Push emails stopped.

Before configuring anything, define who and what should receive mail

First, write down the notification audience and scope. Include the repositories, branches, and types of change that need an email. Don’t default to notifying every person about every push. A broad rule can turn useful alerts into noise, expose repository details to people who do not need them, and make later testing harder to interpret.

Use a test recipient that the team controls. Keep the message content deliberately plain: a test label, the repository or project identifier if appropriate, the branch, and a commit reference are usually enough to verify that the message corresponds to an event. Avoid including access tokens, environment variables, private configuration, or unnecessary commit content. Treat commit messages and repository names as potentially sensitive too; they can contain internal project details.

Write down the intended recipient and the reason that person or inbox needs the notification. This helps catch a common test mistake: verifying that a message arrived somewhere, without verifying that it went to the right destination. If the test recipient is temporary, don’t use it for account recovery or ongoing team communication. For handling data in test workflows, review the relevant privacy guidance and keep the message limited to what the test requires.

Record which branch should trigger the test and which branch should not. That gives you a positive test and a negative test. The positive case proves that an intended push can start the workflow. The negative case helps show that a branch outside the agreed scope does not produce an unwanted notification.

During setup, align the push event with the workflow file

A workflow must declare the event and filters that match your test plan. GitHub’s workflow syntax supports branch filters for push; the filter should reflect the branches you intend to monitor, rather than using a broad rule by accident. The workflow file also needs to exist on the branch where you expect GitHub to use it. Check the official workflow syntax reference for push filters when writing or reviewing the configuration.

For example, this skeleton subscribes to pushes on a dedicated test branch:

name: Test repository email notification

on:
  push:
    branches:
      - notify-test

jobs:
  notify:
    runs-on: ubuntu-latest
    steps:
      - name: Report the event under test
        run: |
          echo "Repository: $GITHUB_REPOSITORY"
          echo "Branch: $GITHUB_REF_NAME"
          echo "Commit: $GITHUB_SHA"

      - name: Send notification
        env:
          SMTP_HOST: ${{ secrets.SMTP_HOST }}
          SMTP_USERNAME: ${{ secrets.SMTP_USERNAME }}
          SMTP_PASSWORD: ${{ secrets.SMTP_PASSWORD }}
          TEST_RECIPIENT: ${{ secrets.TEST_RECIPIENT }}
        run: ./scripts/send-notification.sh

This is a wiring example, not a ready-made mail client. Your team must supply and test the final script using its chosen SMTP server or email service. The example’s secret names are placeholders; create only the values your sender actually needs. Review GitHub’s Actions workflow documentation to understand how workflows and jobs run.

Before running it, check that the test workflow is committed to the target branch. Compare the branch name in the filter with the branch you will actually push to. A typo or a file present only on another branch can make a correct-looking workflow irrelevant to the event you are testing.

Also decide whether the workflow should run for every push to the selected branch or only for specific paths or events. A branch filter limits which branches match; it does not automatically mean that every change on that branch is useful to notify. Choose the narrowest scope that meets the team’s need, then verify that scope with both an included and an excluded test case.

Before sending, restrict credentials and inspect the message

Store sending credentials in GitHub Actions secrets rather than in the workflow file, script, or repository. Pass secrets only to the step that needs them. Limit who can change the workflow and who can access the associated repository settings, then review GitHub’s guidance on using secrets and secure use of Actions.

Keep logs useful but non-sensitive. GitHub’s Actions contexts reference documents values available to a workflow, including repository and event context. Use only the values needed to identify the test event. Don’t print secret values, authentication headers, or full message payloads merely to make debugging easier.

Before triggering a run, review the actual recipient, subject, and body assembled by the send script. Confirm that the recipient is the controlled test address, not a team-wide list. Make sure the message identifies the test commit clearly enough for someone to match it to the workflow run. If your own notification process also creates commits or pushes changes, check whether those events fit the filter. Add a deliberate guard or narrower scope if a notification could generate another notification.

Check the sender configuration separately from the workflow syntax. Confirm that the host, authentication method, sender address, and recipient are configured for the service you actually use. Do not assume that a valid secret name means the value is valid, or that an accepted credential automatically authorizes every sender address. Keep test credentials limited to this sending purpose, and rotate or remove them when they are no longer needed.

During the test, gather evidence for trigger, send, and receipt

Make a harmless push that meets the selected branch filter. In the Actions run, verify the repository, branch, and commit associated with the event. These should match the change you made—not merely a recent successful run. If the workflow doesn’t start, check the event declaration, branch filter, file location, and run history before debugging mail delivery.

Next, inspect the sending step’s result. Capture enough information to identify the send attempt and its outcome, but redact credentials and sensitive content. If your sender reports an SMTP response, interpret that as evidence from the sending exchange, not proof of inbox placement. Under RFC 5321, reply code 250 indicates that the requested mail action completed successfully at that point in the protocol. It does not demonstrate that the message appeared in the intended user-facing inbox.

Finally, open the controlled test inbox and confirm the message itself. Check the recipient, subject, body, and commit reference. Look in spam or quarantine folders if the message is missing, and confirm that the address and any forwarding rules are correct. Record the result rather than assuming that “send succeeded” means “received.”

Use a compact receipt record for each test:

• Repository, branch, and commit under test
• Actions run or link to the run, plus whether the expected trigger occurred
• Sending-step result or provider response, with secrets removed
• Test recipient and whether the message was found in the inbox, spam, or quarantine
• Any delay or rejection observed, recorded as an actual observation rather than an assumed service guarantee

We are not claiming a live delivery-time measurement here. Your own record should show the platform or sender used, the time observed, and whether the controlled mailbox accepted or rejected the message. That gives the team evidence from its own path instead of an unverified timing promise. If you test with a forwarding address, check the destination inbox as well; a message visible in an intermediate inbox does not prove that forwarding reached the final destination.

For a repeatable test, keep the message identifier or another safe correlation value with the run record. Use the repository, branch, and commit to tell similar test messages apart. Avoid adding secrets or full private payloads to make correlation easier. The goal is to establish a traceable link between the triggering push, the send attempt, and the message seen by the recipient.

After receipt, test exclusions and preserve a clean record

Run the negative case on a branch that the filter excludes, using a harmless change. Confirm that it does not produce the notification workflow you intended to limit. If it does run, inspect the actual event and branch information rather than assuming the filter was applied as expected.

Review failure paths too. A test should make it possible to tell whether a failure occurred before the workflow started, during the send step, or after the sender accepted the message but before you found it in the mailbox. Keep diagnostic output specific enough to locate the failing stage, while excluding secrets and unnecessary repository data.

Then check for duplicate or looping notifications. Compare the event that started each run with the commit or push created during the process. If automation can make further pushes, add conditions that prevent an unintended repeat and test those conditions in the authorized repository. Keep the workflow’s trigger scope, recipient list, and credential access under review whenever the notification design changes.

For a concise acceptance decision, use this checklist:

• [ ] The workflow exists on the branch being tested.
• [ ] The push event and branch filter match the agreed notification scope.
• [ ] An in-scope test push starts a run tied to the expected commit.
• [ ] An out-of-scope test push does not send an unintended alert.
• [ ] The sender step uses protected credentials and does not expose them in logs.
• [ ] The sending result is recorded separately from inbox receipt.
• [ ] The controlled inbox contains the expected message, with no sensitive test data.
• [ ] The record identifies any duplicate, rejection, spam, or quarantine outcome.

Mark the notification migration as accepted only when the trigger, sending result, and actual receipt have each been checked. If the workflow passes but the inbox check fails, the trigger may be working while delivery remains unresolved. Keep that distinction in the handoff notes so the next person does not mistake a successful run for a completed email test.

FAQ

How can I send repository Push notifications with GitHub Actions now?

Create a workflow for your own or authorized repository and subscribe it to the required push event and branch filters. Add a mail-sending step that uses your SMTP server or email service, with credentials supplied through Actions secrets. This creates your own sending path; it does not restore GitHub’s retired native repository Push email notification.

Why did my GitHub Actions run succeed if no notification arrived?

A successful run proves that the workflow reached its successful end state, not that a recipient inbox received the message. Check the send step’s result and provider response, then inspect the test inbox, spam folder, and any quarantine or forwarding rules. Match the run to the intended recipient and message before treating the test as passed.

How do I check that a push branch filter triggers the right workflow?

Make a controlled push to a branch included by the workflow filter and confirm that the run references that branch and commit. Then push a harmless change to a branch excluded by the filter and confirm that no notification run starts for it. Check the workflow file on the target branch as well, because the workflow must be present where the event is expected to use it.

How can I confirm a test notification was actually received?

Use a controlled test address and look for the message in its inbox after the workflow and sending step finish. Record the run, commit, recipient, sender response, and inbox result separately. A successful SMTP handoff or provider API response is useful evidence of sending, but it is not proof that the intended recipient’s mailbox accepted and displayed the message.

For a test of your own repository, a separate controlled inbox is a sensible way to verify real receipt without exposing a personal address. Fwdaway can be one option for temporary test mail; keep the message free of sensitive repository details and judge the workflow by what the test inbox actually receives. If the address needs to remain reachable for account recovery or ongoing team replies, use a durable mailbox or a suitable email-forwarding setup instead.

Frequently asked questions

How can I send repository Push notifications with GitHub Actions now?

Create a workflow for your own or authorized repository and subscribe it to the required push event and branch filters. Add a mail-sending step that uses your SMTP server or email service, with credentials supplied through Actions secrets. This creates your own sending path; it does not restore GitHub’s retired native repository Push email notification.

Why did my GitHub Actions run succeed if no notification arrived?

A successful run proves that the workflow reached its successful end state, not that a recipient inbox received the message. Check the send step’s result and provider response, then inspect the test inbox, spam folder, and any quarantine or forwarding rules. Match the run to the intended recipient and message before treating the test as passed.

How do I check that a push branch filter triggers the right workflow?

Make a controlled push to a branch included by the workflow filter and confirm that the run references that branch and commit. Then push a harmless change to a branch excluded by the filter and confirm that no notification run starts for it. Check the workflow file on the target branch as well, because the workflow must be present where the event is expected to use it.

How can I confirm a test notification was actually received?

Use a controlled test address and look for the message in its inbox after the workflow and sending step finish. Record the run, commit, recipient, sender response, and inbox result separately. A successful SMTP handoff or provider API response is useful evidence of sending, but it is not proof that the intended recipient’s mailbox accepted and displayed the message.