What Sentry is
Sentry is an application monitoring platform made by Functional Software, Inc., a company based in San Francisco. It started out in 2008 as an open-source project, and today covers error monitoring, tracing, session replay, profiling, logs, and cron and uptime monitoring.
It runs as a hosted service with a US and an EU data region, and its server code is published under the Functional Source License, so companies can also run it themselves. Sentry publishes its own Flutter SDK, sentry_flutter, which catches Dart errors and native crashes on iOS and Android, and maintains SDKs for most popular languages. Errors from the apps, the web apps and the server end up in one place, which is why it is one of the crash and error monitoring tools our analytics and monitoring module connects to.
What it does in your platform
Analytics & monitoring
Catches crashes and errors in your mobile apps, web apps and server, each with the stack trace, the device, the app version and the release that introduced it, so engineers can fix problems before customers report them. Reports name a customer only by the random platform ID: personal data is stripped before a report is sent, and Sentry's server-side scrubbing checks again.
How the connection works
The apps use Sentry's official Flutter SDK, sentry_flutter, which also catches native crashes on iOS and Android. The web apps and the server report through Sentry's SDKs for their languages, tracing follows a request from the app to the server, and every report carries its release.
A new version is built
Each build gets a release name, and the Sentry Dart Plugin uploads its debug symbols and Dart obfuscation map, so Sentry can turn obfuscated stack traces back into function names, files and lines.
The app crashes
A customer opens their card screen and the app crashes. The SDK records the stack trace, the device, the app version and the release, and knows the customer only by the random platform ID. If the phone is offline, the report is stored and sent later.
Personal data stays behind
Before the report leaves the phone, the app strips personal data from it in the SDK's beforeSend hook. The sendDefaultPii option stays off, so the SDK adds no IP address, device name or user details of its own. Where Session Replay is on, it masks all text, images and input by default, and card and identity screens in full.
Sentry checks again
On arrival, Sentry's server-side scrubbing removes values that look like card numbers and fields named like passwords, secrets or tokens. The project stores no IP addresses, and a scrubbing rule also removes the location Sentry works out from them. Sentry then groups the crash with the same crash from other phones into one issue.
Engineers are alerted
The issue shows how many customers it touched and the release that introduced it, and an alert reaches your engineers in the chat or issue tracker they already use.
The fix is confirmed
Engineers resolve the issue in the next release. Release health shows the share of crash-free sessions and users for each release, and if the crash comes back in a newer one, Sentry marks the issue as regressed.
Next to other providers
Sentry is one of the module's crash, error and performance monitoring connectors, next to Firebase Crashlytics, Datadog, New Relic and BugSnag. Mixpanel, Amplitude or Google Analytics for Firebase show what customers do; Sentry shows your engineers what broke. Every tool sees the same random platform ID and never a name, so a customer's crash can be found by that ID without passing on their personal details.
The apps and the server report through the module's one interface, and the release names, the platform ID and what a report may carry are set in your platform rather than in Sentry. Moving to another crash reporter later swaps the connector in the next release of the apps, and your screens and features stay the same.
When Sentry fits best
A strong fit when
- You want crashes and errors from your mobile apps, web apps and server in one place, linked by tracing.
- Your engineers ship often and want each release's crash-free rate and the issues it introduced.
- You want error data stored in the EU, with scrubbing rules your team controls.
Also worth a look
- Firebase Crashlytics, when your apps already use Firebase for sign-in or push.
- An error tracker your team already runs, a self-hosted Sentry included: it becomes one more connector.
How we get you live
The contract
We help you get your Sentry account and contract in place, with Sentry's Data Processing Addendum, the GDPR terms that cover the data your reports carry.
The data
We create your Sentry organisation in the EU data region, in Frankfurt, a choice Sentry does not let you change later. What a report may carry goes on the tracking plan your team reviews, and server-side scrubbing gets extra rules for account numbers and other identifiers.
The keys
The apps carry only each project's DSN, which Sentry designed to be public: it lets an app send reports but read nothing. The auth token that uploads debug symbols stays in your build pipeline's secrets and never ships in an app.
A full test run
A separate test environment receives deliberate crashes and errors from every app and the server first. We check that stack traces are readable, release health counts sessions and no personal data gets through, before your first real customer.
