Error Monitoring
Here's the uncomfortable truth: most users who hit a bug in your app don't report it. They sigh, close the app, and possibly uninstall it. You never hear about the problem until your reviews start dipping.
Error monitoring is the fix. It catches bugs the moment they happen. On a real user's phone, in the real world. And tells you. You get to fix the bug before the rest of your users hit it.
Appsanic supports Sentry as the managed monitoring connector. Review Sentry's current event, retention, and performance limits for your plan.
What it actually catches
Once you wire up Sentry, you'll start seeing:
- Crashes: the app force-quitting.
- Errors that didn't crash the app but did something visibly wrong (a blank screen, a missing button, a stuck loading spinner).
- Network errors: when the server returns an error instead of data.
- The user actions just before the crash: last screen they were on, last button they tapped. So you know what they were trying to do.
You watch all of this in the Sentry dashboard. Each event includes which user, which device, which version of the app, and the trail of breadcrumbs leading up to the failure.
The setup prompt
"Add Sentry error monitoring. Catch crashes and errors. Tag each event with the current user's ID and the app version so I can see which users are affected."
What the agent can do before export:
- Adds a small JavaScript reporter and an error boundary for preview-visible failures.
- Generates a
SETUP REQUIREDchecklist for the native SDK, release naming, privacy filters, and source maps. - Leaves user tagging and performance tracing for reviewed native setup after export.
What you do on Sentry's side
- Create a free account at sentry.io.
- Create a new project; choose React Native.
- Sentry gives you a long string called a DSN (it's a URL, despite the name). Open the Appsanic project build, select Connectors → Sentry, and enter it. The DSN is public by design, and the connection applies only to that project.
The bounded connection check validates configuration only. Preview reports begin only when the generated reporter executes; full device crashes do not flow until you install and configure the native SDK in an exported development build.
Mapping a crash back to your code
When the app gets built for the App Store, the code gets compacted. Variable names shrink to one letter, whitespace disappears. A crash from a compacted bundle is unreadable: stuff like a(b.c[d](e)).
For readable production stack traces, enable source maps in the exported app's Sentry/EAS setup. The connector does not upload them automatically; follow the generated setup instructions or run Sentry's React Native wizard during native-build configuration.
When a real user crashes in production, you'll see the stack trace in your original code. With file paths and line numbers. Not the gibberish.
Knowing which users are affected
After you configure native Sentry, you can tag events with an opaque user ID. In the Sentry dashboard, you can:
- See how many unique users hit a given bug.
- See which users had a rough time today.
- Reach out to a specific user if it matters (or apologise quietly).
Privacy note. Don't send real email addresses if you don't have to. A user ID is enough to tell repeat patterns apart without sending personal data. The agent uses IDs by default.
"Release health". The most useful single dashboard
Sentry tracks two metrics per release of your app:
- Crash-free sessions: what percentage of app opens didn't crash.
- Crash-free users: what percentage of users got through their day without a crash.
Watch these per version. A new release with a sudden drop is a sign you released something broken. Roll it back fast. See Over-the-Air Updates.
When you want a heads-up about something specific
You can configure Sentry to ping you when something happens. Slack, email, PagerDuty:
- Any new error in production → ping the team.
- Error rate above X% in 5 minutes → page somebody.
- A specific error (e.g., payment failure) → alert the billing person.
Set this up in Sentry's dashboard under Alerts → Create Alert.
Filtering out the noise
Not every error is real. Common noise:
- Network errors during expected offline use.
- The user cancelling a Google sign-in popup.
- A third-party library throwing something benign.
You can filter these out so they do not crowd your dashboard. Ask the agent to generate a candidate filter, then review it so real failures are not silently discarded.
Performance monitoring (optional)
Sentry can also tell you what's slow. Which screens take ages to load, which network calls are slow, which animations stutter.
"After export, configure Sentry performance monitoring at a reviewed sample rate. Exclude sensitive payloads and test navigation/network instrumentation in a development build."
Don't send sensitive data to Sentry
By default, Sentry can capture network request bodies when there's an error. If those bodies contain user passwords or payment info, that data ends up in Sentry.
Do not assume automatic redaction is complete. Configure beforeSend/scrubbing rules, exclude authorization headers and sensitive bodies, and inspect test events before production.
Cost
Check Sentry's current pricing and quotas. If usage is unexpectedly high:
- Look for noise to filter (a flood of one specific error).
- Lower the performance-monitoring sample rate.
Under the hood (for engineers)
- Preview: a minimal DSN-based JavaScript reporter and error boundary, not the native SDK.
- Exported native build: install and initialise
@sentry/react-native, set deliberate release identifiers, and test device crash capture. - Source-map upload configured manually for exported EAS builds using Sentry's supported Expo/React Native tooling.
- Add
Sentry.setUser({ id }),beforeSend, and performance filters only after privacy review.
Next
Read Connectors Overview for a tour of every service the agent supports.