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 uses Sentry by default. Sentry's free tier is generous; most small apps never need to pay.

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 does:

1. Adds Sentry's library to the app.
2. Starts it up at the very beginning, so even errors during launch are caught.
3. Tags every event with the user's ID once they sign in.
4. Adds release tracking so you know which version of the app produced which error.

What you do on Sentry's side

1. Create a free account at sentry.io.
2. Create a new project; choose React Native.
3. Sentry gives you a long string called a DSN (it's a URL, despite the name). Paste it into Dashboard → Connectors → Sentry. The DSN is public-by-design, so it's safe inside your app - and connecting once covers every project in your account.

Errors now flow into Sentry. Open the dashboard and you'll see them as they happen.

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)).

The agent enables a feature called source maps that lets Sentry decode the compacted code back to your readable source. You don't have to do anything; it's automatic on every build.

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

The agent tags each error with the user's 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 don't crowd your dashboard. The agent adds a starter filter you can extend.

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.

"Turn on Sentry performance monitoring. Sample 10% of activity (so we don't blow through the free tier). Auto-track navigation and network requests."

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.

The agent adds default redaction so authorization headers and obvious sensitive fields get stripped. If you're sending anything sensitive in your own API calls, mention it explicitly and the agent will add a filter.

Cost

Free tier: thousands of errors per month, enough for most small apps. Paid plans scale from there.

If you're burning the quota fast, the usual fixes:

• Sentry auto-deduplicates similar errors, so it's not that.
• Look for noise to filter (a flood of one specific error).
• Lower the performance-monitoring sample rate.

Under the hood (for engineers)

• @sentry/react-native initialised at app root before any other code runs.
• DSN from your Sentry connector (a public-by-design value, embedded at build time); release tag from Constants.expoConfig.version.
• Source maps uploaded on each EAS build via sentry-expo.
• Sentry.setUser({ id }) on sign-in.
• A beforeSend hook for filtering and a beforeSendTransaction hook for performance event filtering.

Next

Read Connectors Overview for a tour of every service the agent supports.