What BugSnag is
BugSnag is SmartBear's error monitoring and app stability service. SmartBear, the company behind software development and testing tools such as Swagger and TestComplete, acquired it in 2021, when BugSnag was an independent company based in San Francisco. It reports crashes and errors from mobile, web, desktop and server applications, and also covers performance monitoring and distributed tracing, which is built on OpenTelemetry.
Companies can use it as a hosted service, which keeps data in the United States, or run BugSnag On-premise in their own infrastructure. For Flutter there is bugsnag_flutter, a package BugSnag publishes itself, which reports Dart errors as well as native iOS and Android crashes; in all, BugSnag has SDKs for more than 50 platforms. Its stability scores are built to tell a team when to keep shipping features and when to fix bugs first, which is why it is one of the crash, error and performance monitoring tools our analytics and monitoring module connects to.
What it does in your platform
Analytics & monitoring
Collects crash and error reports from every part of your platform, the mobile apps, the web apps and the server, with the stack trace, device, app version and release in each, and turns sessions into a stability score for every release, so your team can see when fixes should come before new features. Reports identify the customer by the random platform ID, never by a name, email address or phone number: anything personal is taken out on the phone or the server before a report is sent, and redaction rules in BugSnag take out the fields you name a second time on arrival.
How the connection works
In the apps, BugSnag's own Flutter packages do the work: bugsnag_flutter reports errors and crashes, and bugsnag_flutter_performance times app starts, navigation and network requests. The web apps use BugSnag's JavaScript SDK, the server uses BugSnag's notifier for its own language, and each one tags its reports with the release that sent them.
Each build is labelled
Every build carries its version and release stage, and the BugSnag CLI uploads its Dart symbol files, Android mapping file and iOS dSYMs, so stack traces show method names, files and lines. Dart symbols only apply to errors reported after they arrive, so the pipeline uploads them before the build reaches anyone.
An error mid-transfer
A customer confirms a transfer and the confirmation screen fails with an unhandled error in the app's Dart code. The SDK builds a report with the stack trace, the device model and OS version, the app version and release, and the random platform ID in place of a name, and keeps it on the phone until there is a connection. Native iOS and Android crashes are reported too, the next time the app opens.
What the report leaves out
Before the report leaves the phone, an onError callback goes through it and takes out anything personal; redacted keys swap the values of fields named like password, token or IBAN for [REDACTED]. The SDK collects no location and, by BugSnag's own account, links nothing with other companies' data, so iPhones need no App Tracking Transparency prompt for it. If your data protection officer decides crash reports wait for consent, the module starts BugSnag only once the customer agrees.
BugSnag groups it and tells your team
On arrival, redaction rules your admins set remove the fields they name before the report is stored. BugSnag files it under one error together with every other report of the same failure, matched by error class and the top frame of your own code, shows how many users it touched, and tells your engineers in Slack or Microsoft Teams, or with a Jira issue or a PagerDuty incident.
The release gets its score
The SDK counts a session each time the app opens, or comes back after 30 seconds or more in the background. On the releases dashboard, each release gets a stability score, the percentage of its sessions or of its users that ran without an unhandled error, set against the target and critical levels your team chooses: below the critical level, fixing comes before new features.
The fix holds, or comes back
Once the next release is out, engineers mark the error fixed. Should the same error appear in a later version, BugSnag reopens it and puts it back in the inbox, and the new release's stability score shows whether the fix held.
Next to other providers
BugSnag is one of the module's crash, error and performance monitoring connectors, together with Sentry, Firebase Crashlytics, Datadog and New Relic. Mixpanel, Amplitude, PostHog and Google Analytics for Firebase follow the journeys customers take through the apps; BugSnag picks up the ones that end in a crash or an error, and rates each release by how often that happens. Every tool receives the same random platform ID, so an engineer can look up one customer's crashes by that ID while BugSnag never learns who the customer is.
The platform ID, the release names and the tracking plan's rules for what a report may hold are kept in your platform, not in BugSnag, and the app code reports through the module's own interface with BugSnag's SDK behind it. If you replace BugSnag with another crash reporter later, the next app release ships with a different connector, and your customers see the same screens and features.
When BugSnag fits best
A strong fit when
- You want one score per release that tells your team whether to ship features or fix bugs first.
- Your apps are mobile first, and you want native crashes, ANRs, app hangs and out-of-memory terminations next to Dart errors.
- You want the option of running the whole product in your own infrastructure, with BugSnag On-premise.
Also worth a look
- Sentry, when error data has to stay in an EU region run by the provider.
- Datadog or New Relic, when your servers are already monitored there and you want app errors in the same place.
How we get you live
The contract
We help you get your BugSnag account and contract in place, covering the stability scores and sensitive data management this page describes, with SmartBear's Data Processing Addendum, which brings in the EU Standard Contractual Clauses for data processed in the United States.
The data
BugSnag's hosted service keeps data in the United States; where it must stay in the EU, we help you set up BugSnag On-premise in your own infrastructure there instead. The tracking plan your team reviews lists everything a report may contain, the web apps run with BugSnag's collectUserIp option off so no browser IP addresses are kept, and redaction rules name the fields that must never be stored.
The keys
Inside the apps sits only the project's notifier API key, which can send reports; reading them back through BugSnag's Data Access API takes a personal auth token, which stays out of the apps. The separate upload API key for symbol files lives in your build pipeline's secrets, and the token for deletion requests in your platform's secrets.
A full test run
Before your first real customer, every app and the server send deliberate crashes, app hangs and handled errors to a separate BugSnag test project. We confirm that stack traces come back with method names and lines, that a test release gets its sessions and stability score, and that nothing personal reaches BugSnag.
