What is mobile observability? How it differs from crash reporting

Quick answer

Mobile observability is the ability to explain how your app behaves in production from the signals it sends: crash and error reports, timing metrics, events, traces and release data. Crash reporting is one part of it. Observability also covers slow screens, stalled requests and abandoned journeys, so you can investigate a problem when the app never crashed at all.

Your product manager posts in #releases at 9:40 on Wednesday: "Checkout completions are down since yesterday's release. Is the app broken?" Your crash-free sessions chart has not moved. The app could be waiting on a request that never returns, or taking long enough that people give up, and your crash reporter cannot tell you which because nothing crashed.

How is mobile observability different from crash reporting?

Crash reporting answers "what failed, and where?" A crash reporter catches errors, groups them by cause, maps stack traces back to source and calculates crash-free users and sessions. Firebase notes that its crash-free metrics count only fatal events.

Observability answers "why is this happening, and to whom?" It adds timings, events and traces, then ties each one to the release, device and route where it happened. The OpenTelemetry observability primer describes it as understanding a system from the signals it emits.

Mobile apps make that harder than backend services. Your code runs on phones that go offline, get killed by the OS and stay on old versions long after you ship a new one, and a JavaScript update can change what users run without a new store version.

Observability does not require a bigger product. A few well-defined signals on the journeys that matter answer more than a pile of disconnected events.

What signals should a mobile app send?

Each signal answers a different question, and each becomes more useful when it shares an operation or release ID with the others.

A metric finds a regression and a trace explains one instance of it. An error report shows that a request failed, and a route event shows whether the user recovered.

Keep each signal's definition next to its dashboard. A "checkout complete" event that fires before the server confirms the order does not count completed purchases. Instrumentation is code, and code has bugs.

Which tools do mobile teams use for observability?

Expect to combine a crash reporter, a performance tool and the free platform consoles. Listed alphabetically:

Sentry and Firebase Crashlytics are the strongest choices for crash reporting. Datadog RUM fits teams that want mobile and backend traces in one place. BugSnag has its own Expo setup guide, and Embrace builds its React Native SDK on OpenTelemetry. Android vitals and Xcode Organizer cost nothing and show each platform's own view of crashes and launch time.

How do you connect a user journey to a release?

Pick one journey that matters and define where it starts, what success looks like and when it counts as failed or timed out. Without the failure condition, unsuccessful attempts vanish from your results.

For an upload flow, record when the user submits, what the server returned and whether the app showed the saved record. Join those events with a correlation ID that carries no personal data.

Record the native build and the JavaScript update ID with every event. Several app versions run in production at once, and an over-the-air update can change behavior without changing the store version.

Group results by device class and network type, but stop splitting before every chart rests on a handful of sessions. A typical investigation looks like this:

Add only the instrumentation that makes your hypothesis testable. Logging full request bodies by default creates a data-handling problem and rarely helps the diagnosis.

Why is mobile telemetry incomplete?

A phone can be offline when an event happens, and the OS can kill the app before the event is stored or sent. Plan for late and missing data.

Collection settings change the numbers too. Firebase's crash-free metrics documentation warns that opt-in collection makes the metrics less reliable, and that crash reports sent without session data push crash-free charts to low or zero values. A platform console and an in-app SDK may also count sessions differently.

Show the number of sessions behind every comparison. A precise-looking percentile from a tiny group is still a weak basis for a release decision.

Make sure failed operations emit something. If only successful requests send a completion event, your latency chart can improve during an outage, because the slowest attempts never finish.

Measure the instrumentation itself in a release build; synchronous telemetry on the startup path slows the launch you are measuring. Decide how long you keep diagnostic data and who can read it.

How do you turn observability data into a fix?

Give every meaningful regression an owner and a first diagnostic step. "Latency is high" goes nowhere. "The new release added time to a usable order screen on low-memory Android devices" tells someone where to start.

Treat a correlation as a lead. A release marker next to a change in a graph does not prove the release caused it, so check traffic and backend changes, then reproduce the defect.

Coding agents can query and summarize the data for you. Give them the release identity and a precise question; an agent reading a chart without knowing its sampling or endpoint can produce a confident, wrong explanation.

Make every proposed fix pass a reproduction check. Production signals find the problem; pre-release tests and a staged rollout tell you whether the fix worked.

Where Expo fits

EAS Observe is Expo's production performance monitoring for React Native apps. Its introduction lists startup timings, EAS Update download time and, on SDK 56 and later, per-route timings through Expo Router or React Navigation. You can compare any metric across app versions and OTA updates, drill into a single user's session to see what happened in order, and log your own events with Observe.logEvent.

Keep automatic timings separate from the readiness signal you define. Time to interactive only exists once you call markInteractive(), and the metrics reference explains where each endpoint starts and stops.

Error reporting is in preview on SDK 57. It records JavaScript errors, with symbolicated stack traces when EAS Build uploads source maps, and native crashes on Android and iOS from expo-observe 57.0.21. A Hand off to AI button turns an error into a prompt for Claude Code or Codex.

Pair EAS Observe with a dedicated crash reporter. Expo's product page calls the tools complementary: Observe owns the view of the EAS pipeline, while tools like Sentry and Datadog own error tracking and general APM. Expo's Sentry guide uploads source maps automatically for EAS Build and gives you one command for EAS Update.

Limitations

EAS Observe error reporting is in preview. It does not record ANRs or out-of-memory terminations, and it does not symbolicate native stack traces yet. Errors from an OTA update show unsymbolicated JavaScript traces for now. EAS Observe does not run in Expo Go.

No tool works out the cause for you, and none can explain a business outcome your app measures incorrectly. Start with a written journey definition and check that the events match it.

Next step

Pick one user journey and use the observability primer to define its signals, including a result for attempts that never succeed.

Verified on 12 September 2026.