Uma linha no seu sistema e o erro passa a chegar aqui: agrupado, limpo de dado pessoal, com o cliente e a pessoa que o sofreram. Ele nasce como tarefa no Projetos e, quando esse cliente abre chamado, o erro já está anexado à conversa.
O bFocus já tem os projetos, os chamados e o cadastro dos seus clientes. O erro cai dentro disso, não ao lado disso.
Um erro inédito cadastra sozinho uma tarefa de bug, em rascunho, no projeto que você escolheu no agente — com onde estourou, o rastro e os números. A prioridade vem sugerida pela gravidade e pelo número de clientes atingidos; quem decide é a equipe.
Chamado aberto por quem teve erro nos últimos 30 minutos — ou por alguém do mesmo cliente nas últimas 2 horas — ganha uma nota interna ligando o chamado ao erro, à demanda e à provável causa. O atendente não precisa perguntar "o que apareceu na tela?".
Cada grupo mostra quantos clientes e quantas pessoas foram atingidos, e quem são. Só entra aí quem chegou com identidade assinada pelo seu servidor — a mesma assinatura do widget —, então não há vínculo adivinhado.
Instale o pacote da sua plataforma e chame `init` com a chave do agente (`bf_mon_…`), a versão e o ambiente. O pacote encadeia o tratador de erro que já existe em vez de substituí-lo: o seu sistema quebra exatamente como quebraria sem ele.
A query string é cortada antes de sair, e senha, token, cookie, CPF e cartão viram "[filtrado]". O pacote não manda corpo de requisição nem cabeçalho de autorização — e o servidor limpa tudo de novo na entrada.
A impressão digital do erro não leva cliente nem usuário: o mesmo erro em 300 clientes é um grupo só, com as ocorrências somando. O grupo guarda a quebra por cliente, por versão e por dia, e até 20 amostras completas, mais a primeira.
A mesma falha de novo não abre outra tarefa: comenta nos marcos (10, 100, 1.000 ocorrências; a cada 5 clientes novos). Concluir a demanda resolve o grupo, e um evento de versão mais nova que a corrigida reabre como regressão.
A regressão depende de uma versão no formato X.Y.Z no envio: sem ela, o bFocus não separa "voltou" de "ainda não atualizou", e não reabre a demanda por engano.
Com um repositório ligado ao agente, a investigação não fica no rastro: ela vai ao código da versão em que o erro aconteceu e volta com causa provável e linhas apontadas, dentro da própria demanda.
O bFocus não fornece IA e não cobra por investigação. Você cadastra a chave do seu provedor, escolhe o modelo e define o teto em reais; sem chave, o módulo funciona igual, só sem a análise.
Como a IA funciona aquiEste é o pedaço do caminho que, com uma ferramenta de erro à parte, ninguém percorre: a correção volta para a pessoa que levou o erro na tela — e para o chamado que ela abriu.
Publicada a nota daquela versão, o selo de novidades acende no widget do cliente — e o relatório mostra, cliente a cliente, quem leu.
Ver as novidades no app do clientePainel vazio pode ser um dia bom ou um agente que ninguém instalou. O bFocus separa os dois casos.
No servidor, a cada 5 minutos; no navegador e no app, no máximo a cada 30 minutos por aparelho. Silêncio longo demais marca o agente como silencioso — 15 minutos no servidor, 24 horas no front e no app, porque front só fala quando alguém abre.
Opcional: você dá uma URL e o bFocus pinga esperando 2xx ou 3xx, guardando a latência e o erro de quando cai. Serve para sistema web e API, ao lado da captura de erro.
O time é avisado quando o estado muda — vivo, silencioso, fora do ar —, não a cada verificação. Alerta que chega o tempo todo ninguém lê.
Um agente por parte monitorada (web, API, app), sempre ligado a um produto. A configuração mora no agente, não no produto.
De 0 a 100% dos erros enviados. Sistema de volume alto não precisa mandar tudo para o grupo contar certo.
Teto de eventos por dia no agente. Rajada de um sistema não consome o mês inteiro.
Expressões por mensagem, URL ou tipo do erro. Ruído conhecido (extensão de navegador, robô) não chega a virar grupo.
A chave de envio é pública, como a chave publicável do widget: no navegador, só as origens que você listou são aceitas, e você escolhe quais ambientes entram.
Onde a demanda nasce. Sem projeto definido, ela fica no backlog sem projeto, esperando alguém puxar.
Dois grupos que são o mesmo problema viram um, com os números somados e a demanda preservada.
Mesma rota, mesmo formato de evento e a mesma versão em todos. Nenhum deles tem dependência de runtime, e nenhum faz chamada de rede ao ser importado.
npm install @bfocus/monitor — ou uma tag <script> do nosso CDN, sem build nenhum. É o mesmo núcleo que já roda dentro do widget de chamados.
npm install @bfocus/monitor-node, com tratador para Express, plugin para Fastify e um envelope para Next e serverless.
npm install @bfocus/monitor-react-native, encadeando o tratador global que o app já tem, mais um ErrorBoundary.
pip install bfocus-monitor, com middleware para FastAPI e Starlette, Django e Flask.
composer require bfocus/monitor, com registro para Laravel 11 e middleware PSR-15 para Slim, Mezzio e Laminas.
dotnet add package Bfocus.Monitor.AspNetCore, com middleware de uma linha; o pacote base cobre netstandard2.0 e net8.0.
br.com.bernisoftware:bfocus-monitor no Maven Central, com filtro para Servlet e Spring.
go get github.com/bernisoftware/bfocus-monitor-go — Recover no defer, middleware de http.Handler e captura de erro na mão.
flutter pub add bfocus_monitor, cobrindo erro de widget, erro da plataforma e a zona do runApp.
Falha do monitor nunca derruba o seu sistema: a fila é limitada, o envio é em segundo plano e todo erro nosso é engolido. Chave recusada (401 ou 403) desliga o envio até o próximo init — não martelamos a nossa própria API.
Dá para contratar só o Monitoramento, sem nenhum outro módulo — é a porta de entrada mais barata que temos. Quem já assina um plano paga menos: ali a base do contrato já está paga, e o Monitoramento entra como adicional na mesma fatura.
Valores por mês, em reais, no plano anual; o botão mensal/anual da página de preços vale aqui também. Evento é cada erro que o seu sistema envia e o agente aceita — o que a amostragem e as regras de ignorar descartam não conta. A cota de eventos é a mesma nas duas formas: a diferença de preço é a base do contrato, não o módulo.
Não. O pacote corta a query string antes de enviar e não manda corpo de requisição, cookie nem cabeçalho de autorização; senha, token, CPF, CNPJ e cartão viram "[filtrado]". O servidor limpa de novo na entrada, então nem um pacote antigo nem um envio feito à mão passam por cima disso. O que liga o erro a uma pessoa é a identidade assinada pelo seu servidor, não um dado dentro da mensagem.
Não precisa contratar nada além do Monitoramento: ele existe como plano de um módulo só. Se você já assina algum plano, ele sai mais barato como adicional sobre o que você tem — na faixa do seu plano, na mesma fatura. E começar sozinho não fecha porta nenhuma: ao contratar outro módulo depois, o Monitoramento continua com você e passa a ser o adicional, com o valor aparecendo antes de você confirmar a troca.
O pacote encadeia o tratador de erro que já existe em vez de substituí-lo, não faz chamada de rede ao ser importado, mantém uma fila pequena em memória e engole qualquer falha própria. Se a chave for recusada, ele desliga o envio até a próxima inicialização em vez de insistir.
Vira uma. A impressão digital não leva cliente nem usuário, então o mesmo erro em 300 clientes é um grupo só, com as ocorrências somando e a quebra por cliente, por versão e por dia. A tarefa só ganha comentário nos marcos — 10, 100, 1.000 ocorrências e a cada 5 clientes novos.
Automático, não. Quando a correção sai numa versão, a tela oferece avisar as pessoas afetadas e alguém da equipe decide. Aí sai um e-mail com a marca da sua empresa para cada pessoa identificada que teve aquele erro, uma vez por grupo, mais uma nota interna em cada chamado ligado ao erro. O envio fica registrado no histórico, e a conta de demonstração não manda nada.
O grupo e os números ficam. As amostras completas — até 20 por grupo, mais a primeira que chegou — são apagadas depois de 30 dias, e um grupo ignorado sem nenhum evento há 90 dias sai de vez.
Por nós, não. Ela roda na chave do seu provedor, dentro dos tetos em reais que você definiu. Sem chave cadastrada, ou com o teto batido, a demanda ainda recebe o trecho de código e as correlações com commit, pull request e nota de versão.
Uma linha no seu sistema e o primeiro erro já chega agrupado, com o cliente que o sofreu e uma demanda esperando decisão.