Após o fim dos e-mails de push do GitHub em 2026, como manter as notificações do projeto?

Você deixou de receber por e-mail as atualizações de push de um repositório e não sabe se os alertas do projeto também pararam.

A saída mais rápida: desde 15 de outubro de 2026, o GitHub não envia mais os e-mails nativos de eventos de push. Um alias ou encaminhamento não restaura esse aviso. Se você só precisa acompanhar workflows que acionou, confira as configurações de notificações do GitHub Actions; se precisa de um e-mail para cada push, avalie um workflow próprio e um sistema de e-mail autorizado. O aviso oficial informa a data, o escopo e a alternativa sugerida.

Este guia é para você que acompanhava mudanças nos repositórios pela caixa de entrada, mantém projetos para clientes ou precisa definir quem responde pelos avisos de uma equipe. Se o projeto depende de um endereço duradouro para acesso e recuperação, trate a escolha do destinatário como parte da manutenção, não como um detalhe de cadastro.

Última atualização: 4 de novembro de 2026. As informações sobre a interrupção e as notificações do Actions foram verificadas no aviso do GitHub e na documentação oficial.

Antes da mudança: identifique o tipo de mensagem

“E-mail do GitHub” pode significar mensagens com origens diferentes. Separar essas origens evita que você altere um endereço sem resolver o problema real.

O envio encerrado era o aviso nativo associado a eventos de push em repositórios. A interrupção não significa que todos os e-mails do GitHub tenham parado. Notificações da conta e mensagens relacionadas a execuções do GitHub Actions são categorias distintas, com escopos e configurações próprios. O aviso do GitHub sobre o encerramento dos e-mails de push delimita a mudança; não a interprete como uma política geral para todos os avisos.

Também há uma terceira origem: um workflow que você ou sua equipe configurou para enviar uma mensagem. Nesse caso, o repositório pode disparar uma automação, mas o envio depende da lógica do workflow e do sistema de e-mail autorizado que ele utiliza. Esse fluxo não é o aviso nativo que foi encerrado.

A tabela ajuda a escolher por onde começar:

As notificações do Actions não devem ser tratadas como substitutas automáticas de cada aviso de push. A documentação de notificações do GitHub Actions descreve como conferir as preferências; a página sobre notificações para execuções de workflows delimita a relação entre notificações e execuções.

Depois do aviso: faça o inventário dos projetos

Antes de mudar configurações, registre como cada projeto envia informações hoje. Isso evita confundir uma preferência pessoal do GitHub com uma automação que pertence ao repositório.

Para cada repositório, anote:

• Qual evento precisa gerar um aviso: uma execução, uma falha, uma publicação ou cada push.
• Se a mensagem vinha de uma configuração nativa do GitHub ou de um workflow mantido pela equipe.
• Qual endereço recebe a mensagem e quem consegue acessá-lo.
• Quem verifica o conteúdo e quem assume a manutenção quando essa pessoa não está disponível.
• Se o destinatário precisa apenas receber ou também responder, arquivar e recuperar mensagens antigas.

Use nomes claros para identificar a finalidade de cada endereço, como “avisos de falha do projeto” ou “publicações do cliente”. Um alias pode ajudar a separar o tráfego ou identificar qual endereço foi usado em um cadastro. No entanto, ele é apenas um endereço de entrada: não gera notificações, não substitui um workflow e não recupera uma mensagem que deixou de ser enviada.

Considere uma situação comum: você trabalha em vários repositórios de clientes e recebe avisos em uma caixa compartilhada. Se todos os avisos chegavam por e-mail nativo de push, trocar essa caixa por um alias apenas muda o destino de mensagens futuras que existam. A equipe ainda precisa decidir quais eventos são importantes e de que forma cada um será comunicado.

No período de escolha: selecione a rota adequada

A decisão depende do que você precisa acompanhar, não de qual endereço parece mais conveniente.

Se a necessidade é saber o resultado de workflows que você acionou, comece pelas preferências do GitHub Actions. Consulte a documentação e confirme o escopo antes de concluir que a configuração abrange determinado repositório, organização ou pessoa. Se você quer receber somente falhas, verifique se essa opção está disponível para o seu caso e como a documentação define sua aplicação. Não suponha que todos os tipos de execução serão filtrados da mesma maneira.

Se você precisa de um aviso sempre que ocorrer um push, avalie um workflow que reaja ao evento de push. A referência oficial dos eventos que podem acionar workflows ajuda a verificar se o evento e as condições desejadas são suportados. A equipe ainda precisa criar e manter a automação e escolher um sistema de e-mail autorizado para enviar as mensagens.

Essa alternativa traz controle sobre o conteúdo e os destinatários, mas também acrescenta responsabilidade operacional. Alguém precisa revisar mudanças no workflow, manter a autorização do sistema de envio, identificar falhas e atualizar a lista de destinatários. Se o projeto não precisa de uma mensagem por push, usar notificações de execução ou outro canal já mantido pode exigir menos trabalho.

O encaminhamento tem um papel mais restrito. Ele pode direcionar uma mensagem que já foi enviada para outro endereço, conforme as regras do serviço de recebimento. Não cria uma mensagem de workflow, não transforma uma notificação de falha em um aviso por push e não substitui o sistema que envia o e-mail. Para entender essa distinção antes de escolher um endereço, consulte o guia de encaminhamento de e-mail e seus limites.

No meio da configuração: esclareça as dúvidas de recebimento

Ainda há um caminho para receber atualizações do repositório?

Há, mas não pelo e-mail nativo de eventos de push que foi encerrado. Você pode avaliar uma automação própria acionada pelo evento adequado e um sistema autorizado para enviar a mensagem. Antes de implementá-la, defina se cada push realmente precisa de e-mail ou se um aviso de execução, uma falha ou uma publicação atende à necessidade. Essa escolha reduz notificações redundantes e deixa explícito quem responde por manter o fluxo.

O que muda entre um aviso do Actions e uma mensagem por push?

O aviso do Actions se refere a uma execução de workflow e às notificações disponíveis para esse tipo de atividade. O e-mail nativo de push estava ligado ao evento de atualização do repositório. Um workflow pode usar o push como gatilho e enviar uma mensagem própria, mas essa é uma solução construída e mantida pelo projeto. Trocar o destinatário de uma notificação do Actions não muda o tipo de evento que ela representa.

Onde confirmar avisos somente para falhas?

Confira as configurações de notificações da sua conta e compare as opções exibidas com a documentação oficial do GitHub Actions. A disponibilidade e o escopo importam: uma preferência para execuções que você acionou não deve ser presumida como uma regra para todos os membros ou repositórios. Registre o que foi selecionado e teste com uma execução controlada antes de depender desse comportamento em uma rotina crítica.

O encaminhamento serve para mensagens criadas pelo projeto?

Pode encaminhar uma mensagem enviada pelo sistema configurado no workflow, desde que o destino aceite o e-mail e as regras de encaminhamento estejam ativas. Ele atua depois do envio. Portanto, se o workflow falhar ou não gerar a mensagem, não há conteúdo para encaminhar. Também não se deve confundir um encaminhamento para um endereço permanente com uma cópia de segurança ou garantia de entrega.

Antes da ativação: use uma lista de conferência

Marque cada item antes de considerar a nova rota pronta. Se você não conseguir responder a algum deles, resolva a lacuna antes de depender dos avisos.

• [ ] Registrei quais repositórios precisam de notificações e para que finalidade.
• [ ] Separei avisos de execução do Actions de mensagens para eventos de push.
• [ ] Confirmei nas configurações e na documentação quais workflows podem gerar notificações para minha conta.
• [ ] Se preciso de mensagens por push, defini o evento, as condições e o responsável pelo workflow próprio.
• [ ] Confirmei que o sistema de e-mail usado pela automação está autorizado e que alguém pode manter essa autorização.
• [ ] Verifiquei o endereço final de recebimento e se a pessoa responsável consegue acessá-lo.
• [ ] Testei se o conteúdo recebido identifica o repositório e a execução ou o evento correto.
• [ ] Registrei quem investigará falhas de envio e quem atualizará os destinatários.

Na validação: teste o caminho completo

Não conclua que a configuração está correta apenas porque o workflow aparece como concluído. O teste precisa cobrir a geração da mensagem e sua chegada ao endereço esperado. Use um repositório e uma execução que você possa acompanhar; confira se o destinatário recebe o conteúdo, se consegue reconhecer o projeto e se a mensagem corresponde ao evento que deveria notificá-lo.

Se houver encaminhamento, verifique também o destino final. Confirme que a pessoa responsável consegue acessar a caixa e que o endereço não depende de uma conta temporária que será abandonada. Para notificações importantes, registre o resultado observado e o momento do teste, mas não trate uma entrega bem-sucedida como garantia de entregas futuras. Filtros, permissões, autorização do sistema de envio e mudanças de configuração podem alterar o resultado.

Depois da ativação: mantenha a responsabilidade visível

Anote onde a configuração vive, quem é responsável por ela e qual endereço recebe as mensagens. Em projetos de equipe, prefira um processo de transferência que permita substituir o responsável sem depender de uma caixa pessoal inacessível. Se um cliente ou colega deixar o projeto, atualize as permissões e os destinatários antes que a mudança crie uma lacuna de monitoramento.

Reavalie a rota quando o projeto mudar de responsável ou quando a documentação do GitHub atualizar as opções de notificação. A conclusão confirmada aqui é específica: o e-mail nativo para eventos de push foi encerrado em 15 de outubro de 2026, mas isso não equivale ao fim de todos os e-mails do GitHub. Se o aviso oficial ou as configurações documentadas mudarem, revise a distinção entre notificações do Actions e mensagens próprias antes de alterar os endereços.

Para um cadastro pontual, um teste ou o recebimento de uma única mensagem que não exige histórico duradouro, o MsgGone pode ser uma alternativa para não informar seu endereço principal. Isso não recupera o aviso de push encerrado nem substitui um endereço acessível para notificações recorrentes, recuperação de contas ou comunicação da equipe. Para projetos contínuos, defina primeiro a origem do aviso e o responsável pelo recebimento; depois, consulte o guia de encaminhamento de e-mail para avaliar se ele se encaixa no trajeto escolhido.

Perguntas frequentes