Sazabi

oficial

Observabilidade e segurança nativas de IA: permita que seu agente de programação pesquise logs de produção, veja problemas detectados e use dashboards em tempo real.

Ver em sazabi.com

O que você pode fazer com Sazabi MCP?

  • Plain-language log search — Ask a question in natural language and get an answer with the matching log records returned.
  • Structured log queries — Search specific log fields and recurring patterns to narrow down an investigation.
  • Coding agent log access — Let coding agents query production logs from their own tools via the CLI and MCP integration.
  • Automatic issue detection — Surface anomalies in logs without writing alert rules, including silent outages and unusual user behavior.
  • Root-cause analysis — Group related errors and trace them back to the code that produced them.
  • Suggested fixes — Get a plan for resolving each detected issue, usable by engineers and coding agents.

Servidor MCP hospedado

npx add-mcp 'https://mcp.sazabi.com/mcp'

Instala no Claude Code, Codex, Cursor e outros

Documentação

Observabilidade e segurança nativas de IA

Início rápido: https://docs.sazabi.com/get-started/quickstart

Comece: npx @sazabi/cli start

Alertas autônomos, depuração conversacional e integrações com agentes de programação. O Sazabi destaca os problemas que importam e dá à sua equipe o contexto necessário para resolvê-los.

Confiado por

  • Mastra
  • Weave
  • Sandstone
  • Wajo
  • Autumn
  • Agree.com
  • Inth
  • Hoplite
  • Taiga
  • XMTP Labs

O Sazabi é uma plataforma de observabilidade e segurança nativa de IA para equipes que desenvolvem software rapidamente. Ele conecta logs de produção ao código, detecta problemas importantes sem monitores criados manualmente, investiga as causas raiz e envia contexto útil para as ferramentas usadas pelos engenheiros. Faça perguntas em linguagem simples, entenda o que mudou e permita que agentes de programação usem esse contexto para ajudar a resolver problemas de produção.

Use o Sazabi para alertas autônomos, depuração conversacional e fluxos de trabalho com agentes de programação. O Sazabi foi desenvolvido para equipes de engenharia que precisam encontrar e corrigir problemas de produção sem manter uma grande coleção de painéis e monitores estáticos. Explore o produto, as integrações, as práticas de segurança e os recursos para desenvolvedores para saber como o Sazabi se encaixa na sua stack.

Recursos

Detecção sem intervenção

Detecte os problemas que você não previu

Os monitores só detectam as falhas que você previu. O Sazabi monitora todos os logs e sinaliza o restante, desde interrupções silenciosas e usuários frustrados até agentes que saem do controle, a partir do momento em que você se conecta.

  • Detecção automática: Encontre mudanças nos seus logs sem escrever regras de alerta.
  • Análise da causa raiz: Agrupe erros relacionados e rastreie-os até o seu código.
  • Correções sugeridas: Dê aos engenheiros e agentes de programação um plano para resolver cada problema.

Monitoramento de segurança

Saiba no momento em que você fica exposto

O Sazabi verifica seu código em busca de falhas de segurança e avisa assim que uma nova CVE afeta algo que você executa. Quando botnets, fraudes ou invasores aparecem nos seus logs, sua equipe fica sabendo em tempo real.

  • Verificação de código: Encontre vulnerabilidades nos repositórios conectados.
  • Rastreamento de CVEs: Saiba quando uma nova vulnerabilidade afeta suas dependências.
  • Detecção de ameaças: Identifique botnets, fraudes e atividades suspeitas nos seus logs.

Busca em linguagem simples

Logs feitos para seus agentes

Seus agentes de programação depuram lendo logs, então o Sazabi mantém todos eles e facilita a busca. O armazenamento é barato o suficiente para você nunca precisar escolher o que descartar.

  • Busca em linguagem simples: Faça uma pergunta e receba uma resposta com os registros de log correspondentes.
  • Consultas estruturadas: Pesquise campos de log e padrões recorrentes para restringir uma investigação.
  • CLI & MCP: Permita que agentes de programação consultem logs de produção usando as próprias ferramentas.

Painéis sempre atualizados

Crie gráficos com tudo o que você já registra

Se está nos seus logs, você pode colocá-lo em um painel atualizado em tempo real: latência p99, memória, consultas lentas, cadastros. Você elimina totalmente o pipeline de métricas.

  • Painéis gerados por IA: Descreva o que deseja acompanhar e transforme seus logs em gráficos.
  • Métricas baseadas em logs: Crie gráficos de volume de logs, memória e CPU com os dados que você já envia.
  • Atualizações em tempo real: Mantenha os gráficos atualizados à medida que novos logs chegam.

Como o Sazabi funciona

  1. Conecte o GitHub e o Slack: Instale os aplicativos do GitHub e do Slack com poucos cliques. O Sazabi lê sua base de código para obter contexto e participa dos canais onde sua equipe já trabalha.
  2. Envie logs: Encaminhe logs das plataformas que você já usa. Estruturados ou não, o Sazabi os recebe como estão. Não é preciso criar esquemas, regras de análise ou painéis.
  3. Receba alertas: O Sazabi monitora seus logs em busca de anomalias, investiga cada uma delas com base no seu código e envia o problema ao Slack, Microsoft Teams ou e-mail, já com a causa raiz identificada.

Identifique problemas entre centenas de sinais

Tentativas de ataque

Anomalias de autenticação

Picos de falhas de login, preenchimento de credenciais, deslocamentos impossíveis, reutilização de sessão.

Tipo de problema: Ataque ativo (preenchimento de credenciais, varredura, tentativas de exploração.)

Preenchimento de credenciais em 900 contas

Status: Aberto

Descrição

Uma tentativa coordenada de login está testando credenciais em centenas de contas enquanto alterna os endereços de origem.

O que aconteceu

Os logs de autenticação contêm 2,000 falhas de login em 900 contas. A mesma sequência de contas aparece em diferentes IPs, ao contrário dos erros dispersos no tráfego normal de login. As falhas indicam uma tentativa automatizada de tomada de controle; elas não comprovam que alguma conta tenha sido acessada.

Como investigar

Agrupe as tentativas por conta e impressão digital da sessão, inspecione os logins bem-sucedidos nesse conjunto e limite a taxa do tráfego abusivo.

Payloads de ataque

Tentativas de injeção de SQL, travessia de diretórios, SSRF ou injeção de template em solicitações.

Tipo de problema: Ataque ativo (preenchimento de credenciais, varredura, tentativas de exploração.)

Sondagens de injeção de SQL contra uma ferramenta de observabilidade

Status: Aberto

Descrição

Sondagens de injeção de SQL não autenticadas chegaram ao banco de dados por meio de uma ferramenta de observabilidade auto-hospedada e passaram despercebidas pelo rastreamento de erros da equipe.

O que aconteceu

Alguém sem sessão enviou sondagens de injeção de SQL a uma ferramenta de observabilidade auto-hospedada que as encaminhou diretamente ao banco de dados. O rastreamento de erros da equipe não as detectou; pareciam apenas algumas solicitações com falha.

Como investigar

Rastreie o caminho da solicitação afetada e revise os logs de consultas ao banco de dados em busca de acessos não autorizados. Verifique a versão da ferramenta exposta e restrinja o tráfego de entrada durante a investigação.

Tentativas de exploração

Tráfego que corresponde a uma exploração conhecida contra sua stack.

Tipo de problema: Ataque ativo (preenchimento de credenciais, varredura, tentativas de exploração.)

Sondagens a um endpoint vulnerável

Status: Aberto

Descrição

As solicitações estão mirando o endpoint mencionado em um novo comunicado de segurança, levantando dúvidas sobre a exposição do aplicativo implantado.

O que aconteceu

Os logs de acesso mostram sondagens repetidas com a rota e o formato de payload descritos no comunicado. Essas solicitações ignoram a navegação comum e vão diretamente ao endpoint afetado. A correspondência do tráfego comprova uma tentativa de exploração, mas não confirma uma implantação vulnerável nem uma execução bem-sucedida.

Como investigar

Compare a versão do pacote implantado e as rotas habilitadas com o comunicado e, em seguida, inspecione as respostas e os efeitos subsequentes antes de decidir se é necessário aplicar uma correção ou conter a ameaça.

Bots e raspagem de dados

Clientes com alta taxa de solicitações, navegadores headless, IPs rotativos.

Tipo de problema: Abuso e fraude (abuso de promoções ou indicações, cadastros falsos, spam, raspagem de dados.)

Diretório sendo raspado

Status: Aberto

Descrição

Clientes automatizados percorrem o diretório da empresa em ordem, gerando carga de leitura contínua e coletando dados de perfil em massa.

O que aconteceu

Solicitações de uma rede percorrem todas as páginas do diretório em intervalos regulares e sem navegação intermediária. Endereços de cliente rotativos compartilham a mesma sequência de páginas e o mesmo formato de solicitação. A atividade difere da navegação interativa e expõe o diretório à coleta sistemática.

Como investigar

Revise quais campos podem ser lidos publicamente, agrupe os clientes por comportamento e aplique limites de taxa específicos para o diretório sem bloquear a navegação normal.

Acesso suspeito

Anomalias de acesso

Um agente lê muito mais dados do que o normal ou percorre IDs em sequência.

Tipo de problema: Acesso suspeito (contas comprometidas, uso indevido por pessoas internas, exfiltração de dados.)

Registros lidos em sequência

Status: Aberto

Descrição

Uma conta autenticada está enumerando milhares de registros em vez de seguir seu padrão habitual de navegação.

O que aconteceu

A conta solicita IDs de registro de 1 a 5,000 em sequência. As leituras bem-sucedidas continuam em registros que a sessão não alcançou por meio de pesquisa ou navegação. Isso indica coleta em massa e justifica verificar o escopo de acesso antes de presumir que todos os registros retornados estavam autorizados.

Como investigar

Inspecione a sessão, a carga de trabalho esperada e as decisões de autorização por registro. Revogue o acesso se não for autorizado e identifique quais registros foram retornados.

Alterações de privilégios

Novos administradores, elevações de função, novas chaves de API.

Tipo de problema: Acesso suspeito (contas comprometidas, uso indevido por pessoas internas, exfiltração de dados.)

Função de administrador concedida às 3h

Status: Aberto

Descrição

Uma conta recebeu privilégios de administrador de um local desconhecido e fora de sua atividade normal, criando um novo caminho para operações privilegiadas.

O que aconteceu

O registro de auditoria registra uma concessão de acesso de administrador às 3h, de um local que não aparece nas sessões anteriores do agente. O acesso subsequente usa a nova função. A concessão pode corresponder a uma manutenção legítima, mas é preciso verificar o agente, o horário e o escopo antes de confiar no privilégio.

Como investigar

Confirme a concessão com o proprietário da conta, inspecione a sessão que a autorizou e revise as ações privilegiadas subsequentes. Revogue a função se ela não tiver sido aprovada.

Saída de dados incomum

Grandes exportações ou respostas para um único agente.

Tipo de problema: Acesso suspeito (contas comprometidas, uso indevido por pessoas internas, exfiltração de dados.)

Exportação 50x maior que o normal

Status: Aberto

Descrição

Uma exportação está transferindo muito mais dados do que essa conta costuma obter, levantando a possibilidade de acesso em massa acidental ou não autorizado.

O que aconteceu

Uma resposta CSV é 50 vezes maior do que as exportações habituais da conta. A solicitação remove os filtros usados em exportações anteriores e retorna um conjunto de registros muito mais amplo. O tamanho comprova uma saída de dados incomum; ainda é preciso verificar a autorização e o escopo pretendido.

Como investigar

Compare os filtros da exportação, os campos retornados e as permissões da conta com a tarefa solicitada. Revise o destino e revogue a sessão se a exportação não tiver sido autorizada.

Agentes descontrolados

Agentes de IA, seus ou de terceiros, agem fora do escopo habitual.

Tipo de problema: Comportamento inadequado de agentes (agentes de IA agindo fora do escopo, injeção de prompt, ciclos descontrolados.)

Agente de suporte chamando um endpoint de administrador

Status: Aberto

Descrição

Um agente de suporte está invocando uma operação administrativa fora das ferramentas e do escopo usados em suas tarefas normais de suporte.

O que aconteceu

Os logs de chamadas de ferramentas mostram o agente acessando um endpoint de administrador que nunca havia usado antes. A chamada ocorre após conteúdo fornecido por um cliente, e não após uma instrução de um operador. Essa sequência levanta a possibilidade de uma violação de escopo; a resposta e o registro de auditoria devem confirmar se a operação realmente alterou algo.

Como investigar

Inspecione o conteúdo que acionou a chamada, os argumentos da ferramenta e o resultado da autorização. Restrinja as ferramentas do agente ao escopo de suporte e exija aprovação para ações administrativas.

Vulnerabilidades

Segredos ou dados pessoais nos logs

Tokens, chaves, e-mails ou números de identificação gravados nos logs.

Tipo de problema: Exposição (uma CVE que afeta você, um caminho de código vulnerável, uma configuração incorreta, segredos vazados.)

Chave de API impressa em um erro

Status: Aberto

Descrição

Um manipulador de erros está copiando uma credencial para a saída de diagnóstico, expondo-a a sistemas e pessoas com acesso aos logs.

O que aconteceu

Uma solicitação de saída com falha inclui sua chave de API na mensagem de erro registrada. O valor é propagado com a exceção em vez de ser ocultado no limite de registro. Qualquer pessoa capaz de ler esse registro pode reutilizar a chave até que ela seja revogada.

Como investigar

Revogue a chave exposta, identifique onde o registro foi entregue e retido e oculte as credenciais antes de serializar erros de solicitação.

Novo comunicado que afeta você

Uma CVE recém-publicada corresponde às suas dependências ou ao seu ambiente de execução (via cve.now).

Tipo de problema: Exposição (uma CVE que afeta você, um caminho de código vulnerável, uma configuração incorreta, segredos vazados.)

Novo comunicado corresponde ao seu lockfile

Status: Aberto

Descrição

Um comunicado de segurança recém-publicado sobre um framework inclui a versão fixada no lockfile do aplicativo, exigindo uma verificação de exposição em relação à compilação implantada. O que aconteceu

O intervalo de versões afetadas do aviso corresponde à dependência resolvida do framework. A correspondência no arquivo de lock identifica um artefato potencialmente vulnerável, mas não mostra se o recurso afetado está habilitado ou pode ser acessado. O build implantado e sua configuração de rotas determinam a exposição real.

Como investigar

Verifique a versão implantada e o recurso afetado, revise as medidas de mitigação do aviso, atualize para uma versão corrigida e teste a rota relevante.

Código arriscado

A análise de código sinaliza verificações de autenticação ausentes, desvios de autenticação ou riscos de injeção em novos commits.

Tipo de problema: Exposição (Uma CVE que afeta você, um caminho de código vulnerável, uma configuração incorreta, segredos vazados.)

Arquivos do host vazando em erros de implantação

Status: Aberto

Descrição

Falhas de implantação expuseram arquivos do host do builder aos usuários por meio de mensagens de erro que pareciam falhas comuns de análise.

O que aconteceu

Um builder de implantação leu arquivos do próprio host e os retornou aos usuários dentro de mensagens de erro de implantação, incluindo conteúdo no estilo de /etc/passwd. À primeira vista, eram implantações com falha e um erro de análise.

Como investigar

Rastreie como a entrada do build pode acessar arquivos do host e chegar à saída de erros. Revise os limites de extração de arquivos e remova o conteúdo de arquivos do host dos erros visíveis aos usuários.

Cadeia de suprimentos

Uma dependência muda de mantenedor, sofre typosquatting ou é sinalizada como maliciosa.

Tipo de problema: Exposição (Uma CVE que afeta você, um caminho de código vulnerável, uma configuração incorreta, segredos vazados.)

Versão de pacote comprometida

Status: Aberto

Descrição

Uma versão de dependência foi sinalizada como comprometida, e o arquivo de lock indica que ela pode estar incluída nos builds da aplicação.

O que aconteceu

A versão sinalizada do pacote corresponde à dependência resolvida, e não apenas a um intervalo permissivo de versões. Os registros de build precisam determinar onde essa versão foi instalada e se o código ou os scripts de instalação foram executados. A correspondência cria um risco de exposição, mas não prova que credenciais ou dados foram roubados.

Como investigar

Identifique os builds afetados, compare o pacote com a versão confiável, substitua-o e rotacione as credenciais somente nos casos em que a execução possa tê-las exposto.

Padrões de log

Evento desaparecido

Algo que normalmente acontece parou, embora o tráfego esteja normal.

Tipo de problema: Falha silenciosa (Um recurso parece funcionar, mas não funciona: ações sem efeito, exceções ignoradas, conclusão parcial, resultados incorretos, estados travados.)

As inscrições de aplicativos pararam de chegar

Status: Aberto

Descrição

Os eventos de envio de aplicativos pararam, enquanto os usuários continuaram acessando o formulário, o que sugere que o trabalho está sendo perdido sem um erro explícito.

O que aconteceu

O evento “Application submitted” desaparece depois das 14h14, enquanto as visualizações do formulário e as tentativas de envio continuam. O evento de conclusão habitual não ocorre mais após essas tentativas. O tráfego parece saudável, mas a transição ausente significa que os aplicativos talvez não estejam chegando ao estado persistido.

Como investigar

Rastreie uma tentativa de envio pela validação, persistência e emissão do evento. Compare os aplicativos armazenados com as tentativas para distinguir uma lacuna de registro de envios perdidos.

Mudança de volume

A taxa de um evento aumenta ou diminui muito além do padrão normal.

Tipo de problema: Abuso e fraude (Abuso de promoções ou indicações, inscrições falsas, spam, scraping.)

Pico de solicitações de redefinição de senha

Status: Aberto

Descrição

As solicitações de redefinição de senha estão muito acima do padrão semanal habitual, aumentando a carga de e-mails e podendo inundar os titulares das contas com mensagens indesejadas.

O que aconteceu

Os eventos de e-mail de redefinição ocorrem a uma taxa seis vezes maior que a normal para uma terça-feira, enquanto o tráfego comum de login permanece próximo da linha de base. Contas de destino repetidas e sequências de solicitações semelhantes respondem por grande parte do aumento. Isso aponta para abuso ou um loop acidental de novas tentativas, e não para um crescimento amplo de usuários.

Como investigar

Agrupe as solicitações por conta de destino e iniciador, verifique se há um loop de novas tentativas no cliente e aplique limites de redefinição por conta ao tráfego abusivo.

Sequência interrompida

A normalmente é seguido por B; agora A acontece sem B.

Tipo de problema: Falha silenciosa (Um recurso parece funcionar, mas não funciona: ações sem efeito, exceções ignoradas, conclusão parcial, resultados incorretos, estados travados.)

Uploads nunca são concluídos

Status: Aberto

Descrição

As solicitações de upload começam normalmente, mas não chegam à etapa de conclusão, deixando os arquivos indisponíveis mesmo depois que os usuários iniciam a transferência.

O que aconteceu

Os registros de “Upload started” continuam chegando, mas seus IDs de solicitação não têm um evento correspondente de “upload complete”. As conclusões ausentes se concentram após a transferência para o armazenamento. Os usuários ficam esperando por um arquivo que não foi finalizado, sem um erro correspondente na aplicação.

Como investigar

Acompanhe os IDs de upload afetados pelo armazenamento e pela finalização. Verifique uploads multipart abandonados, callbacks com falha e tratamento ausente de timeout ou erro.

Mudança de ordem ou tempo

As etapas acontecem fora de ordem ou com intervalos maiores.

Tipo de problema: Integridade de dados (Gravações perdidas, duplicatas, corrupção, registros incompatíveis.)

Webhooks processados antes da criação dos registros

Status: Aberto

Descrição

O processamento de webhooks está ocorrendo antes da criação do registro que ele atualiza, permitindo que um evento válido seja descartado como se os dados estivessem ausentes.

O que aconteceu

Os handlers de webhook consultam um registro antes de a transação de criação correspondente ser confirmada. A consulta não retorna nada, mas uma leitura posterior encontra o registro sem nenhuma atualização do webhook aplicada. A ordem dos eventos deixa o estado local defasado em relação ao provedor, embora ambas as solicitações sejam concluídas.

Como investigar

Correlacione o recebimento do webhook com as confirmações das transações, retenha eventos sem correspondência para novas tentativas e garanta que a reprodução seja segura quando o registro de destino existir.

Desvio de campo

Os valores dentro dos eventos mudam: novas categorias, valores nulos, strings vazias, tamanhos incomuns.

Tipo de problema: Integridade de dados (Gravações perdidas, duplicatas, corrupção, registros incompatíveis.)

Gravações sem a empresa associada

Status: Aberto

Descrição

Um subconjunto das gravações está perdendo a associação com a empresa, criando registros que não podem ser atribuídos ou recuperados de forma confiável no escopo esperado.

O que aconteceu

O campo company_id é null em 3% das gravações que antes tinham um valor. Esses registros compartilham um caminho de entrada que omite o contexto da empresa antes da persistência. As gravações são concluídas, mas as leituras posteriores com escopo de empresa não conseguem mais encontrá-las na coleção esperada.

Como investigar

Rastreie como o contexto da empresa chega a esse caminho de gravação, rejeite campos obrigatórios de propriedade ausentes e identifique os registros afetados antes de tentar uma correção com escopo definido.

Salto de cardinalidade

Um campo passa repentinamente a ter muito mais valores distintos.

Tipo de problema: Risco de capacidade (Sinal de que um limite está prestes a ser atingido.)

Chaves de cache se multiplicando

Status: Aberto

Descrição

O cache está criando novas chaves para solicitações que, de outra forma, seriam semelhantes, reduzindo a reutilização e aumentando a pressão sobre o armazenamento.

O que aconteceu

Milhares de chaves de cache distintas aparecem a cada minuto para o mesmo pequeno conjunto de rotas. As chaves variam em um sufixo específico da solicitação, então solicitações repetidas não encontram entradas que deveriam ser reutilizáveis. O conjunto crescente de chaves aumenta o uso de memória e transfere mais trabalho para o serviço de apoio.

Como investigar

Compare a construção antiga e a nova das chaves, remova campos específicos da solicitação que não deveriam estar presentes e verifique a expiração antes de limpar entradas inacessíveis.

Mensagens de falha discretas

Eventos que descrevem uma falha, mas são registrados como info ou debug.

Tipo de problema: Falha silenciosa (Um recurso parece funcionar, mas não funciona: ações sem efeito, exceções ignoradas, conclusão parcial, resultados incorretos, estados travados.)

Atualização de preços ignorou a maior conta

Status: Aberto

Descrição

Um job de preços tratou uma conta ignorada como uma conclusão bem-sucedida, deixando os usuários da maior conta com os custos de créditos anteriores.

O que aconteceu

Um job que aplicava alterações de preços ignorou a maior conta por causa de um limite codificado diretamente e, em seguida, informou “completed”. A conta ignorada foi registrada como info, então os usuários desse cliente continuaram pagando os custos antigos de créditos.

Como investigar

Revise o limite e o tratamento de contas ignoradas, execute novamente a atualização para a conta excluída e verifique os preços aplicados antes de registrar a conclusão.

Tempestade de novas tentativas

A mesma operação é repetida em loops apertados.

Tipo de problema: Falha de job em segundo plano (Trabalho agendado perdido, duplicado, travado ou vazio.)

Job repetindo em um loop apertado

Status: Aberto

Descrição

Um worker em segundo plano repete continuamente as tentativas para os mesmos registros com falha, sem avançar, consumindo capacidade necessária para outros jobs.

O que aconteceu

Um job tenta processar cada registro afetado 30 vezes em um loop apertado. O erro e a entrada permanecem inalterados entre as tentativas, e não há aumento progressivo do intervalo. As falhas repetidas ocupam o worker, em vez de permitir que registros independentes avancem ou de sinalizar o trabalho bloqueado.

Como investigar

Classifique o erro repetido como transitório ou permanente, aplique um backoff limitado e mova os registros que esgotaram as tentativas para um estado de falha que possa ser revisado.

Quebra de correlação

Dois serviços que normalmente avançam juntos divergem.

Tipo de problema: Falha de job em segundo plano (Trabalho agendado perdido, duplicado, travado ou vazio.)

Workers pararam de acompanhar o ritmo

Status: Aberto

Descrição

O tráfego da API está aumentando sem um aumento correspondente nas conclusões dos workers, o que sugere que o trabalho aceito não está mais chegando à fila ou saindo dela.

O que aconteceu

A API continua aceitando solicitações enquanto o número de jobs concluídos pelos workers permanece estável. Antes, as duas contagens avançavam juntas. A divergência significa que respostas bem-sucedidas da API já não demonstram que o trabalho em segundo plano solicitado foi concluído, e uma falha na fila ou no despacho pode estar oculta entre elas.

Como investigar

Compare as contagens de itens aceitos, enfileirados, iniciados e concluídos por ID de job para localizar a quebra antes de reproduzir ou escalar o trabalho.

Evento inédito

Um tipo de evento que nunca apareceu antes.

Tipo de problema: Regressão (Comportamento quebrado por uma implantação ou alteração de configuração específica.)

Rascunhos ignorados após a implantação

Status: Aberto

Descrição

Um novo caminho de salvamento está ignorando rascunhos bloqueados após uma versão, deixando as edições dos usuários sem aplicação e sem gerar uma exceção.

O que aconteceu

A mensagem “skipping save, draft locked” aparece pela primeira vez após a implantação. As solicitações afetadas retornam sem o evento normal de rascunho persistido, enquanto leituras posteriores ainda mostram a revisão anterior. A nova ramificação está impedindo o salvamento, em vez de apenas adicionar registros de diagnóstico.

Como investigar

Revise a verificação de bloqueio introduzida pela versão, inspecione a limpeza de bloqueios obsoletos e confirme que uma tentativa de salvamento rejeitada é claramente informada ao usuário.

Comportamento do usuário

Ação sem efeito

Um clique sem solicitação ao servidor ou uma solicitação sem resultado persistido.

Tipo de problema: Falha silenciosa (Um recurso parece funcionar, mas não funciona: ações sem efeito, exceções ignoradas, conclusão parcial, resultados incorretos, estados travados.)

Tela conectada, sem token

Status: Aberto

Descrição

O fluxo de conexão da conta indicou sucesso, embora o token OAuth nunca tenha sido persistido, deixando a conexão sem capacidade de autenticação.

O que aconteceu

Um usuário que conectou uma conta viu “connected”, mas o token OAuth nunca foi salvo. Um callback duplicado o levou à página de sucesso enquanto a solicitação original falhava em segundo plano.

Como investigar

Verifique em conjunto os resultados do callback original e do duplicado. Só informe que a conexão foi bem-sucedida depois que o token for armazenado e, em seguida, reconecte as contas afetadas.

Cliques repetidos e impacientes

O mesmo controle é clicado repetidamente.

Tipo de problema: Falha silenciosa (Um recurso parece funcionar, mas não funciona: ações sem efeito, exceções ignoradas, conclusão parcial, resultados incorretos, estados travados.)

Usuários clicando repetidamente em Save

Status: Aberto

Descrição Os usuários pressionam Salvar repetidamente porque o formulário não confirma se as alterações foram aceitas, incentivando novas tentativas que podem duplicar o trabalho.

O que aconteceu

O mesmo controle é clicado cinco vezes em dez segundos durante uma sessão. A primeira solicitação continua pendente enquanto os cliques seguintes iniciam mais solicitações, e nenhum estado de sucesso ou falha substitui o formulário. O padrão de interação sugere que o salvamento travou ou que falta feedback.

Como investigar

Rastreie a primeira solicitação de salvamento, exiba os estados pendente e de falha e impeça envios duplicados, verificando se as novas tentativas continuam seguras.

Abandono no funil

A conversão cai de uma etapa para outra.

Tipo de problema: Interrupção do fluxo de negócios (queda em uma métrica importante com causa técnica).

Conclusão do cadastro caiu para 50%

Status: Aberto

Descrição

Mais pessoas iniciam o cadastro do que o concluem, e a perda se concentra entre o envio do formulário e a criação da conta.

O que aconteceu

A conclusão do cadastro cai de 80% para 50%, enquanto o número de sessões iniciadas permanece comparável. As sessões chegam à etapa de envio, mas não registram um evento de criação de conta. A queda reflete uma integração incompleta, não apenas menos visitantes chegando ao site.

Como investigar

Compare os rastros de cadastros com falha e bem-sucedidos na primeira etapa ausente e, em seguida, segmente por resultado da validação, versão do cliente e provedor de identidade.

Ciclos de navegação

Os usuários alternam entre as mesmas páginas.

Tipo de problema: Falha silenciosa (um recurso parece funcionar, mas não funciona: ações sem efeito, exceções ignoradas, conclusão parcial, resultados incorretos, estados travados).

Usuários presos entre configurações e cobrança

Status: Aberto

Descrição

Os usuários são enviados de volta e para a frente entre as configurações e a cobrança sem chegar à tela necessária para concluir a tarefa.

O que aconteceu

As sessões seguem repetidamente configurações → cobrança → configurações, sem nenhum evento de conclusão entre elas. Cada destino redireciona o usuário com base em uma verificação diferente do estado da conta. O ciclo impede o acesso aos controles de cobrança, embora ambas as rotas retornem respostas bem-sucedidas.

Como investigar

Compare as condições de acesso e o estado da conta usados pelas duas rotas. Resolva os redirecionamentos conflitantes e verifique a jornada em uma sessão afetada.

Becos sem saída

As sessões terminam em estados de erro, telas em branco ou indicadores de carregamento infinitos.

Tipo de problema: Falha no frontend (não funciona em um navegador, dispositivo ou versão específica do app).

O indicador de carregamento do painel nunca termina

Status: Aberto

Descrição

O painel permanece no estado de carregamento até os usuários saírem, ocultando uma solicitação travada em vez de apresentar conteúdo utilizável ou um erro.

O que aconteceu

As sessões mostram o indicador de carregamento do painel por mais de 30 segundos antes de a aba ser fechada. A solicitação inicial de dados nunca produz um estado renderizado de sucesso ou falha. Outros recursos da página carregam normalmente, restringindo a falha ao caminho de carregamento de dados, e não a uma indisponibilidade completa da página.

Como investigar

Inspecione a solicitação pendente e o limite de erro do componente, adicione um estado de tempo limite recuperável e confirme que falhas de carregamento permitem que o usuário tente novamente.

Erros no cliente

Exceções de JavaScript, falhas de fetch, erros de hidratação.

Tipo de problema: Regressão (comportamento interrompido por uma implantação ou alteração de configuração específica).

Novo TypeError após o lançamento

Status: Aberto

Descrição

Uma página recém-lançada gera um TypeError durante a renderização, impedindo que os usuários afetados acessem seu conteúdo.

O que aconteceu

A exceção aparece pela primeira vez em sessões que usam a nova versão e compartilha uma localização na pilha de chamadas. O código com falha lê uma propriedade de um objeto de resposta ausente antes de renderizar a página. As solicitações podem ser bem-sucedidas na camada de rede enquanto a interface ainda não consegue exibir o resultado.

Como investigar

Associe a pilha de chamadas ao código-fonte lançado, inspecione o formato da resposta nas sessões afetadas e trate o valor ausente antes da renderização.

Regressão nos indicadores vitais da Web

O carregamento e a capacidade de resposta da página pioram.

Tipo de problema: Degradação de desempenho (páginas, tarefas ou APIs mais lentas, de forma repentina ou gradual).

Latência de interação dobrou

Status: Aberto

Descrição

As interações em uma página demoram visivelmente mais para produzir uma resposta visual, embora o servidor continue respondendo normalmente.

O que aconteceu

A latência de interação na página dobra em relação à linha de base anterior. Os rastros do navegador atribuem a espera adicional a um longo processamento na thread principal após a entrada do usuário, enquanto os tempos de rede permanecem comparáveis. Os usuários percebem uma interface atrasada sem um erro de API ou pico de latência correspondente.

Como investigar

Analise a tarefa longa após a entrada, compare o caminho de renderização alterado e mova ou reduza o trabalho síncrono antes de medir novamente a capacidade de resposta.

Comportamento específico de um segmento

Apenas um navegador, sistema operacional, versão do app, região ou cliente é afetado.

Tipo de problema: Falha no frontend (não funciona em um navegador, dispositivo ou versão específica do app).

Checkout falha no Safari 18

Status: Aberto

Descrição

O checkout falha em sessões do Safari 18, enquanto outros navegadores concluem o mesmo fluxo, ocultando a regressão na taxa geral de sucesso.

O que aconteceu

As sessões de checkout com falha se concentram no Safari 18. Os rastros do cliente param antes da solicitação de pagamento, enquanto o mesmo carrinho chega à etapa de pagamento em outros navegadores. A falha específica do navegador impede compras sem gerar uma falha correspondente no provedor de pagamento.

Como investigar

Reproduza a interação com falha no Safari 18, inspecione a compatibilidade das APIs do navegador e as exceções do cliente e, em seguida, verifique a correção nos navegadores em que o fluxo funciona.

Implantações e configuração

Mudança após a implantação

Qualquer outro sinal que comece minutos após uma implantação e esteja associado ao commit.

Tipo de problema: Regressão (comportamento interrompido por uma implantação ou alteração de configuração específica).

Funil caiu logo após o lançamento

Status: Aberto

Descrição

Uma versão coincide com menos jornadas de usuário concluídas e um novo evento de rejeição, associando a regressão a um caminho de solicitação alterado.

O que aconteceu

Quatro minutos após o lançamento, aparece um evento de validação nunca visto antes e a conclusão do funil cai. As sessões com falha chegam à mesma etapa e incluem o identificador da nova versão; as sessões na versão anterior ainda são concluídas. A comparação indica que o caminho lançado é o próximo ponto a investigar.

Como investigar

Compare a validação e o tratamento de respostas entre as duas versões. Reproduza a entrada afetada e avalie a reversão enquanto isola a alteração.

Alteração de configuração ou flag

O comportamento muda após uma alteração em uma flag de recurso, variável de ambiente ou infraestrutura.

Tipo de problema: Regressão (comportamento interrompido por uma implantação ou alteração de configuração específica).

Lançamento gradual da flag interrompe salvamentos

Status: Aberto

Descrição

Uma flag de recurso parcialmente habilitada está encaminhando um subconjunto dos salvamentos por um caminho com falha, enquanto o restante do tráfego continua normalmente.

O que aconteceu

A flag está habilitada para 10% do tráfego, e os salvamentos com falha representam a mesma proporção. Os registros de falha pertencem ao grupo com a flag habilitada; o grupo desabilitado continua persistindo as alterações. O limite do lançamento gradual oferece uma comparação direta para localizar a regressão.

Como investigar

Desabilite o grupo afetado pela flag, compare os dois caminhos de salvamento e verifique os resultados persistidos antes de ampliar novamente o lançamento gradual.

Alteração de dependência

Um pacote atualizado coincide com um novo comportamento.

Tipo de problema: Degradação de desempenho (páginas, tarefas ou APIs mais lentas, de forma repentina ou gradual).

Consultas lentas após a atualização do ORM

Status: Aberto

Descrição

Uma atualização do ORM altera a execução de uma leitura comum, tornando as solicitações mais lentas sem mudar a quantidade de dados solicitada pelos usuários.

O que aconteceu

Os registros de consultas lentas começam com a versão atualizada e se concentram em uma consulta gerada. A versão anterior usa um formato de consulta diferente para a mesma entrada, enquanto o volume de solicitações permanece comparável. A alteração da dependência é uma causa plausível do novo trabalho no banco de dados.

Como investigar

Compare o SQL gerado e os planos de consulta entre as versões do ORM, inspecione o comportamento de carregamento alterado e teste uma consulta corrigida ou a reversão da dependência.

Tratamento de erros que os oculta

Um commit adiciona tratamento genérico de erros a um caminho importante.

Tipo de problema: Falha silenciosa (um recurso parece funcionar, mas não funciona: ações sem efeito, exceções ignoradas, conclusão parcial, resultados incorretos, estados travados).

O controller oculta todas as exceções

Status: Aberto

Descrição

Agora, um controller converte operações com falha em respostas bem-sucedidas, impedindo que os chamadores e o monitoramento de erros reconheçam que o trabalho não foi concluído.

O que aconteceu

O controller alterado envolve sua operação principal em um manipulador genérico que retorna sucesso. Os rastros das solicitações incluem uma exceção antes da resposta, mas não há um resultado persistido correspondente. O novo manipulador mascara as falhas em vez de recuperá-las, então os usuários podem perder alterações sem ver um erro.

Como investigar

Revise o ramo de tratamento genérico, preserve as respostas de falha para operações malsucedidas e verifique se o sucesso só é retornado após a conclusão da gravação.

Efeito da migração

Uma migração de esquema altera o comportamento das consultas.

Tipo de problema: Degradação de desempenho (páginas, tarefas ou APIs mais lentas, de forma repentina ou gradual).

Consultas 20x mais lentas após a migração

Status: Aberto

Descrição

Uma migração de esquema remove o índice usado por uma consulta frequente, aumentando seu tempo de execução e tornando mais lentas as solicitações que dependem dela.

O que aconteceu

A consulta afetada demora 20 vezes mais após a migração. Seu plano muda de uma busca indexada para uma varredura ampla, enquanto o formato da solicitação permanece inalterado. A ausência do índice faz cada solicitação examinar muito mais linhas e aumenta o trabalho no banco de dados sob tráfego normal.

Como investigar

Compare a migração e os planos de consulta, confirme o formato de índice necessário e restaure um índice apropriado usando o procedimento seguro de migração do banco de dados.

Desempenho

Mudança repentina na latência

Um aumento súbito.

Tipo de problema: Regressão (comportamento interrompido por uma implantação ou alteração de configuração específica).

Carregamento da página saltou para 1.2s

Status: Aberto

Descrição

O carregamento das páginas ficou quatro vezes mais lento imediatamente após uma implantação, acrescentando uma espera perceptível a um fluxo de usuário que, de resto, funciona.

O que aconteceu

A duração do carregamento da página passa de 300ms para 1.2s após a implantação. Os rastros das solicitações mostram que o aumento ocorre no trecho de carregamento de dados do servidor, e não nos downloads de recursos. As respostas continuam sendo bem-sucedidas, então apenas a contagem de erros não revela a experiência mais lenta.

Como investigar

Compare o código de carregamento de dados e os tempos das consultas entre as versões da implantação e, em seguida, verifique o caminho lento com a mesma entrada de solicitação.

Aumento gradual da latência

Uma piora lenta ao longo de dias ou semanas que passa despercebida.

Tipo de problema: Degradação de desempenho (páginas, tarefas ou APIs mais lentas, de forma repentina ou gradual).

Busca fica mais lenta a cada semana

Status: Aberto

Descrição

A busca está ficando um pouco mais lenta a cada vez, acumulando um atraso perceptível para os usuários que não aparece como um único pico de incidente.

O que aconteceu

Buscas comparáveis demoram cerca de 5% mais a cada semana. A tendência persiste mesmo após considerar o volume de solicitações e se concentra na busca de dados, não na transferência da resposta. O aumento do trabalho por consulta é uma causa possível, embora nenhuma implantação isolada explique a tendência.

Como investigar

Compare os planos de consulta, as linhas examinadas e o tamanho do índice entre os períodos de referência. Verifique se o crescimento dos dados alterou o custo do caminho de busca mais comum.

Latência de cauda

Apenas as solicitações mais lentas pioram.

Tipo de problema: Degradação de desempenho (páginas, tarefas ou APIs mais lentas, de forma repentina ou gradual).

Latência p99 triplicou

Status: Aberto

Descrição

As solicitações mais lentas estão demorando muito mais, enquanto as solicitações típicas continuam rápidas, ocultando a experiência degradada de um grupo menor de usuários.

O que aconteceu

p99 de latência triplica enquanto a mediana permanece estável. Os rastros lentos passam a maior parte do tempo extra aguardando um recurso compartilhado antes da execução. As médias agregadas ocultam essas esperas, mas as solicitações afetadas continuam bloqueadas por tempo suficiente para correr o risco de atingir o tempo limite do cliente.

Como investigar

Agrupe os rastros lentos por recurso e carga de trabalho, compare o tempo de espera com o tempo de execução e inspecione a contenção antes de aumentar a capacidade.

Surgimento de consultas lentas

Uma nova consulta lenta ou um novo padrão N+1.

Tipo de problema: Degradação de desempenho (páginas, tarefas ou APIs mais lentas, de forma súbita ou gradual.)

Uma página fazendo 400 consultas

Status: Aberto

Descrição

Uma página está fazendo uma consulta separada ao banco de dados para cada item exibido, aumentando o tempo de resposta e a carga no banco de dados à medida que a lista cresce.

O que aconteceu

Uma solicitação de página agora executa 400 consultas com o mesmo formato de instrução e IDs de registro diferentes. As leituras repetidas ocorrem em série após a consulta inicial da lista. Esse padrão N+1 aumenta o trabalho proporcionalmente ao número de itens exibidos, em vez de buscar os dados relacionados em conjunto.

Como investigar

Rastreie a consulta por item, agrupe as leituras relacionadas ou use uma junção e compare a quantidade de consultas e o tempo de resposta com uma lista representativa.

Aumento gradual do tempo de inicialização e de partida a frio

Os serviços demoram mais para iniciar.

Tipo de problema: Risco de capacidade (Indicação de um limite antes que ele seja atingido.)

Implantações demoram para ficar saudáveis

Status: Aberto

Descrição

As novas instâncias demoram mais para ficar prontas, atrasando as implantações e reduzindo a rapidez com que o serviço consegue responder à demanda adicional.

O que aconteceu

O intervalo entre o início do processo e a prontidão saudável é três vezes maior que a linha de base anterior. Os logs de inicialização mostram o atraso extra antes da conclusão da inicialização, enquanto a latência das solicitações em estado estável permanece semelhante. Assim, as implantações e o escalonamento horizontal passam mais tempo aguardando capacidade utilizável.

Como investigar

Divida a inicialização em carregamento de dependências, inicialização e verificações de prontidão, compare cada fase com a versão anterior e remova trabalho desnecessário do caminho de prontidão.

Aumento do tempo de espera na fila

O trabalho espera mais tempo antes de começar.

Tipo de problema: Falha em tarefa em segundo plano (Trabalho agendado perdido, duplicado, travado ou vazio.)

E-mails enviados com 20 minutos de atraso

Status: Aberto

Descrição

As tarefas de e-mail ficam aguardando na fila muito antes da execução, atrasando as mensagens mesmo que o envio em si continue funcionando.

O que aconteceu

O intervalo entre o acionamento de um e-mail e a tentativa de envio chega a 20 minutos. Quando um worker inicia uma tarefa, os tempos de processamento e de resposta do provedor permanecem normais. O atraso ocorre antes da execução, portanto, apenas as contagens de entregas bem-sucedidas não revelam que as mensagens chegam tarde.

Como investigar

Compare a idade da fila, a concorrência dos workers e os tipos de tarefa concorrentes. Remova o gargalo ou separe os e-mails urgentes, preservando um comportamento seguro de novas tentativas.

Infraestrutura

Aproximação de um limite

Cotas de nuvem, créditos de burst, limites de taxa de API, identificadores de arquivo, limites do plano.

Tipo de problema: Risco de capacidade (Indicação de um limite antes que ele seja atingido.)

Créditos de burst se esgotando

Status: Aberto

Descrição

Os créditos de burst do sistema de arquivos estão sendo consumidos mais rápido do que se recuperam, colocando a inicialização e outras operações com uso intenso de armazenamento em risco de limitação.

O que aconteceu

O saldo de créditos diminui em intervalos sucessivos à medida que as leituras excedem a linha de base provisionada. A inicialização de novas instâncias ocorre ao mesmo tempo que essas leituras e depende da taxa de transferência disponível. A tendência indica que resta pouca capacidade de burst, mas não comprova que o volume já esteja sendo limitado.

Como investigar

Compare a taxa de transferência do armazenamento com a linha de base e a taxa de recuperação de créditos, identifique os principais leitores e ajuste o provisionamento ou as operações de E/S na inicialização antes que os créditos se esgotem.

Saturação

CPU, memória, pools de conexões, pools de threads, disco.

Tipo de problema: Risco de capacidade (Indicação de um limite antes que ele seja atingido.)

Pool de conexões quase cheio

Status: Aberto

Descrição

O pool de conexões do banco de dados tem pouca margem durante os picos de tráfego, fazendo com que as solicitações aguardem antes de poder executar uma consulta.

O que aconteceu

A utilização do pool chega a 95% no pico de carga, e as esperas para adquirir conexões aumentam junto com ela. O tempo de execução das consultas permanece relativamente estável assim que uma conexão fica disponível. A contenção ocorre no limite do pool e pode transformar picos normais de solicitações em tempos limite.

Como investigar

Inspecione as conexões mantidas por muito tempo e a duração das transações, verifique a capacidade do banco de dados e corrija a retenção desnecessária de conexões antes de aumentar o limite do pool.

Crescimento do backlog

Uma fila está crescendo mais rápido do que é esvaziada.

Tipo de problema: Falha em tarefa em segundo plano (Trabalho agendado perdido, duplicado, travado ou vazio.)

Fila de tarefas crescendo há 6 horas

Status: Aberto

Descrição

A entrada de tarefas supera as conclusões, aumentando continuamente a quantidade de trabalho aceito que aguarda processamento.

O que aconteceu

A fila de tarefas cresce por seis horas consecutivas porque a quantidade de tarefas enfileiradas permanece acima da quantidade de tarefas concluídas. As tarefas mais antigas continuam envelhecendo, embora os workers estejam ativos. O serviço está processando parte do trabalho, mas sua taxa de transferência é insuficiente para atender à carga recebida.

Como investigar

Compare as taxas de chegada e conclusão por tipo de tarefa, identifique trabalhos lentos ou repetidos e restaure capacidade de processamento suficiente para esvaziar o backlog mais antigo.

Agendamento perdido

Uma tarefa cron não foi executada, foi executada duas vezes ou demorou demais.

Tipo de problema: Falha em tarefa em segundo plano (Trabalho agendado perdido, duplicado, travado ou vazio.)

Exportação noturna não executada

Status: Aberto

Descrição

Uma exportação agendada não foi iniciada, deixando os consumidores downstream sem os dados atualizados normalmente produzidos por essa execução.

O que aconteceu

Não há registro de início ou conclusão da exportação noturna de domingo, embora existam registros das execuções agendadas próximas. Também não há saída para esse intervalo agendado. A lacuna é compatível com um acionamento perdido ou uma falha de admissão, e não com uma tarefa que foi executada e retornou um erro.

Como investigar

Verifique a execução do agendador, o tratamento de fuso horário e os bloqueios de sobreposição; em seguida, preencha o intervalo ausente após confirmar que a repetição não duplicará as exportações.

Ciclos de falha

Reinicializações, encerramentos por falta de memória, verificações de integridade com falha.

Tipo de problema: Falha em tarefa em segundo plano (Trabalho agendado perdido, duplicado, travado ou vazio.)

Worker reiniciando a cada 12 minutos

Status: Aberto

Descrição

Um worker reinicia repetidamente antes de conseguir manter o processamento normal, interrompendo tarefas em andamento e atrasando o trabalho enfileirado.

O que aconteceu

O worker inicia, processa tarefas e encerra em ciclos de aproximadamente 12 minutos. Cada reinicialização perde o estado atual do processo e é seguida pela reentrega do trabalho não concluído. O padrão indica falhas repetidas do processo, mas o motivo da saída precisa distinguir uma falha de um encerramento por falta de recursos ou de uma verificação de integridade malsucedida.

Como investigar

Inspecione os códigos de saída, o uso de memória e os eventos de verificação de integridade em torno de cada reinicialização. Corrija a falha e verifique se as tarefas interrompidas são retomadas sem efeitos colaterais duplicados.

Expiração próxima

Certificados, domínios, tokens de API, concessões OAuth.

Tipo de problema: Risco de capacidade (Indicação de um limite antes que ele seja atingido.)

Certificado TLS expirando

Status: Aberto

Descrição

Um certificado no caminho ativo de atendimento está próximo do vencimento, sem evidências de que um substituto tenha sido instalado.

O que aconteceu

O certificado TLS servido pelo endpoint expira em seis dias. Verificações repetidas ainda retornam o mesmo certificado, portanto, a renovação ainda não chegou à camada de atendimento. As conexões funcionam agora, mas falharão na validação se esse certificado continuar ativo após o fim do período de validade.

Como investigar

Verifique a automação de renovação e a implantação do certificado, instale o substituto e confirme o certificado realmente servido aos clientes.

Erros do provedor de nuvem

Limitação de taxa ou erros das APIs da AWS ou do GCP.

Tipo de problema: Falha de dependência (Um fornecedor ou serviço upstream está com problemas ou mudou.)

S3 deixando os uploads mais lentos

Status: Aberto

Descrição

Os uploads de objetos passam mais tempo repetindo solicitações ao provedor de armazenamento, deixando as transferências dos usuários mais lentas e ocupando os workers de upload.

O que aconteceu

As solicitações ao S3 retornam respostas SlowDown durante os uploads, seguidas por tentativas repetidas para os mesmos objetos. A duração adicional ocorre nas novas tentativas de armazenamento, e não no processamento local de arquivos. Respostas finais bem-sucedidas podem ocultar a espera e o uso extra de recursos ao longo do caminho de upload.

Como investigar

Revise a concorrência das solicitações e o intervalo entre novas tentativas, compare os prefixos de objetos afetados e confirme que os uploads limitados retomam com segurança sem reiniciar o trabalho já concluído.

Serviços de terceiros

Lacuna nos webhooks

Os webhooks de entrada esperados deixam de chegar.

Tipo de problema: Falha de dependência (Um fornecedor ou serviço upstream está com problemas ou mudou.)

Webhooks de entrega de e-mail pararam

Status: Aberto

Descrição

Os envios de e-mail continuam, mas os callbacks de entrega pararam, impedindo que o status de entrega local reflita o que o provedor realmente fez.

O que aconteceu

Nenhum evento de entrega de e-mail chega por uma hora, enquanto as solicitações de envio ainda recebem IDs do provedor. A lacuna se limita aos callbacks, e não a toda a atividade de e-mail. As mensagens podem ter sido entregues ou falhado sem que nenhum dos resultados chegasse à aplicação.

Como investigar

Compare os registros de entrega do provedor com os recebimentos locais de webhooks, verifique o endpoint de callback e a validação de assinatura e, em seguida, reproduza os eventos ausentes com segurança.

Degradação do fornecedor

Erros ou latência de um provedor do qual você depende.

Tipo de problema: Falha de dependência (Um fornecedor ou serviço upstream está com problemas ou mudou.)

Códigos de acesso nunca enviados

Status: Aberto

Descrição

As solicitações de acesso pareciam bem-sucedidas, enquanto o provedor de e-mail rejeitava as mensagens necessárias para que os usuários concluíssem a autenticação.

O que aconteceu

Os códigos de acesso nunca chegaram porque o provedor de e-mail deixou de considerar o domínio de envio verificado. O envio era executado como uma tarefa em segundo plano, então a API ainda retornava 200.

Como investigar

Restaure a verificação do domínio de envio e inspecione os resultados dos envios em segundo plano. Indique a rejeição da entrega do código em vez de tratar a resposta 200 da API como prova de entrega.

Limitação de taxa do fornecedor

Você está sendo limitado.

Tipo de problema: Falha de dependência (Um fornecedor ou serviço upstream está com problemas ou mudou.)

Cota da API de tickets esgotada todos os dias

Status: Aberto

Descrição

Uma coleta recorrente de tickets excedeu a cota do provedor e deixou a última região parcialmente desatualizada, embora continuasse informando conclusão normal.

O que aconteceu

Uma coleta diária atingiu a cota da API de tickets todos os dias durante duas semanas, com cerca de 10,5 mil solicitações para um limite de 10 mil. A última região nunca foi totalmente atualizada, e a tarefa terminou normalmente todas as vezes.

Como investigar

Distribua as solicitações entre as regiões, retome a partir da parte incompleta após a recuperação da cota e registre a conclusão parcial sempre que a coleta parar no limite do provedor.

Alteração de contrato

O formato da resposta de um fornecedor muda.

Tipo de problema: Falha de dependência (Um fornecedor ou serviço upstream está com problemas ou mudou.)

Campo do fornecedor chegando vazio

Status: Aberto

Descrição

A resposta de um provedor deixou de fornecer um campo exigido pela aplicação, interrompendo o processamento mesmo que a solicitação upstream seja bem-sucedida.

O que aconteceu

Valores que antes eram preenchidos chegam vazios em respostas bem-sucedidas do provedor. A aplicação ainda presume que o campo está presente e não consegue concluir a atualização correspondente. A mudança ocorre na fronteira da integração sem uma falha HTTP, portanto, o monitoramento no nível de transporte continua saudável.

Como investigar

Compare os formatos brutos das respostas com o contrato esperado e as mudanças do provedor, valide os campos obrigatórios e trate explicitamente o valor ausente antes de tentar novamente as atualizações.

Correspondência com incidente do fornecedor

A página de status de um provedor registra um incidente que coincide com seus erros.

Tipo de problema: Falha de dependência (Um fornecedor ou serviço upstream está com problemas ou mudou.)

Erros de login coincidem com um incidente do provedor

Status: Aberto

Descrição

As falhas de login coincidem com um incidente do provedor de identidade, sugerindo um problema de dependência upstream, e não uma indisponibilidade ampla do aplicativo.

O que aconteceu

Os erros de login começam no mesmo intervalo e região descritos na página de status do provedor de identidade. As falhas ocorrem durante a comunicação com o provedor, enquanto solicitações não relacionadas do aplicativo continuam funcionando. O momento e a dependência afetada sustentam a correlação, mas não descartam uma falha local adicional.

Como investigar

Compare as comunicações com falha com o escopo do incidente do provedor, verifique a configuração local e monitore a recuperação, oferecendo aos usuários uma opção clara para tentar novamente.

Desvio no comportamento do LLM

As saídas do modelo mudam: comprimento, recusas, JSON malformado, uso de tokens.

Tipo de problema: Falha de dependência (Um fornecedor ou serviço upstream está com problemas ou mudou.)

Saída estruturada falha em 4% das vezes

Status: Aberto

Descrição

As respostas do modelo estão violando o contrato de saída estruturada com mais frequência, impedindo que tarefas downstream consumam conclusões que, de outra forma, seriam bem-sucedidas.

O que aconteceu

As falhas de análise da saída estruturada aumentam de 0,1% para 4% no mesmo recurso. As respostas inválidas contêm campos ausentes ou texto fora do formato JSON esperado. As solicitações ao provedor ainda são concluídas, mas o aplicativo não pode usar esses resultados com segurança e precisa rejeitar ou tentar novamente as tarefas afetadas.

Como investigar

Compare a versão do modelo, os prompts e a validação do esquema antes e depois da mudança, inspecione as saídas inválidas e verifique uma correção com saída restrita antes de retomar o processamento normal.

Integridade dos dados

Gravação sem persistência

Um salvamento é confirmado, mas depois não aparece.

Tipo de problema: Falha silenciosa (Um recurso parece funcionar, mas não funciona: ações sem efeito, exceções ignoradas, conclusão parcial, resultados incorretos, estados travados.)

A sincronização de CI não salvou nada e informou sucesso

Status: Aberto

Descrição

Uma sincronização de CI informou sucesso após buscar pipelines, mas não armazenou nenhum, fazendo com que dados desatualizados do projeto parecessem resultado de uma atualização saudável.

O que aconteceu

Uma sincronização de CI executou por 30 minutos, buscou milhares de pipelines, não salvou nenhum e foi marcada como bem-sucedida. Erros por projeto foram ignorados, então o histórico de sincronização parecia saudável enquanto os dados ficavam desatualizados.

Como investigar

Inspecione os erros por projeto que foram ignorados, reconcilie os pipelines buscados com as linhas persistidas e execute novamente apenas os projetos afetados depois de verificar as gravações.

Processamento duplicado

O mesmo evento, trabalho ou pagamento é processado duas vezes.

Tipo de problema: Integridade dos dados (Gravações perdidas, duplicatas, corrupção, registros incompatíveis.)

Dois e-mails de boas-vindas por cadastro

Status: Aberto

Descrição

Cada nova conta recebe dois e-mails de boas-vindas porque o mesmo evento de cadastro pode acionar o envio mais de uma vez.

O que aconteceu

Duas tentativas de envio concluídas compartilham o mesmo ID de evento de cadastro e destinatário, mas usam IDs de entrega diferentes. Um evento repetido entra novamente no manipulador de e-mails de boas-vindas sem uma proteção de entrega registrada. O efeito colateral duplicado chega ao usuário, embora ambas as tentativas sejam bem-sucedidas individualmente.

Como investigar

Rastreie a reentrega do evento e a proteção de envio, torne a entrega idempotente para cada evento de cadastro e verifique se a reprodução gera apenas um e-mail.

Divergência na reconciliação

As contagens divergem entre sistemas.

Tipo de problema: Integridade dos dados (Gravações perdidas, duplicatas, corrupção, registros incompatíveis.)

Depósito pago, mas nunca creditado

Status: Aberto

Descrição

O pagamento posterior de um depósito não atualizou a carteira do usuário depois que o provedor havia informado anteriormente que o depósito falhou.

O que aconteceu

Um provedor de pagamentos informou que um depósito havia falhado e, 40 minutos depois, pagou o valor. O dinheiro chegou, mas a carteira do usuário nunca foi creditada, e nenhum erro foi registrado.

Como investigar

Compare o estado final do depósito no provedor com o livro-razão da carteira. Reconcilie o crédito ausente e verifique se mudanças posteriores de estado são tratadas sem gerar créditos duplicados.

Desvio nas métricas de negócio

Cadastros, solicitações, pagamentos ou mensagens ficam muito fora da faixa habitual.

Tipo de problema: Interrupção do fluxo de negócio (Queda em uma métrica importante com causa técnica.)

Solicitações caíram 35%

Status: Aberto

Descrição

O número de solicitações concluídas está abaixo do nível habitual, apesar de o tráfego de entrada ser comparável, indicando um problema no fluxo de envio.

O que aconteceu

As solicitações caíram 35% em comparação com a mesma hora da semana passada, enquanto as visitas ao formulário de solicitação permanecem comparáveis. A divergência começa entre as tentativas de envio e as solicitações armazenadas. Esse padrão sugere um problema de processamento ou validação, e não uma simples queda na demanda.

Como investigar

Compare os resultados de envio e os motivos de validação com o período de referência e, em seguida, rastreie as tentativas afetadas até a persistência antes de atribuir a queda ao comportamento dos usuários.

Saída vazia

Os trabalhos informam sucesso, mas não produzem nada.

Tipo de problema: Falha em trabalho em segundo plano (Trabalho agendado perdido, duplicado, travado ou vazio.)

A limpeza de retenção não redigiu nada

Status: Aberto

Descrição

Um trabalho de limpeza de retenção continuou sendo concluído sem redigir os dados de prompt que havia identificado para organizações que optaram por não manter esses dados.

O que aconteceu

Para organizações que optaram por não manter prompts, um trabalho de limpeza continuou encontrando dados para remover, redigiu zero linhas e prosseguiu. Ele foi executado conforme o agendamento, sem exceções, durante um mês em 11 organizações.

Como investigar

Compare a seleção de candidatos com o predicado de redação e a contagem de linhas afetadas. Verifique se os dados elegíveis foram removidos antes de executar novamente a limpeza afetada.

Dados desatualizados

Caches e trabalhos de sincronização param de atualizar.

Tipo de problema: Integridade dos dados (Gravações perdidas, duplicatas, corrupção, registros incompatíveis.)

Dados do diretório estão desatualizados há três dias

Status: Aberto

Descrição

As consultas ao diretório estão servindo um snapshot antigo, embora a fonte upstream tenha mudado, deixando os usuários com registros desatualizados.

O que aconteceu

A última atualização bem-sucedida do diretório ocorreu há três dias. As consultas continuam retornando esse snapshot, enquanto as tentativas de sincronização não avançam o marcador de atualização. As verificações de disponibilidade continuam indicando que está tudo bem porque o cache ainda responde, mas as entradas adicionadas ou alteradas estão ausentes.

Como investigar

Rastreie o trabalho de atualização e a atualização do checkpoint, compare os registros da fonte com o snapshot em cache e verifique a atualização após uma ressincronização segura.

Custos

Pico no volume de logs

Uma implantação fica repentinamente muito ruidosa.

Tipo de problema: Anomalia de custos (Os gastos com logs, nuvem ou uso de LLM aumentam repentinamente.)

Linha de depuração registrada 40 milhões de vezes por dia

Status: Aberto

Descrição

Uma mensagem de depuração que passou a ocorrer com mais frequência está dominando o fluxo de logs, aumentando o trabalho de ingestão e armazenamento sem um aumento correspondente no tráfego.

O que aconteceu

Uma linha de depuração representa 40 milhões de eventos de log por dia após uma implantação. O ponto em que ela é chamada fica dentro de uma operação repetida, então cada solicitação agora emite muitas cópias. A mudança de volume vem do comportamento do registro de logs, e não de um aumento comparável na atividade útil do aplicativo.

Como investigar

Localize a chamada de log repetida, reduza ou amostre as saídas redundantes e confirme que a cobertura de diagnóstico continua sendo útil depois que o volume voltar ao nível de referência.

Anomalia nos gastos com nuvem

Os gastos aumentam para um serviço ou recurso.

Tipo de problema: Anomalia de custos (Os gastos com logs, nuvem ou uso de LLM aumentam repentinamente.)

Custos de transferência de dados dobraram

Status: Aberto

Descrição

Os gastos com transferência de dados dobraram sem um crescimento comparável no tráfego, sugerindo que as solicitações estão movendo dados por um caminho mais caro.

O que aconteceu

Os custos de transferência dobram da noite para o dia, enquanto a quantidade de solicitações do aplicativo permanece semelhante. O aumento se concentra no tráfego entre serviços, e não no tamanho das respostas voltadas aos usuários. Uma mudança de roteamento ou posicionamento pode estar causando transferências repetidas ou entre regiões que as métricas comuns de solicitações não revelam.

Como investigar

Detalhe o uso de transferência por origem, destino e mudança de implantação e, em seguida, verifique se o roteamento ou buscas duplicadas explicam os bytes adicionais.

Pico nos gastos com LLM

O uso de tokens aumenta por recurso ou cliente.

Tipo de problema: Anomalia de custos (Os gastos com logs, nuvem ou uso de LLM aumentam repentinamente.)

Loop do agente consumiu o orçamento de uma semana

Status: Aberto

Descrição

Um agente emite repetidamente chamadas semelhantes ao modelo sem concluir a tarefa, concentrando um uso de tokens excepcionalmente alto em um único fluxo de trabalho.

O que aconteceu

A execução do agente de uma conta consome em um dia o orçamento normal de tokens de uma semana. Chamadas consecutivas repetem o mesmo resultado de ferramenta e carregam um contexto cada vez maior, mas não aparece nenhum resultado final da tarefa. O loop repetido aumenta os custos sem gerar progresso útil adicional.

Como investigar

Inspecione a decisão repetida e o resultado da ferramenta, interrompa a execução improdutiva e adicione novas tentativas limitadas e uma saída para ausência de progresso antes de reiniciar a tarefa.

Lacunas de telemetria

Serviço ficou em silêncio

Uma fonte para de enviar logs.

Tipo de problema: Lacuna de observabilidade (Pontos cegos ou telemetria que cria riscos.)

Frota de workers ficou em silêncio

Status: Aberto

Descrição

Uma frota de workers parou de emitir logs após uma mudança de configuração, removendo o rastro de diagnóstico necessário para entender o trabalho em andamento.

O que aconteceu

O volume de logs dos workers cai para zero, enquanto a atividade da fila mostra que os trabalhos continuam sendo processados. O silêncio começa com a mudança de configuração e afeta a frota, não apenas um host. Isso aponta para o caminho de registro ou entrega de logs, mas não prova que todos os workers pararam.

Como investigar

Compare a configuração do logger e do exporter com a versão anterior, inspecione os erros de entrega e verifique um evento conhecido de um worker, da emissão até a ingestão.

Formato ilegível

Um novo formato de log não pode ser analisado.

Tipo de problema: Lacuna de observabilidade (Pontos cegos ou telemetria que cria riscos.)

Novo formato de log ilegível

Status: Aberto

Descrição

Uma atualização do logger alterou a formatação dos registros, fazendo com que os logs recebidos perdessem os campos estruturados usados para análise e correlação.

O que aconteceu

A fonte continua enviando registros, mas as falhas de análise começam com o logger atualizado. As linhas brutas contêm um novo envelope em torno dos campos que o analisador espera no nível superior. Os eventos chegam sem gravidade, mensagem ou contexto de solicitação confiáveis, reduzindo seu valor para diagnóstico.

Como investigar

Compare os registros brutos antigos e novos, atualize o contrato de análise e verifique eventos representativos de várias linhas e de erro antes de considerar a fonte saudável.

Ponto cego

Uma rota ou trabalho importante não tem telemetria.

Tipo de problema: Lacuna de observabilidade (Pontos cegos ou telemetria que cria riscos.)

Endpoint de pagamentos não registra nada

Status: Aberto

Descrição

Um novo endpoint de pagamentos processa solicitações sem produzir telemetria do aplicativo, dificultando a investigação de falhas e operações incompletas.

O que aconteceu

Os registros de entrada mostram solicitações chegando ao endpoint, mas não há eventos correspondentes de início, resultado ou ID de solicitação no fluxo de logs. Outras rotas de pagamento continuam emitindo esses eventos. A falta de cobertura impede que uma solicitação seja acompanhada durante a validação, as chamadas ao provedor e a persistência.

Como investigar

Rastreie o middleware de registro da rota, adicione eventos estruturados de resultado com IDs de correlação e verifique o rastro sem registrar credenciais de pagamento ou dados confidenciais do payload.

Desvio do relógio

Os timestamps divergem entre as fontes.

Tipo de problema: Lacuna de observabilidade (Pontos cegos ou telemetria que cria riscos.)

Host está 4 minutos atrasado

Status: Aberto

Descrição Um host registra eventos com horários anteriores aos dos demais, fazendo com que uma única solicitação pareça ser executada fora de ordem entre os serviços.

O que aconteceu

Os eventos do host estão quatro minutos atrasados em relação aos IDs de solicitação correspondentes de outras fontes. Os horários de ingestão permanecem próximos, então a discrepância está no horário registrado do evento, e não em um atraso de transporte. Essa diferença distorce as linhas do tempo e pode induzir a análises de latência ou sequência ao erro.

Como investigar

Verifique a sincronização do horário do host e a serialização dos timestamps, corrija o relógio e compare novamente os eventos correlacionados antes de confiar na temporização entre serviços.

Exemplos do Catálogo de Detecção do Sazabi. Alguns sinais ainda estão a caminho.

Funciona com sua stack

Ver todas as integrações

Provedores de chat (3 integrações)

Provedores Git (2 integrações)

Rastreadores de problemas e plantão (6 integrações)

Fontes de logs (73 integrações)

Ferramentas de infraestrutura (17 integrações)

Ferramentas de banco de dados (12 integrações)

Ferramentas de IA e fluxo de trabalho (32 integrações)

Ferramentas de equipe e operações (43 integrações)

Estudos de caso

Ler estudos de caso

Weave

Como a Weave recupera mais de 20 horas de engenharia por semana ao substituir a detecção manual pelo Sazabi

O Sazabi transformou pontos cegos em problemas que detectamos e corrigimos antes que os clientes percebam. A melhor coisa depois de prevenir totalmente um problema é ficar sabendo dele imediatamente, e é exatamente isso que o Sazabi nos oferece.

Andrew Churchill, cofundador e CTO da Weave

  • 8,5 min: Tempo para encontrar a causa raiz de um problema em produção
  • 9 min: Tempo de configuração

Ler o estudo de caso

Mastra

Como a Mastra substitui investigações de 45 minutos por alertas de causa raiz do Sazabi

O Sazabi nos deu a visibilidade de produção de que precisávamos para o lançamento, sem precisar montar nossa configuração habitual de observabilidade. Agora é uma rede de segurança em que confiamos sempre que fazemos uma implantação.

Abhi Aiyer, cofundador e CTO da Mastra

  • 45 min: Tempo de investigação manual antes do Sazabi
  • 150 problemas: Problemas de produção identificados em duas semanas

Ler o estudo de caso

XMTP Labs

Como a XMTP Labs reduziu a detecção de bugs de dias para minutos com o Sazabi

Com o Sazabi como parte da nossa stack de observabilidade, chegamos às causas raiz muito mais rápido do que com qualquer abordagem anterior.

Nick Molnar, CTO da XMTP Labs

  • 5 min: Tempo para sinalizar um incidente grave
  • 20 min: Tempo para lançar uma correção para um problema crítico

Ler o estudo de caso

Do nosso blog

Ver todos os artigos

Uma abordagem diferente para observabilidade e segurança

01 Tudo é um log

Métricas, traces, eventos de aplicação, ações de agentes. Tudo descreve o que aconteceu. Os logs oferecem a humanos e agentes uma base comum para entender um sistema.

02 Os logs impulsionam a detecção de anomalias

Você não deveria precisar prever todas as falhas para detectá-las. Uma base de logs permite que o Sazabi descubra mudanças no comportamento do seu sistema e investigue o que aconteceu.

03 Feito para um mundo nativo em IA

A IA está mudando a forma como o software é desenvolvido e executado. O Sazabi oferece a humanos e agentes acesso compartilhado às evidências e ferramentas necessárias para agir.

O que dizem os clientes

Nos nossos dois primeiros dias, o Sazabi detectou cerca de 8 problemas que não teríamos encontrado de outra forma, nem mesmo com o Sentry.

Bence R., Hoplite

Vivendo no futuro: o Sazabi abre o PR, o Cursor avalia os riscos e aprova, e o CI fica todo verde.

Evan, AGREE

Nem todo alerta é de alta prioridade, mas todos permitem agir. Estou muito impressionado com a qualidade.

Yash N., Sandstone

Alguns dos problemas que o Sazabi envia me fazem ficar 🤯, de um jeito muito útil. Isso importa ainda mais à medida que nossos microsserviços crescem.

Nanda G., Taiga

Os alertas no Slack são tão bons que não precisei abrir o painel. Um agente de programação corrige os bugs assim que aparecem.

Charlie L., Autumn

O Sazabi é a espinha dorsal do nosso plantão. E, com os novos alertas de segurança, podemos entrar em pânico em tempo real.

Ed P., WAJO

Pronto para empresas

Traga sua própria nuvem

Execute a ingestão, o processamento e o armazenamento de logs na sua própria conta da AWS. O Sazabi opera a implantação.

  • Armazenamento sob controle da sua organização
  • Sua política de retenção
  • Acesso que você pode revogar

Ler o anúncio do BYOC

Conformidade

Padrões de segurança e compromissos de privacidade para apoiar a avaliação da sua equipe.

  • SOC 2
  • SOC 1
  • ISO 27017
  • ISO 27001
  • GDPR

Acessar a central de confiança

Acesso e segurança

Conecte seu provedor de identidade e controle o acesso em toda a sua organização.

  • SSO com SAML / OIDC
  • Provisionamento SCIM
  • Permissões baseadas em funções
  • Acesso restrito a projetos
  • Autenticação de dois fatores

Explorar controles de acesso

Perguntas frequentes

O que é o Sazabi?

O Sazabi é uma plataforma de observabilidade e segurança nativa em IA para equipes de engenharia e agentes de programação. Ele analisa seus logs de produção junto com seu código, detecta os problemas importantes, investiga cada um até chegar à causa raiz e envia os resultados às ferramentas que sua equipe já usa.

Preciso escrever monitores ou regras de alerta?

Não. O Sazabi monitora seus logs em busca de mudanças que mereçam uma análise mais detalhada, como um evento que deixa de ocorrer, uma etapa que começa a falhar silenciosamente ou uma latência que aumenta após uma implantação. O agente investiga esses sinais, confirma se há impacto real e só então abre um problema, sem monitores, limites ou regras de alerta para manter.

A quais logs e ferramentas o Sazabi se conecta?

Envie logs de fontes como Datadog, PostHog, Sentry, Google Cloud, Supabase e Cloudflare, e conecte seu código do GitHub para que o Sazabi possa rastrear problemas até o commit e o arquivo relacionados. Os problemas chegam à sua equipe pelo Slack, Microsoft Teams, e-mail ou SMS.

Como o Sazabi trabalha com agentes de programação?

Cada problema vem com sua causa raiz e um plano de correção que você pode entregar diretamente a um agente de programação, como Claude Code, Codex ou Cursor. Os agentes também podem consultar o Sazabi sobre seus logs pela CLI e pelo MCP enquanto trabalham.

Meus logs podem permanecer na minha própria nuvem?

Sim. Com o Sazabi BYOC, a ingestão, o processamento e o armazenamento de logs são executados na sua própria conta da AWS, e seus logs permanecem em um armazenamento pertencente à sua organização, enquanto o Sazabi opera a implantação. Os resultados das consultas e os trechos dos logs ainda podem chegar ao Sazabi e aos provedores de modelos.

Quanto custa o Sazabi?

O Hobby custa $50, o Startup $200 e o Growth $1,000 por ciclo de 30 dias, cada um com uso incluído. O Enterprise tem preços e condições personalizados. Consulte a página de preços para saber o que cada plano inclui.

Como começar?

Execute npx @sazabi/cli start no seu terminal para configurar o Sazabi ou siga o guia de início rápido na documentação.

URL canônica

https://www.sazabi.com