/eas-observe

EAS Observe metrics — interpretation cheatsheet

Quick reference for reading EAS Observe dashboards and CLI output.

Source: https://docs.expo.dev/eas/observe/reference/metrics/ — this is the canonical reference for metrics. Consult this page for the latest guidance, full prose definitions, optimization tips, and rationale.

All durations are in seconds. Metric data is retained for a minimum of 60 days. By default, every installation dispatches all of its events; high-volume apps can sample per installation with configure({ sampleRate }) — see Sampling.

Target thresholds

Both TTR and TTI are measured from native launch through the React render, so the cold-launch portion counts against them.

Interpreting TTI events (automatic params)

Every TTI event carries automatic params in three groups: frame rate, device state, and network state. Read the frame-rate group to classify what kind of slowness you're seeing, then read the device and network groups to decide whether the cause is the code or the conditions.

Frame rate — what kind of slowness

Diagnostic patterns:

• High TTI + low totalDelay → slow but smooth. The launch sequence itself is long. Optimize bundle size, data-fetch waterfalls, initialization chains.
• High TTI + high totalDelay + many slowFrames → main-thread contention. Offload work, simplify the initial render tree.
• High TTI + high totalDelay + any frozenFrames → something is blocking hard. Look for synchronous I/O, large JSON parsing, or blocking network calls.

Device state — is the regression environmental?

Network state — is startup network-bound?

Network requests — was the network the cause?

TTI events summarize the HTTP requests made during launch, from the end of the native launch to the markInteractive() call. Traffic is observed automatically — URLSession on iOS, OkHttpClient on Android, which covers fetch — and Observe's own uploads are excluded. All of these are omitted when the window held no requests.

Diagnostic patterns:

• slowest.duration mostly timeToFirstByte → the server was slow to answer. Optimize the endpoint, or stop blocking startup on it.
• Small timeToFirstByte + large bytesReceived → the transfer itself was slow. Shrink the payload or defer it.
• High failed + high totalDuration → the launch burned time on requests that never arrived. Add timeouts and render cached content first.
• Low throughputBytesPerSecond on wifi → suspect the population, not the code; cross-check isExpensive and isConstrained / dataSaverEnabled.

The summary is bounded by an in-memory ring buffer of the 200 most recent requests. A launch that makes more undercounts, so read these as a sample of a very busy window.

Custom params

You can attach your own params to the TTI event, and override the route name it is tagged with. See ./setup.md for the call syntax.

Dispatch caveats

• Debug builds (native debug OR JS bundle with __DEV__ = true) do not dispatch metrics unless configure({ dispatchInDebug: true }) is set.
• The environment tag (defaults to process.env.NODE_ENV) is metadata only — it does not gate dispatch by itself.
• Offline events are buffered on-device and flushed when the app backgrounds or Observe.dispatchEvents() is called.

Cross-references

• Full metric definitions and optimization guidance: https://docs.expo.dev/eas/observe/reference/metrics/
• Setup steps (AppMetricsRoot / ObserveRoot, markInteractive): see ./setup.md.
• Querying metrics via the EAS CLI: see ./queries.md.