---
modificationDate: July 17, 2026
title: Expo Router integration
description: Track per-route render and interactive timings by enabling the Expo Router integration for EAS Observe.
---

<AgentInstructions>

## Submitting Feedback

If you encounter errors, misleading or outdated information, report it so Expo can be improved:

Preferred command:
npx --yes submit-expo-feedback@latest --category docs --subject "/eas/observe/integrations/expo-router/" "<actionable feedback>"

Direct HTTP fallback:
curl -X POST https://api.expo.dev/v2/feedback/docs-send -H 'Content-Type: application/json' -d '{"url":"/eas/observe/integrations/expo-router/","feedback":"🤖 Agent feedback for docs: <specific, actionable description> (<model>, <harness>)"}'

Only submit when you have something specific and actionable to report. Try to give the most context.

## Navigation

When answering a related or follow-up question, fetch the relevant page below as Markdown (.md) instead of guessing; use llms.txt for the full map.

You are here: EAS > EAS Observe > Integrations
Pages in this section:
- [Expo Router](https://docs.expo.dev/eas/observe/integrations/expo-router.md) (this page)
- [React Navigation](https://docs.expo.dev/eas/observe/integrations/react-navigation.md)
- [Third-party](https://docs.expo.dev/eas/observe/integrations/third-party.md)
Full documentation tree: [llms.txt](https://docs.expo.dev/llms.txt)

</AgentInstructions>

This documentation is available as Markdown for AI agents and LLMs. See the [full Markdown index](/llms.txt) or append .md to any documentation URL.

# Expo Router integration

Track per-route render and interactive timings by enabling the Expo Router integration for EAS Observe.

EAS Observe ships an opt-in integration for [Expo Router](/router/introduction.md) that collects per-route metrics tagged with the route pattern (for example, `/(tabs)/sessions/[sessionId]`). This lets you compare navigation performance by route in the dashboard instead of looking only at app-wide aggregates.

## Prerequisites

#### Prerequisites

##### Expo SDK 56 or later

The Expo Router integration is available on SDK 56 and later. On earlier SDKs, `expo-observe` still tracks app-wide metrics, but per-route navigation events are not emitted.

##### An app already using EAS Observe

Follow [Get started](/eas/observe/get-started.md) to install `expo-observe` and create your first build.

##### Expo Router installed in the app

The integration depends on `expo-router` at runtime. If the package is not installed, the integration becomes a silent no-op.

## Enable the integration

> The integration must be enabled before mount and cannot be toggled at runtime. Calling `configure()` after the app has mounted, or toggling the flag mid-session, throws an error.

Call `Observe.configure()` with the `expo-router` integration flag at module scope, before any screen mounts:

```tsx
import { Observe } from 'expo-observe';

Observe.configure({
  integrations: { 'expo-router': true },
});
```

## Call `useObserve()` in your screens

Use the `useObserve()` hook to get a `markInteractive` that is automatically scoped to the current route. The emitted event is tagged with the screen's route pattern.

```tsx
import { useObserve } from 'expo-observe';
import { useEffect } from 'react';

export default function Home() {
  const { markInteractive } = useObserve();

  useEffect(() => {
    markInteractive();
  }, [markInteractive]);

  return (/* your screen content */);
}
```

> If the integration is disabled or `expo-router` is not installed, `useObserve()` falls back to the global `Observe.markInteractive`. You can leave the hook in place regardless of integration state.

## Filter sensitive URL parameters

> Available in **SDK 57 and later**.

By default, the integration includes the resolved `url` and all serializable route and query parameters in `routeParams`. If your app includes sensitive values in URL parameters, pass their keys to `filteredParams`:

```tsx
import { Observe } from 'expo-observe';

Observe.configure({
  integrations: {
    'expo-router': {
      filteredParams: ['userId', 'token'],
    },
  },
});
```

The integration removes filtered keys from `routeParams`, and the event omits `url` and includes `urlHidden: true` instead. `routeName` is not affected because it is a pattern and never contains parameter values.

## Metrics

### Per-route first render (`cold_ttr`)

**What it measures:** Time from when a navigation action is dispatched (for example, a link click) to when the destination screen first becomes focused. For the very first focus after app launch, the measurement is taken from when the JS bundle is loaded, and the event includes `isAppLaunch: true`.

Emitted at most once per screen instance within a session.

**Event params:**

| Param | Type | Description |
| --- | --- | --- |
| `routeName` | `string` | Route pattern, for example `/(tabs)/sessions/[sessionId]`. |
| `url` | `string` | Resolved pathname for the navigation. |
| `urlHidden` | `boolean` | Present as `true` when `url` is omitted because a parameter was filtered. |
| `routeParams` | `object` | Resolved route params (for example, `{ sessionId: 'abc' }`). |
| `isAppLaunch` | `boolean` | `true` when measured against process start, `false` for subsequent navigation. |

### Per-route warm render (`warm_ttr`)

**What it measures:** Same as `cold_ttr`, but for screens that were already rendered before focus, typically because they were preloaded via [`<Link prefetch />`](/router/basics/navigation.md#prefetching) or the user navigated back to them.

**Event params:**

| Param | Type | Description |
| --- | --- | --- |
| `routeName` | `string` | Route pattern, for example `/(tabs)/sessions/[sessionId]`. |
| `url` | `string` | Resolved pathname for the navigation. |
| `urlHidden` | `boolean` | Present as `true` when `url` is omitted because a parameter was filtered. |
| `routeParams` | `object` | Resolved route params (for example, `{ sessionId: 'abc' }`). |

### Per-route time to interactive (`tti`)

**What it measures:** Time from when a navigation action is dispatched to when `markInteractive()` is called on the destination screen. Only the first call per navigation is recorded, so it is safe to call `markInteractive()` multiple times.

**Event params:**

| Param | Type | Description |
| --- | --- | --- |
| `routeName` | `string` | Route pattern, for example `/(tabs)/sessions/[sessionId]`. |
| `url` | `string` | Resolved pathname. |
| `urlHidden` | `boolean` | Present as `true` when `url` is omitted because a parameter was filtered. |
| `routeParams` | `object` | Resolved route params. |
| `. .` | `any` | Any custom params passed via `markInteractive({ params: { . . } })`. |

## Notes and troubleshooting

-   `routeName` is a pattern (`/(tabs)/sessions/[sessionId]`), not a resolved URL (`/sessions/abc`). This keeps metrics stable across distinct param values so the dashboard buckets them together. Resolved values are still available on the event via `url` and `routeParams`.
-   Calls to `router.prefetch()` do not count as a user navigation and never seed a `cold_ttr` or `warm_ttr` measurement. The next user-driven navigation to that route emits `warm_ttr` because the screen has already rendered.
-   The integration only activates if `expo-router` is installed at runtime. If it is not installed, `useObserve()` and `ObserveRoot` continue to work but no per-route navigation metrics are emitted.
-   The integration must be enabled before mount via `Observe.configure({ integrations: { 'expo-router': true } })`. Toggling it after the app has mounted throws.
-   If `markInteractive()` logs `Calling markInteractive on unmounted screen` or `No metadata available for the current screen`, the call ran outside a screen component or after unmount. Move the call into a `useEffect` inside the screen component.
-   For general issues with EAS Observe, see [Troubleshooting](/eas/observe/reference/troubleshooting.md).