GitHub parou de enviar e-mail após push: como substituir

Resposta rápida

O GitHub encerrou em 15 de outubro de 2026 o envio nativo de e-mails para eventos de push em repositórios. Se esses avisos sumiram nessa data, não trate primeiro como falha da sua caixa, regra de spam ou incidente da plataforma: o recurso foi retirado para impedir abuso, porque destinatários podiam receber mensagens sem consentimento prévio.

Para continuar recebendo um alerta por e-mail, o caminho recomendado pelo GitHub é um workflow do Actions acionado por push e conectado ao seu próprio servidor SMTP ou provedor de e-mail. Quando o destino não precisa ser e-mail ou muitos repositórios usam a mesma integração, um webhook de repositório, organização ou GitHub App costuma ser mais adequado. Em ambos os casos, limite branches e destinatários antes de ativar.

O que acabou e o que continua funcionando

A mudança atinge a função específica que enviava um e-mail quando ocorria um push. Ela não desativa o evento push, os webhooks, os workflows do GitHub Actions, a página de commits nem as notificações de conversas, pull requests, issues ou execuções de workflow configuradas separadamente.

Também não há uma opção escondida para reativar o remetente antigo. Alterar Watch para All Activity não recria necessariamente um e-mail para cada push, porque as assinaturas do GitHub são voltadas às atividades de notificação suportadas pelo produto. Se o requisito é auditar cada atualização de branch, crie um fluxo explícito e controlado.

Escolha entre Actions e webhook

Use GitHub Actions quando a regra pertence a um repositório, o volume é moderado e a equipe já administra workflows. O gatilho push aceita filtros por branch, tag e caminho; o job pode montar uma mensagem curta e chamar a API do provedor de e-mail. O histórico de execuções facilita descobrir se o gatilho rodou e em qual etapa falhou.

Use webhook quando vários sistemas precisam do mesmo evento, quando a entrega deve entrar em uma fila própria ou quando você quer centralizar regras de muitos repositórios. O GitHub envia um POST para o endpoint cadastrado. Seu servidor valida a assinatura, reconhece o evento e decide se deve enviar e-mail, abrir incidente ou apenas registrar a atualização.

• Um repositório e poucas regras: comece com GitHub Actions.
• Muitos repositórios ou consumidores: prefira webhook de organização ou GitHub App.
• Notificação para colaboração, auditoria ou deploy: não force e-mail quando outro canal representa melhor o evento.
• Alerta somente para falha de CI: use a notificação de execução do Actions em vez de avisar cada push.

Como substituir com GitHub Actions

Crie um arquivo em .github/workflows e use o evento push. Aplique branches para limitar o alerta, por exemplo à main e a branches de release; use paths ou paths-ignore quando só determinadas áreas importarem. No job, envie assunto, repositório, branch, autor, SHA e URL do commit para o provedor. Evite anexar o diff inteiro ou dados de arquivos.

O token ou a senha do provedor deve ficar em Actions secrets, nunca no YAML, no texto do e-mail ou em saída de log. Prefira um token dedicado com permissão apenas de envio e restrinja remetente e destinatários no próprio provedor. Se uma action de terceiros for usada, revise o repositório e fixe a referência em um commit; chamar a API oficial do provedor diretamente reduz uma dependência de cadeia de suprimentos.

• Defina on.push com branches, tags e paths que realmente precisam de alerta.
• Configure concorrência ou agrupamento para evitar uma enxurrada de mensagens em pushes rápidos.
• Armazene a credencial do provedor em Actions secrets e conceda permissões mínimas ao GITHUB_TOKEN.
• Monte o conteúdo sem executar mensagens de commit ou nomes de branch como comandos de shell.
• Use o SHA ou o run_id como identificador para não reenviar o mesmo alerta em uma repetição.
• Teste em uma branch temporária e só depois habilite o destinatário de produção.

Como substituir com webhook

Em Settings, Webhooks, adicione a URL HTTPS do receptor e selecione somente o evento push. A API REST também permite criar e administrar webhooks; para criar um hook de repositório, o token fine-grained precisa da permissão Webhooks em escrita. Mantenha a verificação de certificado habilitada.

Defina um segredo aleatório para o webhook e valide X-Hub-Signature-256 com HMAC-SHA256 antes de processar o corpo. Compare a assinatura de forma resistente a ataques de tempo e use X-GitHub-Delivery como chave de idempotência. Responda rapidamente, coloque o trabalho em uma fila e não confie em branch, autor ou mensagem de commit como entrada segura.

• Crie um endpoint HTTPS dedicado e um segredo exclusivo para a integração.
• Cadastre somente o evento push e o escopo necessário.
• Valide a assinatura antes de analisar ou armazenar o payload.
• Registre o identificador de entrega e descarte duplicatas já processadas.
• Enfileire o envio do e-mail e devolva a resposta HTTP sem esperar o provedor concluir.
• Restrinja logs para não expor payloads, endereços ou credenciais.

Evite spam, vazamento e alertas inúteis

O motivo da retirada foi justamente a possibilidade de mensagens indesejadas. Não replique o problema com uma lista ampla: documente quem pediu o alerta, ofereça um modo de saída e defina um limite de frequência. Para equipes, um resumo por janela ou um alerta apenas na branch protegida costuma ser mais útil que um e-mail por commit.

Considere o conteúdo do push não confiável. Mensagens de commit, nomes de branch e nomes de autor podem conter texto inesperado. Faça escape para HTML, limite tamanho e crie links a partir do domínio conhecido do GitHub. Nunca inclua secrets, patches de arquivos privados ou o payload completo no e-mail.

Como diagnosticar quando o novo alerta não chega

No Actions, abra a aba Actions e procure uma execução para o SHA. Se não existir, revise branch, tag, paths, arquivo do workflow e origem do push. Um push feito por um workflow com o GITHUB_TOKEN não inicia outro workflow de push, proteção que evita loops; se esse for o fluxo, redesenhe a automação em vez de ampliar o token sem necessidade.

Em um webhook, abra Recent deliveries. Ausência de entrega aponta para escopo, evento ou limite; uma entrega com erro indica que o GitHub tentou chamar o endpoint. Confira status HTTP, tempo de resposta, DNS, TLS e logs pelo X-GitHub-Delivery. O GitHub permite redelivery manual ou pela API, mas seu receptor ainda precisa tratar idempotência.

• Confira o GitHub Status para Actions, Webhooks e API antes de alterar a configuração.
• Confirme o SHA, a ref e o horário exato do push.
• No Actions, veja se o workflow foi ignorado por filtro ou se o job falhou no provedor.
• No webhook, veja a entrega recente, a resposta do endpoint e o identificador X-GitHub-Delivery.
• Valide DNS, HTTPS e certificado do receptor quando houver timeout ou falha de conexão.
• Reenvie somente depois de confirmar que a entrega anterior não produziu o e-mail.

Limitações e próxima ação útil

Este guia foi verificado em 16 de outubro de 2026. Ele trata do GitHub.com e da retirada anunciada pelo GitHub; instalações do GitHub Enterprise Server podem ter versões e comportamentos próprios. Actions consome minutos e está sujeito a políticas do repositório, enquanto webhooks exigem um endpoint seguro, observável e disponível. A página de status mostra incidentes amplos, não confirma se o seu filtro ou provedor de e-mail está correto.

Faça agora um inventário dos repositórios que dependiam do e-mail antigo, identifique destinatários e elimine alertas sem proprietário. Escolha um repositório de baixo risco, limite o gatilho à branch principal, envie para uma caixa de teste e valide um push, um push ignorado e uma repetição. Só então replique a solução com secret, idempotência e responsável definidos.

Fontes consultadas

Os links abaixo servem para conferir conceitos, orientações oficiais e o critério editorial usado neste conteúdo.

• Email notifications for repository push events have been retiredGitHub Changelog
• Events that trigger workflowsGitHub Docs
• About webhooksGitHub Docs
• Creating webhooksGitHub Docs
• Best practices for using webhooksGitHub Docs
• Validating webhook deliveriesGitHub Docs
• Troubleshooting webhooksGitHub Docs
• GitHub StatusGitHub