Why a crash with no report is worse than a bad review
A 1-star review at least tells you something is wrong. A silent crash tells you nothing. The user opens your app, it closes itself, and they delete it without leaving a word. You see it only as a dip in your retention numbers weeks later, if you notice it at all. Crash reporting turns that silent failure into a stack trace you can actually act on.
I add Sentry to every Expo app before the first TestFlight build goes out, not after launch. The setup takes under an hour, and the first version of any app is the version most likely to crash - untested device combinations, edge cases in real data, permissions a simulator never triggers. That is exactly the window where you need the reports most.
Why Sentry, and how it fits an Expo project
Sentry publishes an official React Native SDK, @sentry/react-native, with a built-in Expo config plugin. That means it installs into a managed Expo project the normal way - no ejecting to bare React Native, no manual native project surgery. The config plugin handles the native-side wiring for you the next time you run a prebuild or an EAS Build.
Setting it up in a managed Expo project
- Create a free Sentry account and a new React Native project inside it - this gives you a DSN (the URL your app sends crash data to).
- Run the Sentry install wizard from your project root: npx @sentry/wizard@latest -i reactNative -p expo. It installs the @sentry/react-native package and adds the config plugin to your app.json automatically.
- Confirm the plugin entry landed in app.json under "plugins": it should include "@sentry/react-native/expo" with your organization slug and project slug.
- Wrap your root App component with Sentry.wrap(App) as the wizard sets up, so uncaught errors anywhere in the component tree get captured.
- Rebuild with EAS Build (not Expo Go - native crash reporting needs a real build) and confirm a test error shows up in the Sentry dashboard before you ship to testers.
Source maps: the step that makes crash reports readable
A crash report without source maps shows you a stack trace full of minified variable names and bundled line numbers - technically a crash report, practically useless. The Sentry Expo config plugin automatically uploads source maps as part of your EAS Build when it is configured with a valid auth token, so the stack traces you see in the dashboard map back to your actual source files and line numbers.
Set the SENTRY_AUTH_TOKEN as an EAS secret (eas secret:create) rather than committing it to your repo. Without it, builds still ship fine and crashes still get captured, but every stack trace stays minified and you lose most of the value of having crash reporting at all.
What to do once reports start coming in
| Signal | What it usually means |
|---|---|
| One crash type spikes right after a release | The last build introduced a regression - check what changed in that version first. |
| A crash affects a small percentage of devices only | Often a specific OS version or device model edge case - check the device breakdown before assuming it affects everyone. |
| The same crash keeps recurring across versions | Something structural, not a one-off - worth stopping new feature work to fix before it keeps costing you users. |
| Crash-free session rate below roughly 99% | A reasonable bar to work toward for a shipped app - below that, prioritize stability work over new features. |
Sentry groups crashes by their stack trace automatically, so you are not reading a flat list of thousands of identical events - you are looking at distinct crash types, each with a count and the device/OS breakdown. Sort by count and work the top of the list first.
A mistake worth avoiding
The mistake I see most is installing Sentry, confirming one test error fires, and never opening the dashboard again until a user complains. Crash reporting only pays off if you check it. Build a two-minute weekly habit of scanning the dashboard for new crash types, the same way you would check analytics or reviews - it is one of the highest-signal, lowest-effort habits in the first few months after launch.
Short, practical drops on app ideas, validating fast, store listings, and passing app review. No spam, unsubscribe anytime.
Frequently asked questions
Do I need crash reporting before my first TestFlight build?
Yes, if you want to know why a build fails for a tester instead of just hearing that it did. Your first TestFlight build runs on real devices and real OS versions your simulator never covers, which is exactly when crashes are most likely and reports are most valuable.
Does Sentry work with Expo Go?
No. Expo Go is a shared native binary and cannot embed your project's Sentry native modules. Test crash reporting in a development build (EAS Build) or a TestFlight build instead.
Is the Sentry free tier enough for a new app?
For most new apps in their first months, yes. Sentry's free tier covers a meaningful volume of error events, which comfortably fits a pre-launch or just-launched app's crash volume - you can evaluate a paid tier once you have real scale to justify it.
What are source maps and why do they matter for crash reports?
Source maps translate the minified, bundled JavaScript that actually runs on a device back into your original source file names and line numbers. Without them, a crash report shows an unreadable stack trace. The Sentry Expo config plugin uploads source maps automatically during EAS Build when a valid auth token is configured.
Should I use Sentry or Firebase Crashlytics with Expo?
Both can work with a managed Expo project. Sentry's Expo config plugin has been stable the longest and its dashboard groups and triages crashes clearly, which is why it is the default in this guide - but either tool beats shipping with no crash reporting at all.
How often should I check the crash dashboard after launch?
Weekly, at minimum, in the first months after launch. Crash reporting only pays off if someone actually looks at it - a dashboard nobody checks is no better than not having one.
Last reviewed by David on August 7, 2026
