Modelos de mensagens para janelas de manutenção que acalmam os usuários durante paralisações planejadas, interrupções parciais e desempenho degradado, reduzindo pânico e chamados ao suporte.
A maioria das notas de manutenção falha por uma razão simples: elas geram incerteza. Um banner que diz “Estamos fazendo manutenção” sem detalhes força os usuários a adivinhar o que está quebrado, quanto tempo vai durar e se o trabalho deles está seguro. Adivinhação vira medo, e medo vira chamados ao suporte.
Mensagens vagas também soam suspeitas. Se os usuários veem erros, mas sua mensagem parece calma e genérica, eles assumem que você está escondendo o problema real. Essa lacuna entre o que vivenciam e o que você diz é o que quebra a confiança.
As pessoas geralmente precisam de três coisas imediatamente: impacto claro, horário claro e próximos passos claros.
Impacto significa nomear o que está afetado (login, exportações, pagamentos), não apenas dizer “interrupção do serviço”. Horário significa uma janela específica e quando será a próxima atualização, não “em breve”. Próximos passos significa dizer o que fazer enquanto esperam, como “tente novamente em 20 minutos” ou “use o app móvel em vez disso”.
Prometer demais é a maneira mais rápida de piorar as coisas. “Sem impacto esperado” é arriscado a menos que você esteja realmente confiante. Quando mesmo um usuário é afetado, essa frase vira prova de que você não está atento. Atualizações honestas funcionam melhor: diga o que você sabe, o que ainda não sabe e exatamente quando voltará a conferir.
O objetivo não é “maquiar” a história. É reduzir a incerteza. Quando as pessoas entendem o que está acontecendo, o que isso significa para elas e o que devem fazer agora, elas param de atualizar a página, param de supor o pior e deixam de abrir tickets só para ter uma sensação de controle.
Os usuários relaxam quando você nomeia a situação em termos simples. Se você chama tudo de “manutenção” ou “problemas”, as pessoas assumem o pior e começam a tentar novamente, atualizar e abrir tickets.
Comece pelo rótulo certo:
“Degraded” nunca deve ser vago. Diga o que o usuário vai notar. Por exemplo: “As exportações podem demorar 10 a 20 minutos a mais que o usual” é mais claro que “Estamos com desempenho degradado.”
Seja específico sobre o que está afetado, mesmo que a lista seja curta. Mencione as áreas que mais importam: login, pagamentos e cobrança, sincronização, notificações, dashboards, exportações, acesso à API e upload de arquivos.
Evite palavras assustadoras, mas não esconda a verdade. Substitua “falha crítica” por “alguns usuários não conseguem fazer login” e “instabilidade do sistema” por “você pode ver timeouts ao salvar”. Um tom calmo vem da precisão, não do otimismo.
Se você não souber, escolha o rótulo que corresponde ao impacto para o usuário, não à causa interna. “Manutenção do banco de dados” diz pouco à maioria das pessoas. “A página de cobrança pode ficar indisponível por até 15 minutos” diz o que esperar e o que fazer.
Os usuários confiam no que conseguem ver no exato momento em que estão bloqueados. Bons templates de mensagem são menos sobre redação criativa e mais sobre usar a superfície certa.
Use um banner dentro do app para a maior parte dos trabalhos planejados. Ele fica visível enquanto as pessoas continuam o que podem e não sequestra a tela.
Use um modal apenas quando o usuário não puder continuar com segurança (ações de cobrança, edição de dados, cadastros). Se usar um modal, permita que as pessoas o fechem e mantenha um banner persistente depois.
Toasts funcionam melhor para atualizações curtas e de baixo risco (por exemplo, “Exportações podem ficar mais lentas por 10 minutos”). São fáceis de perder, então não os use para downtime real.
Uma regra simples:
Se os usuários podem ficar impossibilitados de entrar, coloque a mesma mensagem na tela de login. É ali que o pânico começa, porque os usuários assumem que a conta está com problema. Uma nota simples como “Login pode falhar entre 02:00–02:30 UTC” reduz chamados rapidamente.
Use sua página de status para atualizações em andamento e histórico (o que mudou, o que ainda está afetado, o que foi consertado). Use o aviso dentro do produto para dizer o que o usuário deve fazer agora (esperar, tentar novamente mais tarde, evitar exportações etc.). Não esconda detalhes críticos só na página de status, pois muitos usuários nunca a consultam.
Email e notificações push ajudam quando o impacto é alto e os usuários precisam planejar. Caso contrário, parecem barulhentos. Se enviar, mantenha a consistência com a cópia no app.
Por fim, alinhe o suporte com a mesma redação. Sua resposta automática deve coincidir com o texto do banner e as atualizações de status para que os usuários não recebam mensagens divergentes.
As pessoas confiam em avisos de manutenção quando eles são específicos, honestos e úteis. Isso não significa longos textos. Significa responder às perguntas de um usuário estressado nos primeiros 10 segundos, com horário claro e um plano.
Um aviso confiável inclui cinco itens básicos:
O tempo é onde as mensagens frequentemente perdem confiança. Use uma janela que as pessoas entendam, como “16 de jan, 01:00 às 02:30 UTC”. Se tiver uma audiência global grande, considere adicionar um segundo horário de referência que muitos usuários compartilhem (por exemplo, “08:00 às 09:30, horário de Singapura”). Evite precisão falsa como “de volta às 02:17”. Um intervalo como “30 a 60 minutos” parece mais honesto e reduz ciclos de atualização raivosos.
Se você não sabe algo ainda, diga o que está verificando a seguir. Por exemplo: “Estamos investigando carga elevada no banco de dados e revisando deploys recentes e queries lentas. Próxima atualização às 14:30 UTC.” Essa única frase transforma silêncio em um plano.
Inclua sempre um horário da próxima atualização, mesmo que seja em breve e mesmo que nada mude. “Próxima atualização em 20 minutos” acalma porque estabelece uma promessa que você pode cumprir.
Exemplo de detalhe que gera confiança: “Exportações de arquivos podem demorar de 10 a 30 minutos a mais que o usual. Enquanto isso, você pode visualizar relatórios no app. Publicaremos outra atualização até 16:10 UTC.”
Bons avisos de manutenção parecem calmos porque são específicos e consistentes. Trate-os como checklists, não como anúncios.
Escreva o primeiro rascunho com espaços reservados claros. Comece com: o que está afetado, quando começa, quanto tempo pode durar e quem é impactado. Deixe colchetes para detalhes que você pode confirmar depois (hora de término exata, regiões afetadas, nome da funcionalidade). Isso permite publicar cedo sem chutar.
Escolha um rótulo de severidade que combine com a realidade. Use um rótulo e mantenha-o em banner, página de status e email. Por exemplo: Maintenance (planejado), Partial outage (alguns usuários ou funcionalidades), Degraded performance (lento ou com atraso). Se usar cores, mantenha-as consistentes (verde = normal, amarelo = degradado, vermelho = outage) para que os usuários possam escanear rapidamente.
Adicione uma frase que explique o rótulo em linguagem simples. “Degraded” deve sempre significar algo concreto como “exportações podem levar 5–15 minutos”.
Ofereça um workaround quando possível. Mesmo uma pequena alternativa reduz tickets. Exemplo: “Se precisar do relatório agora, use o download CSV do dashboard enquanto as exportações agendadas estão atrasadas.” Se não houver alternativa, diga isso uma vez, claramente.
Planeje suas atualizações antes de publicar. Agende dois lembretes: um pouco antes da janela e outro “começando agora” exatamente no início. Se o horário mudar, atualize o aviso primeiro e depois envie o lembrete.
Feche o ciclo com uma atualização final. Diga o que mudou, quando foi restaurado e o que os usuários devem fazer se algo ainda parecer errado (atualizar, tentar novamente ou contatar o suporte com um detalhe específico como timestamp ou ID do job).
Use esses templates como ponto de partida e ajuste os detalhes para o que seus usuários realmente fazem no produto. Mantenha o tom calmo e direto. Dê uma ação clara que o usuário possa tomar.
Subject/Title: Planned maintenance on [Day], [Date] at [Start time] [TZ]
Message: Temos manutenção agendada em [Dia, Data] das [hora de início] às [hora de término] [TZ].
Durante esta janela, [o que ficará indisponível]. [o que continuará funcionando] permanecerá disponível.
Se precisar se preparar: por favor [ação recomendada, ex.: finalize exportações, salve rascunhos] antes de [hora]. Publicaremos atualizações aqui durante a janela.
Title: Maintenance is now in progress
Message: A manutenção começou e deve durar até [hora de término] [TZ].
No momento, [o que está indisponível]. Se tentar [tarefa comum], você poderá ver [erro/comportamento esperado].
Próxima atualização às [hora] (ou antes, se houver mudanças).
Title: Maintenance is taking longer than planned
Message: A manutenção está demorando mais que o previsto. O novo horário estimado de término é [novo horário de término] [TZ].
O que isso significa para você: [impacto em uma frase]. O que pode fazer agora: [workaround seguro ou “tente novamente após X”].
Desculpe pela interrupção — compartilharemos outra atualização às [hora].
Title: Maintenance is complete
Message: A manutenção foi concluída às [hora] [TZ].
Agora você pode [top 2–3 ações principais para verificar, ex.: entrar, executar exportação, efetuar pagamento]. Se algo ainda parecer errado, tente [passo simples como atualizar/re-login] e depois contate o suporte com [que informação incluir, ex.: horário, conta, screenshot].
Title: Monitoring after maintenance
Message: Os sistemas voltaram ao ar e estamos monitorando de perto pelas próximas [X horas].
Você pode notar [sintoma menor, ex.: carregamento mais lento, emails atrasados] enquanto as filas são processadas. Se encontrar erros, por favor tente novamente após [tempo].
Próxima atualização às [hora] (ou antes se identificarmos algo).
Quando o app não está totalmente fora, banners vagos geram o maior pânico. Seja específico sobre o que está afetado (funcionalidade, região ou etapa), o que ainda funciona e o que os usuários devem fazer agora.
Use quando a maior parte do produto funciona, mas uma área não.
Template
Title: Partial outage: [feature/service] unavailable in [region/account type]
Body: Estamos vendo um problema em que [feature] não está funcionando para [quem é afetado]. Outras partes do app, incluindo [o que ainda funciona], estão operando normalmente. Nossa equipe está trabalhando em uma correção.
Impacto: Você pode ver [mensagem de erro/sintoma] ao tentar [ação].
Workaround: Até a correção, por favor [ação alternativa segura].
Próxima atualização: Até [hora + fuso] (ou antes, se for resolvido).
Use quando as requisições têm sucesso, mas parecem quebradas por serem lentas.
Template
Title: Degraded performance: slower than normal [area]
Body: Algumas ações estão levando mais tempo que o normal, especialmente [ações específicas]. Você pode ver timeouts ou tentativas automáticas, mas os dados não devem ser perdidos.
O que fazer: Se ocorrer um erro, aguarde [X minutos] e tente novamente. Evite repetir a mesma ação muitas vezes (pode criar duplicados).
Próxima atualização: Até [hora + fuso].
Use quando a parte mais difícil é a incerteza.
Template
Title: Intermittent issue: [feature] may fail or succeed unpredictably
Body: Estamos investigando um problema em que [feature] funciona em algumas tentativas e falha em outras. Se falhar, é seguro tentar novamente após [X minutos].
Como ajudar: Se contatar o suporte, inclua [request ID / intervalo de tempo / região afetada].
Use quando os usuários não conseguem entrar. Mantenha a mensagem calma e direta.
Template
Title: Login issues: some users may not be able to sign in
Body: Estamos vendo falhas de login elevadas para [quem é afetado]. Se estiver bloqueado, por favor não redefina a senha repetidamente a menos que veja um erro claro de senha.
O que tentar: Atualize a página uma vez, aguarde [X minutos] e tente novamente. Se usar SSO, observe se o problema é SSO apenas ou todos os métodos de login.
Use quando os usuários acham que dados estão faltando.
Template
Title: Data delay: [reports/sync/analytics] may be behind by [X minutes/hours]
Body: Atividades novas podem demorar a aparecer em [área]. Seus dados ainda estão sendo coletados, mas o processamento está atrasado.
O que isso significa: Exportações/relatórios criados nesse período podem ficar incompletos. Se possível, aguarde até [hora] para rodar relatórios críticos.
Próxima atualização: Até [hora + fuso].
A maioria dos picos de suporte durante manutenções não é causada pela manutenção em si. Vêm da redação que faz as pessoas adivinhar o que está acontecendo, como isso as afeta e quando terminará. Se os usuários têm de adivinhar, abrem tickets.
Padrões que geram pânico rápido:
Um pequeno exemplo: sua ferramenta de exportação está lenta, mas o resto do app funciona. Se seu banner diz “Interrupção do serviço”, usuários que não estão exportando vão parar e acionar o suporte. Se disser “Exportações podem levar 10–20 minutos; dashboards e edição estão normais. Próxima atualização às 14:30 UTC”, muitos vão apenas esperar.
Se estiver construindo templates de mensagem, foque em linguagem simples que responda rapidamente a três perguntas: O que está afetado, o que devo fazer agora e quando vocês me atualizarão em seguida.
Antes de publicar, leia sua mensagem como um cliente preocupado. O objetivo é simples: reduzir a incerteza.
Certifique-se de que a redação bate entre banner, email, macros de help desk e mensagens de status. Se um diz “degradado” e outro “fora”, as pessoas pensam que você está escondendo algo.
Mantenha o tom calmo e factual. Evite exageros, piadas ou frases do tipo “sem problemas”. Uma linha simples e firme como “Estamos investigando exportações lentas” funciona melhor que tentar soar animado.
Faça o teste da clareza: um usuário novo consegue repetir o problema em uma frase sem acrescentar suposições? Se não, reescreva.
Quando terminar, feche explicitamente: confirme que está resolvido, informe a hora da resolução e diga o que fazer em seguida (por exemplo, “Tente exportar novamente” ou “Se ainda vir erros, atualize e tente outra vez”).
Um momento comum de “tudo está quebrado” é quando uma funcionalidade falha enquanto o resto do app parece normal. Imagine uma ferramenta financeira: a página de cobrança carrega, faturas aparecem e pagamentos continuam funcionando. Mas exportações CSV começam a expirar para alguns usuários. As pessoas atualizam, tentam de novo e depois abrem tickets porque acham que os dados sumiram.
A primeira mensagem deve dizer o que funciona, o que não funciona, quem é afetado e o que fazer agora. Por exemplo:
“Exportar faturas para CSV está expirando para algumas contas. Páginas de cobrança e pagamentos funcionam normalmente. Se precisar dos dados com urgência, use os filtros na tela e copie os resultados, ou tente exportar um intervalo de datas menor. Estamos investigando e atualizaremos aqui em 15 minutos.”
Na hora seguinte, as atualizações devem evoluir de “estamos vendo” para “isto foi alterado”:
A mensagem final fecha o ciclo. Inclui o conserto, o escopo e um caminho claro para suporte:
“Resolvido: aumentamos a capacidade dos workers de exportação e ajustamos timeouts. Das 10:05 às 11:05 UTC, algumas exportações CSV falharam, mas cobrança e pagamentos permaneceram disponíveis. Se ainda não conseguir exportar, responda ao seu último ticket com o horário da exportação e o intervalo de faturas.”
Times que se comunicam assim costumam ter menos tickets porque os usuários aprendem três coisas rápido: seus dados estão seguros, o que tentar agora e quando chegará a próxima atualização.
Trate mensagens de manutenção como uma pequena funcionalidade de produto, não como um pedido de desculpas pontual. O objetivo é consistência: os usuários devem reconhecer o padrão, saber o que fazer e confiar que vocês atualizarão no horário.
Transforme sua melhor cópia em blocos reutilizáveis com variáveis claras e mantenha-os em um só lugar para que qualquer pessoa na equipe publique um aviso sem reescrever do zero. Padronize básicos como hora de início, fim esperado, funcionalidades afetadas, regiões e quem é impactado (todos vs subconjunto).
Anote propriedade e um fluxo simples de aprovação. Uma pessoa rascunha, outra aprova e outra publica, mesmo que duas dessas funções sejam a mesma em equipes pequenas. Defina uma cadência de atualização antecipadamente (por exemplo, a cada 30 minutos durante um incidente) para que o suporte não precise adivinhar quando será a próxima mensagem.
Cuidado com linguagem de “snapshot” e “rollback”. Só prometa o que consegue cumprir sob pressão. Se rollback é possível, mas não garantido, diga isso com clareza e foque no que os usuários podem contar.
Se quiser tornar isso repetível dentro do produto, ajuda construir os pontos de entrega uma vez e reutilizá-los: um componente de banner no app, uma página de status leve e um fluxo de “tudo certo” pós-manutenção. Se sua equipe constrói produtos com Koder.ai (koder.ai), você pode criar essas peças de UI e fluxos de atualização via processo guiado por chat, depois ajustar a cópia e as variáveis sem reconstruir todo o app.
Termine fazendo um teste seco durante uma janela de baixa risco. Use templates reais, publique nas superfícies reais, cronometre suas atualizações e revise depois:
Quando tiver esse ciclo, seus templates deixam de ser documentos e viram um hábito.
Comece com o que está afetado, por quanto tempo vai durar e o que o usuário deve fazer agora. Uma frase simples como “Exports podem levar 10–20 minutos a mais; dashboards funcionam normalmente; próxima atualização às 14:30 UTC” evita suposições e reduz chamados.
Use Maintenance para trabalho planejado com janela definida, Partial outage quando uma funcionalidade ou região específica estiver fora, e Degraded performance quando as ações funcionam, mas estão lentas ou com erros. Escolha o rótulo que corresponda ao que os usuários sentem, não à causa interna.
Diga o que o usuário vai perceber em uma frase e, se possível, quantifique. Por exemplo: “Exports podem levar 10–30 minutos e podem expirar em grandes intervalos de datas”, em vez de “Estamos com desempenho degradado”.
Use um banner no app na maioria dos casos para que as pessoas continuem trabalhando. Use um modal só quando continuar pode causar erros ou perda de dados (como ações de cobrança ou edição de dados) e mantenha um banner persistente depois. Use toasts para atualizações breves e de baixo risco.
Coloque a mesma mensagem na tela de login sempre que o acesso estiver sujeito a falhas, porque é ali que o pânico começa. Se você só publicar dentro do app, usuários bloqueados vão assumir que a conta está com problema e inundar o suporte.
Evite certeza falsa como “Sem impacto esperado” a menos que você tenha certeza absoluta. Diga o que você sabe, o que ainda está sendo verificado e quando será a próxima atualização; essa honestidade é vista como competência, não fraqueza.
Sempre inclua um horário específico para a próxima atualização, mesmo que nada mude. “Próxima atualização em 20 minutos” estabelece uma promessa que os usuários podem confiar e reduz o ciclo de atualizar a página e abrir tickets.
Ofereça uma ação segura e única que reduza riscos e duplicações. Por exemplo: “Tente novamente uma vez após 2 minutos”, “Evite repetir a mesma exportação” ou “Use um intervalo de datas menor”. Se não houver alternativa, diga isso claramente uma vez.
Explique o que está afetado, o que ainda funciona e o que fazer se estiver bloqueado. Diga aos usuários para não repetir ações de alto risco (como redefinir senha várias vezes) a menos que a mensagem instrua isso especificamente.
Encerramento explícito com “resolvido” incluindo horário, o que foi restaurado e o que tentar se algo ainda parecer errado (atualizar, fazer login novamente, tentar outra vez). Se podem ocorrer casos pontuais, diga que estão monitorando e quando publicarão a confirmação final.
