SaaS Metrics
Product Hunt
EAS Observe
Performance monitoring built for Expo and React Native
Observe measures how fast your Expo app starts and how fast each screen becomes usable, on real user devices. Install the library, wrap your root layout, and startup metrics arrive with nothing to instrument. Every native build and every EAS Update gets its own marker on the chart, so you can see which release moved the line. Full device context on every session: model, OS, country, network type, thermal state, frame data. Free plan covers 100K events a month.
View Raw Thread
Developer & User Discourse
[Redacted] • Aug 31, 2026
Hey Product Hunt! Observe is performance monitoring for Expo and React Native apps. It went generally available last week after a few months of open beta.
Mobile releases don't behave like web releases. Users update when they feel like it, and over-the-air JavaScript updates stack on top of native builds, so three native releases plus two updates leaves you with five different apps live at once. A tool that models a release as a single version string will average all five into one p90 and call it a day.
Observe treats every native build and every EAS Update as its own release. It measures how fast your app starts and how fast each screen becomes usable on real user devices, then drops a marker on the chart when each release's first event arrives. Click the marker and you get the version, the build number or update ID, and the metric value at that point.
What you get after `npx expo install expo-observe` and one wrapper around your root layout:
- Launch time split into cold and warm, bundle load, and time to render. Nothing to instrument.
- Time to interactive, once you call `markInteractive()`. That one needs a line from you, because only your code knows when the first screen actually has data in it.
- Per-route cold and warm time to first render on SDK 56 and later, through the Expo Router or React Navigation integration. First visits and repeat visits are tracked separately, since they're usually different problems.
- Release markers for every build and update, filters down to a single version, build, or update ID, and a downloads tab with median and p90 per update.
- Device context on every session: model, OS version, country, language, app version and build, route. Plus the fields a browser tab doesn't have, like frozen and slow frames, thermal state, low power mode, and network type.
- Custom events through `Observe.logEvent()`, landing on the same session timeline as the startup metrics.
- JavaScript error reporting, in preview on SDK 57 and later. Set `uploadSourceMaps: true` in eas.json and production stack traces come back readable.
- A "hand off to your AI assistant" button that copies the dashboard state as a prompt for Claude Code, Cursor, or Codex.
The library is open source and emits OpenTelemetry. EAS Observe is the default collector and you can point it at your own instead. You give up release attribution if you do, since joining a metric to a build and a commit needs the build pipeline.
There are some gaps/limitations in this early version of the service: no alerting yet (email, Slack and webhooks are in progress), no session replay, no backend tracing, no native crash reporting. If you already run Sentry, keep it. They work side by side. You need SDK 55 or later, an EAS project, and a development or production build. It doesn't run in Expo Go, and turning it on takes a new binary.
Free plan is 100K events a month. Starter is $19 and Production is $199, both including 500K events with usage pricing beyond that. Metric data is retained at least 90 days.
Happy to answer anything in the comments. Bug reports go to the #eas channel in the Expo Discord.
Mobile releases don't behave like web releases. Users update when they feel like it, and over-the-air JavaScript updates stack on top of native builds, so three native releases plus two updates leaves you with five different apps live at once. A tool that models a release as a single version string will average all five into one p90 and call it a day.
Observe treats every native build and every EAS Update as its own release. It measures how fast your app starts and how fast each screen becomes usable on real user devices, then drops a marker on the chart when each release's first event arrives. Click the marker and you get the version, the build number or update ID, and the metric value at that point.
What you get after `npx expo install expo-observe` and one wrapper around your root layout:
- Launch time split into cold and warm, bundle load, and time to render. Nothing to instrument.
- Time to interactive, once you call `markInteractive()`. That one needs a line from you, because only your code knows when the first screen actually has data in it.
- Per-route cold and warm time to first render on SDK 56 and later, through the Expo Router or React Navigation integration. First visits and repeat visits are tracked separately, since they're usually different problems.
- Release markers for every build and update, filters down to a single version, build, or update ID, and a downloads tab with median and p90 per update.
- Device context on every session: model, OS version, country, language, app version and build, route. Plus the fields a browser tab doesn't have, like frozen and slow frames, thermal state, low power mode, and network type.
- Custom events through `Observe.logEvent()`, landing on the same session timeline as the startup metrics.
- JavaScript error reporting, in preview on SDK 57 and later. Set `uploadSourceMaps: true` in eas.json and production stack traces come back readable.
- A "hand off to your AI assistant" button that copies the dashboard state as a prompt for Claude Code, Cursor, or Codex.
The library is open source and emits OpenTelemetry. EAS Observe is the default collector and you can point it at your own instead. You give up release attribution if you do, since joining a metric to a build and a commit needs the build pipeline.
There are some gaps/limitations in this early version of the service: no alerting yet (email, Slack and webhooks are in progress), no session replay, no backend tracing, no native crash reporting. If you already run Sentry, keep it. They work side by side. You need SDK 55 or later, an EAS project, and a development or production build. It doesn't run in Expo Go, and turning it on takes a new binary.
Free plan is 100K events a month. Starter is $19 and Production is $199, both including 500K events with usage pricing beyond that. Metric data is retained at least 90 days.
Happy to answer anything in the comments. Bug reports go to the #eas channel in the Expo Discord.
Does free plan cover single user per session? Or is it different?