Una línea en su sistema y el error empieza a llegar acá: agrupado, limpio de dato personal, con el cliente y la persona que lo sufrieron. Nace como tarea en Proyectos y, cuando ese cliente abre un ticket, el error ya está adjunto a la conversación.
bFocus ya tiene sus proyectos, sus tickets y el registro de sus clientes. El error cae dentro de eso, no al lado.
Un error inédito registra solo una tarea de bug, en borrador, en el proyecto que eligió en el agente — con dónde estalló, el rastro y los números. La prioridad viene sugerida por la gravedad y por la cantidad de clientes afectados; decide el equipo.
Un ticket abierto por quien tuvo un error en los últimos 30 minutos — o por alguien del mismo cliente en las últimas 2 horas — recibe una nota interna que une el ticket al error, a la tarea y a la causa probable. Nadie tiene que preguntar "¿qué apareció en la pantalla?".
Cada grupo muestra cuántos clientes y cuántas personas fueron afectados, y quiénes son. Solo entra ahí lo que llegó con identidad firmada por su servidor — la misma firma del widget —, así que no hay vínculo adivinado.
Instale el paquete de su plataforma y llame a `init` con la clave del agente (`bf_mon_…`), la versión y el ambiente. El paquete encadena el manejador de error que ya existe en lugar de reemplazarlo: su sistema falla exactamente como fallaría sin él.
La query string se corta antes de salir, y contraseña, token, cookie y documento se vuelven "[filtrado]". El paquete no manda cuerpo de petición ni cabecera de autorización — y el servidor vuelve a limpiar todo en la entrada.
La huella del error no lleva cliente ni usuario: el mismo error en 300 clientes es un solo grupo, con las ocurrencias sumando. El grupo guarda el detalle por cliente, por versión y por día, y hasta 20 muestras completas, más la primera.
La misma falla otra vez no abre otra tarea: comenta en los hitos (10, 100, 1.000 ocurrencias; cada 5 clientes nuevos). Terminar la tarea resuelve el grupo, y un evento de una versión más nueva que la corregida lo reabre como regresión.
La regresión depende de una versión en formato X.Y.Z en el envío: sin ella, bFocus no separa "volvió" de "todavía no actualizó", y no reabre la tarea por error.
Con un repositorio conectado al agente, la investigación va más allá del rastro: lee el código en la versión donde ocurrió el error y vuelve con causa probable y líneas señaladas, dentro de la propia tarea.
bFocus no provee IA y no cobra por investigación. Usted registra la clave de su proveedor, elige el modelo y define el tope en reales; sin clave, el módulo funciona igual, solo sin el análisis.
Cómo funciona la IA acáEste es el tramo del camino que, con una herramienta de errores aparte, nadie recorre: la corrección vuelve a la persona que se llevó el error en la pantalla — y al ticket que ella abrió.
Publicada la nota de esa versión, el distintivo de novedades se enciende en el widget del cliente — y el informe muestra, cliente por cliente, quién la leyó.
Ver las novedades en la app del clienteUn panel vacío puede ser un buen día o un agente que nadie instaló. bFocus separa los dos casos.
En el servidor, cada 5 minutos; en el navegador y en la app, como máximo cada 30 minutos por aparato. Demasiado silencio marca el agente como silencioso — 15 minutos en el servidor, 24 horas en el front y en la app, que solo hablan cuando alguien los abre.
Opcional: usted da una URL y bFocus la pinga esperando 2xx o 3xx, guardando la latencia y el error cuando se cae. Para sistemas web y API, junto a la captura de errores.
El equipo se entera cuando el estado cambia — vivo, silencioso, caído —, no en cada verificación. Alerta que llega todo el tiempo no la lee nadie.
Un agente por parte monitoreada (web, API, app), siempre ligado a un producto. La configuración vive en el agente, nunca en el producto.
De 0 a 100% de los errores enviados. Un sistema de alto volumen no necesita mandar todo para que el grupo cuente bien.
Un tope de eventos por día en el agente. La ráfaga de un sistema no se come el mes entero.
Expresiones por mensaje, URL o tipo de error. El ruido conocido — extensión de navegador, robot — nunca llega a ser grupo.
La clave de envío es pública, como la clave publicable del widget: en el navegador solo se aceptan los orígenes que usted listó, y usted elige qué ambientes entran.
Dónde nace la tarea. Sin proyecto definido, queda en el backlog sin proyecto.
Dos grupos que son el mismo problema se vuelven uno, con los números sumados y la tarea preservada.
Misma ruta, mismo formato de evento y la misma versión en todas. Ninguna tiene dependencia de runtime, y ninguna hace llamada de red al importarse.
npm install @bfocus/monitor — o una etiqueta <script> de nuestro CDN, sin build. Es el mismo núcleo que ya corre dentro del widget de tickets.
npm install @bfocus/monitor-node, con manejador para Express, plugin para Fastify y un envoltorio para Next y serverless.
npm install @bfocus/monitor-react-native, encadenando el manejador global que la app ya tiene, más un ErrorBoundary.
pip install bfocus-monitor, con middleware para FastAPI y Starlette, Django y Flask.
composer require bfocus/monitor, con registro para Laravel 11 y middleware PSR-15 para Slim, Mezzio y Laminas.
dotnet add package Bfocus.Monitor.AspNetCore, una línea de middleware; el paquete base cubre netstandard2.0 y net8.0.
br.com.bernisoftware:bfocus-monitor en Maven Central, con filtro para Servlet y Spring.
go get github.com/bernisoftware/bfocus-monitor-go — Recover en un defer, middleware de http.Handler y captura manual de error.
flutter pub add bfocus_monitor, cubriendo error de widget, error de plataforma y la zona del runApp.
Una falla del monitor nunca tira su sistema: la cola es limitada, el envío ocurre en segundo plano y cualquier error nuestro se traga. Una clave rechazada (401 o 403) apaga el envío hasta el próximo init — no martillamos nuestra propia API.
Se puede contratar solo el Monitoreo, sin ningún otro módulo — es la puerta de entrada más barata que tenemos. Quien ya tiene un plan paga menos: allá la base del contrato ya está pagada, y el Monitoreo entra como adicional en la misma factura.
Por mes, en reales, en el plan anual; el botón mensual/anual de la página de precios vale acá también. Un evento es cada error que su sistema envía y el agente acepta — lo que el muestreo y las reglas de ignorar descartan no cuenta. La cuota de eventos es la misma en las dos formas: la diferencia de precio es la base del contrato, no el módulo.
No. El paquete corta la query string antes de enviar y no manda cuerpo de petición, cookie ni cabecera de autorización; contraseña, token, documento y tarjeta se vuelven "[filtrado]". El servidor limpia de nuevo en la entrada, así que ni un paquete viejo ni un envío hecho a mano pasan por encima. Lo que une el error a una persona es la identidad firmada por su servidor, no un dato dentro del mensaje.
No necesita contratar nada además del Monitoreo: existe como plan de un módulo solo. Si ya tiene un plan, sale más barato como adicional sobre lo que tiene — en el tamaño de su plan, en la misma factura. Y empezar solo no cierra ninguna puerta: al contratar otro módulo después, el Monitoreo sigue con usted y pasa a ser el adicional, con el valor apareciendo antes de que confirme el cambio.
El paquete encadena el manejador de error que ya existe en lugar de reemplazarlo, no hace llamada de red al importarse, mantiene una cola pequeña en memoria y se traga cualquier falla propia. Si la clave es rechazada, apaga el envío hasta la próxima inicialización en vez de insistir.
Crea una. La huella no lleva cliente ni usuario, así que el mismo error en 300 clientes es un solo grupo, con las ocurrencias sumando y el detalle por cliente, por versión y por día. La tarea solo recibe comentario en los hitos — 10, 100, 1.000 ocurrencias y cada 5 clientes nuevos.
Automático, no. Cuando la corrección sale en una versión, la pantalla ofrece avisar a las personas afectadas y alguien del equipo decide. Entonces sale un correo con la marca de su empresa para cada persona identificada que tuvo ese error, una vez por grupo, más una nota interna en cada ticket vinculado. El envío queda registrado en el historial, y la cuenta de demostración no manda nada.
El grupo y sus números quedan. Las muestras completas — hasta 20 por grupo, más la primera que llegó — se borran después de 30 días, y un grupo ignorado sin ningún evento desde hace 90 días se elimina.
Por nosotros, no. Corre con la clave de su proveedor, dentro de los topes en reales que usted definió. Sin clave registrada, o con el tope alcanzado, la tarea igual recibe el fragmento de código y las correlaciones con commit, pull request y nota de versión.
Una línea en su sistema y el primer error ya llega agrupado, con el cliente que lo sufrió y una tarea esperando decisión.