One line in your system and errors start landing here: grouped, scrubbed of personal data, with the customer and the person who hit them. Each one opens as a task in Projects — and when that customer opens a ticket, the error is already attached to the conversation.
bFocus already holds your projects, your tickets and your customer records. The error lands inside that, not beside it.
A first-time error files its own bug task, as a draft, in the project you chose on the agent — with where it blew up, the stack trace and the numbers. Priority comes suggested from severity and the number of customers hit; the team decides.
A ticket opened by someone who hit an error in the last 30 minutes — or by anyone at the same customer in the last 2 hours — gets an internal note linking the ticket to the error, the task and the probable cause. No one has to ask "what did the screen say?".
Every group shows how many customers and how many people were hit, and who they are. Only events that arrived with an identity signed by your server — the same signature the widget uses — count there, so no link is guessed.
Install the package for your platform and call `init` with the agent key (`bf_mon_…`), the release and the environment. The package chains the error handler you already have instead of replacing it: your system fails exactly as it would without us.
The query string is cut before anything leaves, and passwords, tokens, cookies and national IDs become "[filtered]". The package never sends request bodies or authorization headers — and the server scrubs everything again on the way in.
The fingerprint carries no customer and no user: the same error across 300 customers is one group, with occurrences adding up. The group keeps the breakdown per customer, per release and per day, plus up to 20 full samples and the very first one.
The same failure again does not open another task: it comments at milestones (10, 100, 1,000 occurrences; every 5 new customers). Closing the task resolves the group, and an event from a release newer than the fixed one reopens it as a regression.
Regression detection needs an X.Y.Z release in the payload: without it, bFocus cannot tell "it came back" from "they have not updated yet", and will not reopen the task by mistake.
With a repository wired to the agent, the investigation goes past the stack trace: it reads the code at the release where the error happened and comes back with a probable cause and pointed-at lines, inside the task itself.
bFocus does not supply AI and does not charge per investigation. You register your provider’s key, pick the model and set the cap in reais; with no key, the module works the same, just without the analysis.
How AI works hereThis is the stretch of the path that nobody walks when the error tool sits off to the side: the fix comes back to the person who got the error on screen — and to the ticket they opened.
Publish that version’s note and the news badge lights up in the customer’s widget — and the report shows, customer by customer, who read it.
See release notes inside your appAn empty dashboard can be a good day or an agent nobody installed. bFocus tells the two apart.
Every 5 minutes on a server; at most every 30 minutes per device in a browser or an app. Too long without a signal marks the agent as silent — 15 minutes on a server, 24 hours on front ends and apps, which only speak when someone opens them.
Optional: give a URL and bFocus pings it expecting 2xx or 3xx, keeping the latency and the error when it goes down. For web systems and APIs, alongside error capture.
The team hears about it when the state changes — alive, silent, down — not on every check. Alerts that arrive all the time are alerts nobody reads.
One agent per monitored surface (web, API, app), always tied to a product. The configuration lives on the agent, never on the product.
From 0 to 100% of errors sent. A high-volume system does not need to send everything for the group to count correctly.
A ceiling of events per day on the agent. One system’s burst does not eat the whole month.
Patterns on message, URL or error type. Known noise — browser extensions, bots — never becomes a group.
The ingest key is public, like the widget’s publishable key: in a browser only the origins you listed are accepted, and you choose which environments count.
Where the task is born. With no project set, it waits in the backlog with no project.
Two groups that are the same problem become one, with the numbers added up and the task preserved.
Same route, same event format and the same version on all of them. None has a runtime dependency, and none makes a network call on import.
npm install @bfocus/monitor — or a <script> tag from our CDN, with no build step. It is the same core that already runs inside the support widget.
npm install @bfocus/monitor-node, with an Express handler, a Fastify plugin and a wrapper for Next and serverless.
npm install @bfocus/monitor-react-native, chaining the global handler the app already has, plus an ErrorBoundary.
pip install bfocus-monitor, with middleware for FastAPI and Starlette, Django and Flask.
composer require bfocus/monitor, with a Laravel 11 registration and PSR-15 middleware for Slim, Mezzio and Laminas.
dotnet add package Bfocus.Monitor.AspNetCore, one line of middleware; the base package targets netstandard2.0 and net8.0.
br.com.bernisoftware:bfocus-monitor on Maven Central, with a filter for Servlet and Spring.
go get github.com/bernisoftware/bfocus-monitor-go — Recover in a defer, an http.Handler middleware and manual error capture.
flutter pub add bfocus_monitor, covering widget errors, platform errors and the runApp zone.
A failure in the monitor never takes your system down: the queue is bounded, sending happens in the background and any error of ours is swallowed. A rejected key (401 or 403) switches sending off until the next init — we do not hammer our own API.
You can subscribe to Monitoring alone, with no other module — it is the cheapest front door we have. If you already have a plan you pay less: there the base of the contract is already paid for, and Monitoring joins the same invoice as an add-on.
Per month, in Brazilian reais, on the annual plan; the monthly/annual switch on the pricing page applies here too. An event is each error your system sends and the agent accepts — whatever sampling and ignore rules drop does not count. The event quota is the same either way: the price difference is the base of the contract, not the module.
No. The package cuts the query string before sending and never sends request bodies, cookies or authorization headers; passwords, tokens, national IDs and card numbers become "[filtered]". The server scrubs everything again on the way in, so neither an old package nor a hand-made request can get around it. What ties an error to a person is the identity signed by your server, not something inside the message.
You do not need anything beyond Monitoring: it exists as a plan with a single module. If you already subscribe to a plan, it costs less as an add-on on top of what you have — at your plan’s tier, on the same invoice. And starting alone closes no door: add another module later and Monitoring stays with you as the add-on, with the amount shown before you confirm the change.
The package chains the error handler you already have instead of replacing it, makes no network call on import, keeps a small bounded queue in memory and swallows any failure of its own. If the key is rejected it switches sending off until the next initialization rather than retrying forever.
It creates one. The fingerprint carries no customer and no user, so the same error across 300 customers is a single group, with occurrences adding up and a breakdown per customer, per release and per day. The task only gets a comment at milestones — 10, 100, 1,000 occurrences and every 5 new customers.
Automatic, no. Once the fix ships in a version, the screen offers to tell the people who were hit and someone on the team decides. Then an email goes out in your company’s brand to every identified person who hit that error, once per group, plus an internal note on every ticket linked to it. The send is recorded in the history, and the demo account sends nothing.
The group and its numbers stay. Full samples — up to 20 per group, plus the first one that arrived — are deleted after 30 days, and an ignored group with no event for 90 days is removed for good.
Not by us. It runs on your provider’s key, within the caps in reais you set. With no key registered, or the cap reached, the task still gets the code excerpt and the correlations with commit, pull request and release note.
One line in your system and the first error already arrives grouped, with the customer who hit it and a task waiting for a decision.