Use este runbook de incidentes para apps sem código para identificar problemas rápido, triar impacto, reverter com segurança, comunicar claramente e evitar repetição.
Um incidente é qualquer problema inesperado que impede pessoas de usar seu app, o deixa dolorosamente lento ou coloca dados em risco. Em apps sem código, isso pode se manifestar como falhas súbitas de login, telas quebradas após uma alteração, automações em background que param de disparar, erros de API ou fluxos “bem-sucedidos” que silenciosamente gravam valores errados no banco de dados.
Um runbook escrito transforma um momento estressante em um conjunto de ações pequenas e claras. Ele reduz a adivinhação, acelera decisões (como quando fazer rollback) e ajuda todo mundo a compartilhar os mesmos fatos. A maioria dos atrasos durante incidentes não é técnica. Vem da incerteza: É real? Quem está liderando? O que mudou? O que dizemos aos usuários?
Este playbook é para qualquer pessoa que mexa no app quando algo dá errado: builders que entregam mudanças, ops ou donos de plataforma que gerenciam deploys e acessos, times de suporte que recebem os primeiros relatos e donos de produto ou negócio que avaliam impacto e prioridades.
É intencionalmente leve, inclusive para times que constroem em plataformas como AppMaster, onde você pode ter lógica visual, serviços gerados e múltiplas opções de deploy.
Cobre o ciclo completo de incidente: detectar e confirmar um problema real, triar rápido, estabilizar e recuperar (incluindo decisões de rollback), comunicar durante a queda e, por fim, rodar uma revisão pós-incidente curta para reduzir chances de repetição.
Não cobre redesenho arquitetural de longo prazo, forense profunda de segurança ou procedimentos complexos de conformidade. Se você lida com dados regulados ou infraestrutura crítica, acrescente passos mais rígidos a este runbook.
Incidentes parecem caóticos quando você não sabe como “normal” se parece. Defina seu baseline para que o time consiga perceber problemas reais rapidamente. Para um app sem código, sinais iniciais geralmente vêm de uma mistura de saúde da plataforma, métricas de negócio e pessoas.
Escreva os sinais que você vai assistir todo dia, não só durante quedas. Comuns: uptime, taxa de erros, telas lentas, logins falhos, falhas de pagamento e picos em tickets de suporte ou mensagens de usuário.
Defina severidade em linguagem simples para que qualquer pessoa consiga usar:
Estabeleça metas de resposta que criem impulso. Exemplos: reconhecer em até 5 minutos, postar a primeira atualização em 15 minutos e buscar estabilizar em 60 minutos (mesmo que a correção completa demore mais).
Decida os papéis antes de precisar deles. Nomeie quem pode declarar um incidente, quem o lidera e quem é backup se essa pessoa estiver offline. Em times AppMaster, isso costuma ser a pessoa que possui a lógica de Business Process, mais um backup que consegue lidar com deploys ou exports.
Por fim, mantenha um lugar compartilhado para notas do incidente. Use timestamps para cada ação (o que mudou, quando, por quem) para reconstruir a história depois sem adivinhar.
Confirme o impacto antes de ficar olhando dashboards. Faça uma pergunta clara: quem não consegue fazer o quê agora? “O time de suporte não consegue abrir tickets” é mais útil que “o app está lento”. Se possível, reproduza o problema usando o mesmo papel e dispositivo do usuário afetado.
Em seguida, entenda quão amplo é. É uma conta, um segmento de clientes ou todo mundo? Faça divisões rápidas: região, tipo de conta, web vs mobile e recurso único vs app inteiro. Em ferramentas no-code, algo pode parecer global quando na verdade é uma regra de permissão ou uma tela quebrada.
Depois, verifique o que mudou. Olhe 1–2 horas para trás por um release, um toggle de config, uma edição de schema do banco ou uma importação de dados. Em plataformas como AppMaster, mudanças em business processes, modelos de dados ou configurações de auth podem afetar muitos fluxos de uma vez, mesmo que a UI pareça ok.
Antes de culpar seu app, descarte dependências externas. Provedores de email/SMS, pagamentos (como Stripe) e integrações (Telegram, serviços AWS, APIs de AI) podem falhar ou aplicar rate limit. Se o app falha só ao enviar mensagens ou cobrar cartões, a raiz pode estar a montante.
Use uma checklist de decisão simples:
Uma vez classificado severidade e escopo, você pode passar de “é real?” para “o que fazemos primeiro?” sem adivinhação.
Abra um registro de incidente imediatamente. Dê um título simples que nomeie o impacto ao usuário, não a causa suspeita (por exemplo, “Checkout falhando para clientes da UE”). Anote o horário de início (primeiro alerta ou primeiro relato). Isso vira o lugar único para decisões, timestamps e o que mudou.
Atribua papéis para que o trabalho não se sobreponha. Mesmo em times pequenos, nomear donos reduz erros sob estresse. No mínimo, você quer:
Escreva duas coisas: o que você sabe com certeza e sua hipótese atual. “Conhecido” pode ser: taxa de erro subiu, um endpoint específico está falhando, apenas mobile é afetado. A hipótese pode estar errada, mas deve guiar o próximo teste. Mantenha ambos atualizados conforme aprende.
Enquanto as coisas estiverem instáveis, adote uma cadência de atualizações de 15 minutos. Se nada mudou, diga isso. Atualizações regulares evitam discussões paralelas e pings duplicados de “tem novidades?”.
Escolha a primeira ação de contenção. O objetivo é reduzir dano rápido, mesmo sem a causa raiz clara. Movimentos típicos: pausar jobs em background, desabilitar um feature flag arriscado, limitar tráfego a um módulo ou alternar para uma configuração segura conhecida. No AppMaster, isso frequentemente significa desligar um fluxo específico no Business Process Editor ou ocultar temporariamente um caminho de UI que dispara falhas.
Se a contenção não melhorar as métricas dentro de uma janela de cadência, comece a planejar rollback em paralelo.
Uma vez confirmado que é um incidente real, mude de “achar o bug” para “parar o sangramento”. Estabilizar compra tempo. Protege usuários, receita e dados enquanto você investiga.
Comece com a menor mudança que reduza dano. Contenção é frequentemente mais rápida que correção completa porque você pode desabilitar um recurso novo, pausar um fluxo de trabalho ou bloquear um caminho de entrada arriscado sem rebuild.
Se suspeitar que dados estão sendo corrompidos, pare gravações primeiro. Isso pode significar desabilitar formulários temporariamente, pausar automações que atualizam registros ou bloquear um endpoint de API que aceita atualizações. Ler dados ruins é doloroso, mas escrever dados ruins multiplica o trabalho de limpeza.
Se usuários estão bloqueados, trate login como prioridade máxima. Verifique configurações de autenticação e fluxo de login antes de qualquer outra coisa. Todo o resto é mais lento se usuários (e seu próprio time) não conseguem acessar o app.
Se o app está lento ou com timeout, reduza carga e remova caminhos caros. Desligue telas pesadas, pause jobs em background e desative integrações novas que disparam muitas requisições. No AppMaster, contenção pode ser tão simples quanto desabilitar um business process problemático ou remover temporariamente uma ação de UI que dispara uma cadeia custosa.
Mantenha ações deliberadas e documentadas. Sob pressão, times repetem passos ou desfazem uma correção por acidente. Anote cada mudança e o resultado.
Uma sequência de estabilização simples:
O objetivo é “seguro e utilizável”, não “totalmente resolvido”. Uma vez contido o impacto, você pode diagnosticar calmamente e escolher o rollback ou correção correta.
Quando algo quebra, velocidade importa, mas o movimento mais seguro vence. Normalmente você tem três opções práticas: rollback, enviar uma correção adiante, ou fazer um revert parcial (desligar uma função mantendo o resto).
Primeiro, seja claro sobre o que “rollback” significa no seu ambiente. Pode ser deploy da versão anterior do app, reverter uma mudança de configuração ou restaurar um estado de banco de dados. Em plataformas como AppMaster, uma “versão” pode incluir lógica backend, UI web, builds móveis e configurações de ambiente.
Use estas checagens de risco para decidir se rollback é seguro:
Defina uma regra simples de go/no-go antes de tocar em qualquer coisa. Escolha 2–3 métricas que devem melhorar em 10–15 minutos após a ação, como taxa de erro, sucesso de login, conclusão de checkout ou latência de API. Se não melhorarem, pare e mude de estratégia.
Planeje também o backout do rollback. Saiba como desfazer se a versão antiga causar novos problemas: qual build redeployar, qual config re-aplicar e quem aprova essa segunda mudança. Mantenha uma pessoa responsável pela decisão final de “ship” para não alterar o rumo no meio do processo.
O silêncio piora incidentes. Use uma forma simples e repetível de manter pessoas informadas enquanto o time investiga.
Comece com atualizações internas. Avise quem receberá perguntas primeiro e quem pode remover bloqueios. Seja breve e factual. Normalmente você precisa alcançar:
Para atualizações externas, mantenha-se no que sabe. Evite adivinhar a causa ou culpar um fornecedor. Usuários querem basicamente três coisas: confirmação, impacto e quando terão nova atualização.
Mantenha uma linha de status consistente entre canais:
Se usuários estiverem irritados, reconheça primeiro e depois seja específico: “Sabemos que o checkout está falhando para alguns clientes. Estamos revertendo a última mudança agora. Próxima atualização em 30 minutos.” Não prometa prazos, créditos ou correções permanentes durante o incidente.
Declare resolvido apenas quando o sintoma principal tiver desaparecido e checagens chave estiverem limpas (logins, fluxos centrais, taxas de erro). Use monitorando quando aplicou uma correção (por exemplo, rollback ou restauração) mas ainda precisa observar repetições. Sempre diga o que será monitorado, por quanto tempo e quando a atualização final será postada.
Quando as coisas estiverem estáveis, mude do firefighting para recolher o menor conjunto de fatos que explique os sintomas. O objetivo não é a causa raiz perfeita, é uma causa provável que permita agir sem piorar o incidente.
Sintomas diferentes apontam para suspeitos diferentes. Páginas lentas geralmente significam queries pesadas no banco, pico de tráfego ou um serviço externo lento. Timeouts podem vir de um processo travado, backend sobrecarregado ou uma integração demorando demais. Picos de erros ou retries normalmente acompanham uma mudança recente, uma entrada ruim ou uma queda a montante.
Execute uma jornada real de usuário fim a fim com uma conta de teste normal. Frequentemente é o sinal mais rápido porque toca UI, lógica, banco de dados e integrações.
Concentre-se em algumas verificações:
Se você usa AppMaster, isso frequentemente mapeia claramente a um passo de Business Process, uma mudança no Data Designer ou uma configuração de deploy.
Se as checagens rápidas apontarem um culpado claro, escolha o movimento mais seguro: mantenha a mitigação atual ou aplique uma correção pequena e permanente. Só remova limites de taxa, toggles de feature ou workarounds manuais depois que a jornada passar duas vezes e a taxa de erro se mantiver estável por alguns minutos.
São 10:15 da manhã numa terça. Um time libera uma pequena mudança num portal de clientes construído no AppMaster. Em minutos, usuários começam a ver páginas em branco após o login e novos pedidos param de entrar.
O suporte recebe três tickets com a mesma mensagem: “O login funciona, depois o portal não carrega.” Ao mesmo tempo, monitoramento mostra pico de erros 500 no web app e queda em chamadas de API bem-sucedidas. Você trata como incidente real.
O incident lead faz uma confirmação rápida: tenta logar como usuário de teste em desktop e mobile e checa o horário do último deploy. O timing bate com o release, então assume-se que a mudança recente está envolvida até prova em contrário.
Os primeiros 30 minutos podem ser assim:
Às 10:40, os erros voltam ao normal. Você mantém vigilância nas métricas enquanto o suporte confirma redução de tickets.
Depois, o time faz uma revisão curta: o que detectou primeiro (alertas vs suporte), o que atrasou (dono ausente, passos de rollback confusos) e o que mudar. Uma melhoria comum é adicionar um checklist de smoke-test de release para os três fluxos principais do portal e documentar o rollback como um passo de ação única.
A maioria dos incidentes piora por dois motivos: pessoas deixam o sistema continuar fazendo dano enquanto investigam, ou mudam muitas coisas rápido demais. Este runbook serve para proteger contra ambos.
Uma armadilha comum é investigar enquanto o app ainda grava dados ruins. Se um fluxo está em loop, uma integração posta duplicatas ou um bug de permissão permite usuários errados editar registros, pause o processo ofensivo primeiro. No AppMaster, isso pode significar desabilitar um Business Process, desligar uma integração de módulo ou restringir acesso temporariamente para interromper a propagação.
Outra armadilha é “consertar” por chute. Quando várias pessoas clicam e mudam configurações, você perde a linha do tempo. Mesmo pequenas edições importam durante um incidente. Combine um responsável, mantenha um changelog simples e evite empilhar ajustes sobre incógnitas.
Erros que repetidamente alongam quedas:
Comunicação faz parte da recuperação. Compartilhe o que sabe, o que não sabe e quando será a próxima atualização. “Estamos revertendo e confirmaremos eventos de cobrança corretos em 15 minutos” é melhor que “Estamos vendo o problema.”
Não feche o incidente só porque os erros pararam. Verifique com um checklist curto: telas chave carregam, novos registros salvam corretamente, automações críticas executam uma vez e backlogs (filas, retries, jobs agendados) estão drenados ou pausados com segurança.
Quando algo quebra, seu cérebro tentará fazer dez tarefas ao mesmo tempo. Use isto para manter a calma, proteger pessoas e restaurar o serviço.
Fixe esta seção onde o time realmente a verá.
Tire um minuto para nomear um dono do incidente. Uma pessoa decide, todos apoiam.
Estabilizar e conter (10 minutos): Pare o sangramento antes de caçar a causa. Desative o caminho arriscado (feature toggle, banner temporário, pausa de fila) e teste uma jornada chave fim a fim. Escolha a jornada que mais importa ao negócio, não a mais fácil de testar.
Recuperar serviço (10–20 minutos): Escolha o movimento mais seguro: rollback para a última versão boa ou aplicar um conserto mínimo. Em plataformas como AppMaster, isso pode significar redeploy de build anterior ou reverter a última mudança, e então confirmar que taxas de erro e tempos de resposta voltaram ao normal.
Comunicar (durante todo o tempo): Publique uma atualização curta com o que está impactado, o que os usuários devem fazer e o próximo horário de atualização. Oriente o suporte com um roteiro de duas frases para que todos digam a mesma coisa.
Encerrar limpo (antes de esquecer): Registre o que aconteceu, o que mudou e o horário de recuperação. Atribua próximos passos com dono e prazo (ajuste de monitoramento, gap de testes, limpeza de dados, correção de acompanhamento).
Um incidente não está totalmente “concluído” quando o app volta. A forma mais rápida de reduzir downtime futuro é capturar o que aconteceu enquanto está fresco e transformar esse aprendizado em mudanças pequenas e reais.
Agende uma revisão pós-incidente curta em 2–5 dias. Mantenha-a sem culpa e prática. O objetivo não é achar alguém para culpar, é tornar o próximo incidente mais fácil de lidar.
Escreva um registro que alguém possa ler meses depois: o que os usuários viram, quando detectaram, o que tentaram, o que funcionou e quando o serviço retornou. Inclua a causa raiz se souber e anote fatores contribuintes como alertas faltando, dono pouco claro ou passos de rollout confusos.
Transforme aprendizados em tarefas com donos e prazos. Foque nas menores mudanças que previnem a mesma falha:
Escolha uma medida de prevenção por incidente, mesmo pequena. “Qualquer mudança de papéis requer segundo revisor” ou “Migrações de dados devem rodar primeiro em cópia de staging” podem evitar quedas repetidas.
Mantenha este runbook próximo ao seu processo de build e release. Se você constrói com AppMaster, anote onde cada app está deployado (AppMaster Cloud, AWS, Azure, Google Cloud ou self-hosted), quem pode redeployar rápido e quem pode fazer rollback. Se quiser um único lugar para essa documentação, manter ao lado das notas do projeto AppMaster (appmaster.io) facilita achar quando minutos contam.
When should we treat a problem as an incident for a no-code app?Use este runbook sempre que um problema inesperado bloquear tarefas essenciais, deixar o app inutilizavelmente lento ou colocar em risco alterações incorretas ou inseguras nos dados. Se usuários não conseguem entrar, pagamentos falham, automações param ou registros estão sendo gravados incorretamente, trate como incidente e siga o runbook.
What’s the fastest way to confirm an incident is real and measure impact?Comece pelo impacto ao usuário: quem não consegue fazer o quê agora e desde quando. Depois tente reproduzir com o mesmo papel e dispositivo, e verifique se é um caso isolado, um segmento de clientes ou todos os usuários, para não perseguir a causa errada.
How do we quickly decide SEV1 vs SEV2 vs SEV3?Declare SEV1 quando a maioria dos usuários está bloqueada ou quando dinheiro/segurança/dados estão em risco. Use SEV2 quando um recurso chave está quebrado mas existe um workaround, e SEV3 para problemas menores ou de escopo limitado; decidir rápido é mais importante do que ser perfeito.
Who should do what during an incident, especially in a small team?Escolha um incident lead que tome as decisões finais e atribua um responsável por consertar, um por comunicações e um por registrar notas, para evitar sobreposição ou mudanças acidentais. Em times pequenos, uma pessoa pode acumular papéis, mas o papel de líder do incidente deve ficar claro.
What does “containment” look like in AppMaster or similar no-code platforms?Contenção significa parar o dano rápido, mesmo sem saber a causa. No AppMaster, isso costuma ser desabilitar um Business Process específico, ocultar temporariamente uma ação de UI que dispara falhas ou pausar uma automação que está em loop ou escrevendo dados incorretos.
When should we roll back versus ship a quick fix forward?Faça rollback quando o problema começou logo após um deploy e você tem uma versão conhecida que restaura o serviço rapidamente. Opte por um fix à frente apenas quando puder aplicar uma mudança pequena e de baixo risco e verificá‑la rápido sem aumentar o tempo de inatividade.
What makes a rollback unsafe in no-code apps?Considere o rollback arriscado se houve mudança de esquema de banco de dados, se ocorreram gravações irreversíveis, ou se jobs enfileirados e webhooks podem ser reprocessados pela lógica antiga. Nesses casos, estabilize primeiro e confirme o que a versão antiga espera antes de redeployar.
If we suspect data corruption, what should we do first?Pare as gravações primeiro se houver suspeita de corrupção de dados — gravações ruins multiplicam o trabalho de correção. Na prática, desative formulários, pause automações de atualização ou bloqueie endpoints de atualização até confirmar que novos registros não estão sendo alterados incorretamente.
What should we say during an outage, and how often should we update?Envie atualizações curtas e factuais em uma cadência fixa, dizendo o que está afetado, o que estão fazendo e quando será a próxima atualização. Evite especular sobre a causa ou culpar fornecedores; usuários e stakeholders precisam principalmente de clareza e previsibilidade.
When is it okay to call an incident “resolved” versus “monitoring”?Considere resolvido apenas quando o sintoma principal sumiu e checagens chave estiverem limpas (login, fluxo principal, taxa de erros). Se você aplicou uma correção mas ainda precisa monitorar por recorrências, marque como "monitorando" e diga o que será observado e por quanto tempo.
21 de jan. de 2026
8 min
20 de jan. de 20268 min
20 de jan. de 20268 minExperimente o AppMaster com plano gratuito.
Quando estiver pronto, você poderá escolher a assinatura adequada.
