Free
Try it on one app
$0
No card needed
Start free- 1 project
- 10 bug reports a month
- 500 error events a month
- No screenshots
- No releases or impact
- No AI summaries
- 7-day history
- Docs support
Bugfed Insights
Give the people using your app a “Report a bug” button. Their reports land in your Bugfed dashboard with the app version, browser, OS and an optional screenshot, so you can reproduce the problem without a back-and-forth.
Already a Bugfed customer? It's in your dashboard: use the Testing | Insights switcher.
How it works
Name it and pick the platform. You get a public project key and a setup page with your key already in the snippets.
One script tag on the web, a few lines in Flutter. A “Report a bug” button appears, or open the form from your own menu. Turn on error capture if you want it.
Filter by status, version and environment. Set priority, mark duplicates, and leave notes your team can see but the reporter can't.
The setup page has a “Send a test report” button that checks the whole path before you touch your app, and it tells you when the first report from your app arrives.
What's ready
What works today is listed as available. Anything we haven't built yet is labelled as planned.
Impact numbers will only appear once they can be measured: we'll show what users did after hitting a bug, and we won't call that the cause.
Beyond reports
Uncaught errors grouped into issues by stack, not by line number, so a rebuild doesn't split them. Counts, installs affected, a sample with emails and tokens removed.
Each version's share of error-free installs, error events and new issues, so a bad release shows up the day it ships.
Whether installs that hit an issue came back within a week, next to those that didn't. With sample sizes, and never called the cause.
Privacy by default
Your users trust you with their data, so the SDK collects as little as it can. You can switch off screenshots and contact emails per project, and edit or drop any report before it leaves the device.
Bugfed Testing puts your build in front of vetted testers before release, including the 12-tester Google Play closed test. Same account and dashboard as Insights.
Pricing
Free shows you it works. Pro is for a live app.
Try it on one app
$0
No card needed
Start freeFor a live app with real users
$24/ month
$288 billed yearly
Get ProFor several apps or a busy one
$64/ month
$768 billed yearly
Get BusinessPrices in USD. Limits reset on the 1st of each month and are never billed as overage: past a limit, new data waits until the reset or an upgrade. Separate from Testing plans; one account can have both.
Pro is $29 a month ($24 billed yearly) and Business $79 ($64 yearly). The Free plan is for trying it: 1 project, 10 reports and 500 error events a month, 7 days of history. It's a separate subscription from Testing, and you don't need a Testing plan.
Nothing is billed as overage. New reports or errors for that month are refused politely (the SDK waits and tries later), you get a notice at 80% and at 100%, and you can upgrade at any time with the difference prorated. Everything resets on the 1st.
Web apps through a JavaScript SDK with a built-in reporting widget (plain HTML, React, Next.js, Vue and others), and Flutter through a Dart package with a report sheet. Both can capture errors. Native iOS and Android apps, React Native and servers can send reports and errors through the HTTP API. The Flutter package isn't on pub.dev yet; the docs show how to add it.
Yes. The key is public by design: it can only send reports to its project, never read anything. Reads always need a signed-in Bugfed account. Rate limits, an optional list of allowed websites, an on/off switch and key rotation protect a project from abuse.
Nothing until someone sends a report. Then it sends what they typed, a screenshot only if they chose one, your app version and environment, the browser, OS, screen size and language, and the page address without its query string. It never reads the page, form fields, cookies, the console or network requests. IP addresses aren't stored.
Yes, if you turn it on in the SDK. Uncaught exceptions and failed promises (web), and Flutter and platform errors (Flutter), are grouped into issues with counts, installs affected and a trend per release. Reports and errors stay separate, and a report links to the errors its sender hit just before. Native crash signals such as iOS crashes and Android ANRs aren't captured yet.
It shows what happened, not why. With session tracking on, an issue page compares how often installs that hit it came back within a week with installs active the same days that didn't, and shows the sample sizes and ranges. It only calls a difference clear when the ranges don't overlap, and never says the error caused it.
Nothing unless the project owner turns them on. When someone asks for a summary, the project's recent report titles and descriptions, error titles and release numbers go to our AI provider's API (Google Gemini or Anthropic Claude, paid tiers that don't train on your data), without emails or user ids. Every point in the summary links to the reports and errors it's based on, and with too little data it declines to summarise.
Yes. Team members you've invited to your Bugfed account can read and triage every report: status, priority, duplicates and internal notes. Only the account owner can change project settings, rotate the key or delete a project.