Interrupção do serviço Heroku da Salesforce: o que acontece com os aplicativos implantados?

Em 16 de setembro de 2026, o snapshot público da API de Status do Heroku mostrava os aplicativos , dados e ferramentas como "verdes", sem incidentes ativos listados. Essa é apenas uma verificação pontual, não uma garantia de que todos os aplicativos, regiões ou dependências estejam íntegros. O Heroku agora identifica a página de status do Heroku da Salesforce Trust como o principal canal para comunicações sobre incidentes e manutenção, enquanto a API de status legada continua útil para uma verificação rápida por meio de programação.

Há também um importante desenvolvimento em nível de plataforma por trás da questão da indisponibilidade. Em sua atualização de 6 de fevereiro de 2026, a Heroku afirmou ter migrado para um modelo de engenharia de sustentação focado em estabilidade, segurança, confiabilidade e suporte. A Heroku descreveu a plataforma como estando em suporte ativo e pronta para produção, e afirmou que os clientes de cartão de crédito existentes não devem perceber nenhuma alteração nos preços, faturamento, serviço ou uso diário. Esse anúncio é uma atualização sobre o ciclo de vida e investimentos — não uma declaração de que os aplicativos implantados serão desativados.

O que uma interrupção do Salesforce Heroku pode realmente afetar.

"Interrupção do Heroku" não é um único tipo de falha. As próprias categorias de serviço do Heroku separam a plataforma em Aplicativos, Dados e Ferramentas. O impacto prático depende de qual camada foi afetada e se o seu aplicativo pode continuar funcionando sem ela.

Impacto em aplicações já implementadas

1. Um aplicativo em execução pode permanecer acessível.

Um problema no plano de controle ou na ferramenta de implantação não significa automaticamente que todos os dynos em execução parem de atender requisições. A documentação do ciclo de vida de aplicações do Heroku explica que os dynos web recebem tráfego HTTP através dos roteadores do Heroku, enquanto os dynos worker processam tarefas em segundo plano. Se o componente afetado for o painel de controle, a CLI ou o caminho de implantação, uma aplicação web existente pode continuar respondendo mesmo que um operador não consiga implantar, escalar, inspecionar logs ou alterar a configuração normalmente.

O inverso também é possível: um serviço de Ferramentas pode estar funcionando corretamente enquanto um incidente em Aplicativos ou roteamento torna a URL pública indisponível. É por isso que uma visualização verde do painel — ou uma falha no login do painel — não deve ser considerada uma verificação completa da integridade do aplicativo.

2. Falhas de dados podem transformar uma interrupção parcial em um incidente comercial.

Se o processo do aplicativo estiver em execução, mas seu banco de dados ou fila estiver comprometido, os usuários poderão ver uma página que carrega sem os dados atuais, falhas no envio de formulários, tentativas duplicadas ou atrasos no processamento. Uma página somente leitura pode parecer normal enquanto o processo de finalização da compra, alterações na conta ou processamento de pedidos aguarda silenciosamente.

Não responda a todos os erros de banco de dados aumentando o número de tentativas. Uma tempestade de tentativas pode aumentar a carga e criar trabalho duplicado quando o serviço se recuperar. Prefira tentativas limitadas e idempotentes; pause atividades em lote não essenciais, se o seu manual de operações permitir; e registre quais operações foram concluídas, falharam ou permanecem desconhecidas.

3. A confiança na implantação pode ser menor do que a confiança em tempo de execução.

Durante uma interrupção do Heroku que afete pushes do Git, a API de Deployment, a infraestrutura de build ou os logs, um desenvolvedor pode não conseguir comprovar se uma versão chegou à produção. Executar novamente o mesmo deploy pode gerar confusão ou produzir múltiplas versões difíceis de conciliar. Capture o identificador do commit, o número da versão (se disponível), a saída do comando local e os timestamps. Aguarde um sinal oficial de recuperação antes de tentar um deploy de verificação controlado.

4. A conectividade com o Salesforce é uma dependência separada.

Um incidente relacionado ao Salesforce não necessariamente interrompe os dynos web que hospedam um aplicativo Heroku. No entanto, um aplicativo que depende da autenticação do Salesforce, chamadas de API, sincronização do Heroku Connect ou fluxos de trabalho orientados a eventos ainda pode ser significativamente prejudicado. A pergunta correta não é simplesmente "O Heroku está fora do ar?", mas sim "Qual jornada do usuário depende de qual serviço e quais dados podem ser adiados com segurança?".

Como diagnosticar o problema sem piorá-lo

1. Verifique os dois canais oficiais. Comece pelo Salesforce Trust for Heroku e pela API de Status do Heroku . As orientações de status do Heroku indicam que você deve entrar em contato com o suporte quando nenhum incidente for publicado ou quando os sintomas relatados não corresponderem ao seu problema.
2. Faça o teste a partir de fora da rede do escritório. Use uma verificação sintética externa ou uma conexão separada para testar o URL público, um endpoint de integridade simples e uma ação representativa do usuário. Isso permite distinguir um evento da plataforma de um problema local de DNS, firewall ou VPN.
3. Classifique a operação com falha. A falha está no roteamento, em um processo de dyno, em uma consulta de banco de dados, em uma implantação, em um registro de logs ou em uma API externa? Um mapa de serviços simples impede que uma equipe migre um aplicativo que, de outra forma, estaria funcionando corretamente, porque uma dependência está indisponível.
4. Reduza as mudanças arriscadas. Congele lançamentos não essenciais, edições de configuração, alterações de complementos e experimentos de escalabilidade até que o estado da plataforma esteja mais claro. Preserve as evidências em vez de alterar várias variáveis ​​de uma só vez.
5. Proteja os fluxos de trabalho dos clientes. Se for seguro, mude para um modo somente leitura, adie tarefas não críticas, exiba uma mensagem de manutenção explícita ou desative uma integração com falhas. Torne o comportamento degradado visível em vez de aceitar solicitações que não podem ser concluídas de forma confiável.
6. Reconcilie após a recuperação. Verifique gravações, filas, tarefas agendadas, webhooks, sincronização com o Salesforce e callbacks de terceiros. Uma resposta HTTP 200 após a recuperação não comprova que todos os fluxos de trabalho em segundo plano foram atualizados.

Qual opção de resiliência se adequa à sua aplicação?

Não existe uma arquitetura de resposta ideal única. O investimento certo depende do custo do tempo de inatividade, dos requisitos de durabilidade dos seus dados e da complexidade operacional que sua equipe consegue suportar.

O failover multirregional ou multi-provedor só é valioso quando testado de forma independente. Um ambiente de espera que compartilha o mesmo provedor de identidade, DNS, armazenamento de dados, segredos ou pipeline de implantação pode falhar juntamente com o primário. Por outro lado, uma implantação simples no Heroku com bom monitoramento externo e um modo de degradação bem definido pode ser a opção mais confiável para uma equipe pequena que não pode operar duas plataformas.

O que a atualização do Heroku de 2026 significa para os aplicativos implantados

O modelo de engenharia de sustentação altera as expectativas em relação à evolução da plataforma mais do que altera o comportamento imediato de um aplicativo existente. A Heroku afirma que seu foco é a operação e o suporte estáveis, seguros e confiáveis, com novos trabalhos alinhados aos objetivos de sustentação. Para as equipes que já executam aplicativos em produção, a mensagem verificada para o cliente é a de continuidade: a funcionalidade principal permanece disponível e os clientes de cartão de crédito não precisam alterar seu uso diário por causa desse anúncio.

A escolha é estratégica. Organizações que optam pelo Heroku para rápida adoção de novos recursos abrangentes da plataforma devem analisar cuidadosamente o roteiro e as opções de contrato. Já as organizações que priorizam uma experiência de implantação gerenciada, primitivas de aplicativos maduras e administração de infraestrutura reduzida podem ter uma visão diferente de um modelo focado em estabilidade. O Heroku também informou que novos contratos de Contas Empresariais não serão mais oferecidos a novos clientes, enquanto as assinaturas e o suporte Empresariais existentes serão honrados e poderão ser renovados. Isso é importante para decisões de aquisição e arquitetura futura, mas não indica uma interrupção ou um risco automático para os aplicativos atualmente implantados.

Resumindo

A última verificação oficial, datada de 16 de setembro de 2026, não apresentou incidentes ativos no Heroku, e o anúncio de suporte contínuo do Heroku para 2026 descreveu a continuidade do suporte à plataforma. Caso ocorra uma interrupção, o impacto em um aplicativo implantado depende da camada afetada: os aplicativos podem afetar a disponibilidade, os dados podem ser afetados pela correção e pelo trabalho em fila, as ferramentas podem afetar a implantação e a observabilidade, e as dependências do Salesforce ou de terceiros podem interromper fluxos individuais, mesmo que o próprio aplicativo permaneça online.

Use o Salesforce Trust como a principal fonte de incidentes, compare-o com a API de status pública, teste o caminho real do usuário fora da sua rede e classifique a dependência antes de tomar qualquer ação. Escolha failover, degradação controlada ou uma resposta de espera e verificação de acordo com seu objetivo de recuperação — não porque toda interrupção do Heroku exija a mesma solução.

Referências oficiais

• Heroku: Uma atualização sobre o Heroku (6 de fevereiro de 2026)
• Centro de desenvolvedores Heroku: Status do Heroku (atualizado em 21 de outubro de 2025)
• Salesforce Trust: Status do produto Heroku
• API de status do Heroku: instantâneo do status atual
• Centro de desenvolvimento Heroku: Ciclo de vida do aplicativo Heroku