Um alerta de emergência pode chegar a milhões de celulares e ainda assim falhar: basta que as pessoas parem de prestar atenção. Esse é o risco da fadiga de alertas. Na minha experiência com sistemas de software, notificações demais não aumentam automaticamente a segurança; sem relevância, contexto e critérios de escalonamento, elas desgastam a confiança que torna um aviso útil.
Segundo o Terra.com.br, uma reportagem do jornal mineiro O Tempo ensinou leitores a desativar alertas da Defesa Civil. O episódio não é só uma discussão editorial. Ele expõe uma questão de produto e engenharia: como entregar avisos urgentes sem transformar o canal em ruído?
O que é fadiga de alertas e por que ela afeta sistemas de emergência
Alert fatigue, ou fadiga de alertas, acontece quando mensagens frequentes, irrelevantes ou mal calibradas perdem a capacidade de chamar atenção. A reação pode ser ignorar o aviso, reclamar, desativar notificações ou deixar de confiar no sistema justamente quando surge um risco real.
O material do Terra cita um estudo publicado em 2025 sobre a percepção de gestores de emergência e integrantes do público. Entre os fatores associados à fadiga estão a frequência e a relevância dos avisos, além do conteúdo das mensagens. O ponto importante para quem desenvolve sistemas é que a entrega técnica é apenas uma parte do resultado.
Um alerta enviado com sucesso não prova que alguém o leu, entendeu o risco e tomou uma atitude de proteção. Por isso, métricas como mensagens enviadas e taxa de entrega precisam ser acompanhadas por indicadores de compreensão e comportamento — quando esses dados puderem ser coletados de forma ética e confiável.
Defesa Civil Alerta: cobertura não é o mesmo que efetividade
O Defesa Civil Alerta usa a rede de telefonia celular para enviar mensagens a aparelhos compatíveis conectados às redes 4G ou 5G em uma área de risco, sem exigir cadastro prévio. Isso é diferente de um aplicativo que depende de instalação, permissão de notificações e uma lista de usuários inscritos.
Essa diferença importa. Um sistema baseado em cadastro pode não alcançar quem não instalou o app ou não autorizou notificações. Já um mecanismo de difusão celular pode atingir aparelhos dentro da área definida pela rede, mas não garante que cada pessoa esteja olhando para a tela, compreenda a mensagem ou consiga seguir a orientação.
Também não devemos misturar tecnologias só porque todas aparecem como notificações no celular:
- Difusão celular: transmite avisos a aparelhos em uma área atendida pela infraestrutura móvel. Não depende de uma inscrição individual em um aplicativo.
- Push de aplicativo: depende de app instalado, permissão concedida, token válido e conectividade com os serviços da plataforma.
- SMS: pode alcançar celulares sem aplicativo específico, mas é uma mensagem individualizada e sujeita a limitações de entrega, volume e infraestrutura.
- E-mail e canais sociais: ajudam na comunicação complementar, mas não devem ser tratados como substitutos garantidos de um canal de emergência.
Na arquitetura, isso significa que não existe um único “botão de enviar” capaz de resolver a comunicação de risco. Cada canal tem alcance, latência, dependências e limitações diferentes. O sistema precisa escolher o canal adequado e manter mensagens consistentes entre eles.
Como projetar notificações sem criar ruído
Quando desenho um sistema de notificações, começo pela decisão que a mensagem deve provocar. “Há risco na região” pode ser verdadeiro, mas ainda deixa dúvidas: qual região, qual perigo, quando começa e o que a pessoa deve fazer agora?
Uma mensagem útil costuma responder, em linguagem direta, a quatro perguntas: o que está acontecendo, onde, qual é o período relevante e qual ação recomendada. Em emergência, clareza é mais importante que uma descrição extensa do fenômeno. Detalhes adicionais podem ficar em uma página oficial ou em um canal de apoio.
Também separo severidade de urgência. Um evento grave pode exigir preparação antes de um impacto imediato. Já um evento menos abrangente pode pedir ação instantânea em uma área pequena. Se o sistema usa apenas níveis vagos como “baixo, médio e alto”, sem definir consequências operacionais, cada equipe pode interpretar a escala de um jeito.
Deduplicação, atualização e cancelamento
Um problema comum é publicar um aviso, receber uma atualização do mesmo evento e enviar tudo como se fosse uma emergência nova. Isso multiplica notificações sem acrescentar informação útil.
Prefiro tratar cada ocorrência como um evento com identificador estável, versão e validade. Uma atualização deve explicar o que mudou. Se o risco acabou ou a orientação foi corrigida, o sistema precisa emitir uma mensagem de encerramento ou correção pelos canais disponíveis. Silêncio depois de um alerta pode deixar as pessoas sem saber se ainda precisam agir.
Não aplicaria um limite genérico de notificações a qualquer sistema de emergência. Um mecanismo de “no máximo um alerta por hora” pode bloquear uma orientação crítica. O controle deve considerar tipo de evento, severidade, novidade e ação necessária. Alertas informativos podem ser agrupados; instruções de proteção imediata não devem ser suprimidas só porque houve mensagens anteriores.
Na Prática: uma política simples para notificações de produto
O exemplo abaixo não envia avisos à rede celular nem substitui protocolos oficiais. Ele demonstra uma política para notificações de um produto próprio: descarta eventos expirados, evita duplicatas recentes e bloqueia avisos de baixa prioridade quando não há mudança. Em sistemas reais, a regra deve ser validada com especialistas de domínio e adaptada ao impacto de cada alerta.
type Alert = {
id: string;
version: number;
severity: "info" | "warning" | "critical";
message: string;
createdAt: number;
expiresAt: number;
};
type PreviousAlert = {
version: number;
sentAt: number;
};
type Decision = {
send: boolean;
reason: string;
};
const severityRank = {
info: 1,
warning: 2,
critical: 3,
} as const;
function shouldSend(
alert: Alert,
previous: PreviousAlert | undefined,
now = Date.now(),
): Decision {
if (alert.expiresAt <= now) {
return { send: false, reason: "alerta expirado" };
}
if (previous && alert.version <= previous.version) {
return { send: false, reason: "versão já processada" };
}
if (
previous &&
alert.severity === "info" &&
now - previous.sentAt < 30 * 60 * 1000
) {
return { send: false, reason: "informativo recente; evitar repetição" };
}
return { send: true, reason: "novo alerta válido" };
}Há uma limitação deliberada nesse exemplo: o histórico usa apenas versão e horário, não um mecanismo distribuído de idempotência. Em produção, eu persistiria o identificador do evento e a versão em armazenamento confiável, com uma chave idempotente por destinatário e canal quando aplicável.
Também não usaria o texto da mensagem como chave de deduplicação. Uma pequena alteração de pontuação criaria uma “mensagem nova”, enquanto dois eventos diferentes poderiam ter textos iguais. Identidade do evento, versão e escopo geográfico são dados melhores para essa decisão.
- Defina o objetivo: registre qual ação a pessoa precisa tomar, não apenas qual dado será comunicado.
- Classifique o evento: estabeleça severidade, urgência, área afetada e validade com critérios documentados.
- Escolha os canais: considere o alcance e as limitações de cada canal, sem presumir que um push substitui um mecanismo de alerta público.
- Controle o ciclo de vida: deduplique, atualize e encerre o evento de forma explícita.
- Teste compreensão: verifique se as pessoas entendem a orientação, inclusive sob pressão e em telas pequenas.
- Monitore consequências: acompanhe falhas, reclamações e padrões de repetição sem coletar dados pessoais além do necessário.
Erros comuns ao implementar alertas por celular
- Otimizar apenas a entrega: dashboards com “enviados” e “entregues” não medem compreensão nem ação. Trate essas métricas como parte do funil, não como prova de sucesso.
- Enviar a mesma mensagem em todos os canais: cada canal tem limites de tamanho, apresentação e acessibilidade. Preserve a orientação central, mas adapte o formato.
- Usar linguagem ambígua: termos técnicos ou instruções vagas aumentam o esforço de interpretação. Prefira verbos concretos, como “saia da área” ou “procure abrigo”, quando forem adequados ao protocolo.
- Repetir sem explicar a mudança: uma nova notificação deve dizer se a área, o risco, o horário ou a ação recomendada mudou.
- Aplicar throttling sem exceções: limitar mensagens por usuário pode ser razoável para avisos informativos, mas perigoso se bloquear uma atualização crítica.
- Ignorar acessibilidade e localização: considere leitores de tela, linguagem simples e incertezas na delimitação da área. Um limite geográfico não representa necessariamente a percepção de risco de quem está perto dele.
- Testar só em condições ideais: considere conectividade instável, aparelho sem som, bateria baixa e pessoas que não acompanham notificações em tempo real.
O que desenvolvedores podem aprender com o caso
O caso descrito pelo Terra mostra que a possibilidade de desativar um aviso não é apenas uma configuração de interface. É um sinal de que a relação entre quem envia e quem recebe pode estar se deteriorando. Em produtos comerciais, isso aparece como permissões revogadas, notificações desativadas e usuários que ignoram mensagens. Em uma emergência, o custo potencial é maior.
Para times de engenharia, a consequência prática é tratar notificações como parte crítica do produto, com governança, testes e critérios de qualidade. Registrem quem aprovou o conteúdo, qual versão foi publicada, qual público foi definido e quando o evento foi encerrado. Observabilidade ajuda a encontrar falhas, mas o log precisa respeitar privacidade e políticas de retenção.
Na minha visão, o melhor sistema não é o que fala mais alto. É o que preserva a atenção para quando ela realmente importa. Isso exige coordenação entre tecnologia, comunicação e autoridades responsáveis. O código pode reduzir duplicatas e melhorar a entrega; não substitui a confiança nem decide sozinho quando um alerta é necessário.
Perguntas frequentes sobre fadiga de alertas
O que significa fadiga de alertas?
É a perda de atenção e resposta causada por avisos frequentes, pouco relevantes, repetitivos ou difíceis de interpretar. Pode levar pessoas a ignorar mensagens ou desativar notificações.
Push notification é a mesma coisa que alerta da Defesa Civil?
Não. Um push normalmente depende de aplicativo instalado, permissão e serviços da plataforma. O Defesa Civil Alerta descrito na reportagem usa a rede celular para difundir mensagens em uma área de risco, sem exigir cadastro prévio.
Como evitar alertas duplicados em uma aplicação?
Modele o evento com identificador estável, versão, escopo e validade. Persista o que já foi processado e use idempotência. Não dependa apenas do texto da mensagem para detectar duplicatas.
É uma boa ideia limitar o número de notificações por pessoa?
Para avisos informativos, um limite ou agrupamento pode reduzir ruído. Para alertas críticos, limites genéricos podem ocultar informações importantes. A política precisa considerar severidade, novidade e ação necessária.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.