Reading your dashboard
Five views, one question each. Overview tells you whether anything moved; Builds tells you which release moved it; the rest tell you where.
Filters
Two filters apply across the views: a time range and a platform selector (iOS, Android, or both). Both are part of the URL, so a filtered view is shareable with a teammate.
Time range
| Range | Available on |
|---|---|
| 24h | Every plan |
| 7d (default) | Every plan |
| 30d | Every plan |
| 90d | Indie and Studio |
| 180d | Studio |
Presets beyond your plan's retention stay visible but are locked, and link to pricing rather than silently disappearing — so it is clear the window exists and your plan does not reach it. See API keys & plans for retention by plan.
Automatic widening
If you land on a page without an explicit range in the URL and the default 7-day window is empty, the dashboard widens to the narrowest preset that actually contains data — capped by your retention — and tells you it did:
Note
No data in the last 7d — showing the last 30d instead. [Use 7d] [✕]
The widened range is deliberately not written into the URL, so a bookmarked page keeps re-evaluating as your data changes instead of pinning 90d forever. Picking a range yourself always wins — an explicit ?range= is never overridden.
The freshness indicator
The sidebar carries an ambient chip showing when the app last sent anything, on every page including Builds:
| Indicator | Meaning |
|---|---|
| ● Live · 2 min ago | An event arrived within the last 15 minutes |
| ○ Last event 3 days ago | Reporting, but nothing recent |
| ○ Last event 2 months ago | Nothing for over a week — amber, because the page you are reading is a historical snapshot |
| ○ No events yet | This app has never received an event |
Empty states explain a page with nothing on it; this explains a page that does have content. Without it, a month-old snapshot looks identical to live data.
Overview
Four headline numbers, each compared against the immediately preceding window of the same length — so on a 7d range, this week versus last week:
- Cold start p50
- Crash-free rate
- Slow frame rate
- Average screen load p50
Below them: a daily cold-start trend line (median per day) and your five slowest screens with p50, p75, p95 and sample count.
Note
Deltas here are time-based, not build-based. A regression that shipped mid-window will look diluted because the window contains both the old and new builds. Use Builds to isolate it.
Builds
The view perfbit is built around. Pick two appVersion values and compare them directly — no time window blending, because each event already carries the version it came from.
Seven metrics are compared, each with an absolute and percentage delta:
| Metric | What a regression looks like |
|---|---|
| Cold start p50 | Typical launch got slower |
| Cold start p95 | The worst launches got worse — often the more actionable of the two |
| Warm start p50 | Resuming from background got slower |
| Crash-free rate | A new crash path shipped |
| Slow frame rate | More frames missing the 60fps budget |
| Frozen frame rate | New long blocks on the JS thread |
| Average network latency | Backend or request pattern changed |
Underneath, a per-screen breakdown compares p50 for every screen present in both builds, sorted by the size of the change — so the screen that moved most is first, whether it got better or worse.
Heads up
This view only works if appVersion actually changes between releases. If every build reports the same string there is nothing to compare. See Quickstart.
Screens
Every screen name the SDK has seen, with p50, p75, p95 and a sample count. Drill into one for a daily trend and a latency histogram bucketed at 0–200ms, 200–500ms, 500ms–1s, 1s–2s and 2s+.
The histogram is the useful part when p50 looks fine but users complain — a healthy median with a fat 2s+ bucket means a subset of loads is badly slow, which an average would hide.
Empty for apps that have not passed navigationRef to init() — see Screen tracking.
Network
Endpoints grouped by HTTP method and URL, showing p50, p95, error rate (status ≥ 400) and request count, sorted by p95 descending — slowest first.
Remember that URLs keep their path parameters, so /users/123 and /users/456 appear as separate rows. Endpoints with IDs in the path will spread across many low-count rows rather than aggregating.
Sessions
Crash-free rate with a period-over-period delta, total and crashed session counts, a daily crash-free trend, and a list of the 100 most recent sessions — id, app version, platform, start time, duration and whether it crashed. A filter narrows the list to crashed sessions only.
Note
This is a rate view, not a crash debugger. Error messages and stack traces are captured and stored, but the dashboard does not render them, and native crashes are not detected at all. See Metrics.
Why a view is empty
An empty page always names its own cause rather than defaulting to install instructions. There are four distinct reasons, and only the first one shows the SDK snippet:
| What you see | What it means | What to do |
|---|---|---|
| Waiting for first event… | No event has ever arrived for this app. | Follow the Quickstart. The page polls, so it flips on its own once data lands. |
| Events are arriving, but not from production | Events are being received, but every one is tagged as a non-production environment. | Send environment: 'production', or drop the option — production is the default. |
| No data in the last 7d | Real data exists, but it predates the selected window. The message names how stale the newest event is. | Widen the time range. |
| No data in this view | Data exists inside the window, but the active filters exclude it — or this page's particular metric was never collected. | Clear the filters using the action on the card. |
Note
Dormancy outranks filters. If the newest event predates the window, you are told to widen the range rather than to clear filters — because clearing them could not have filled the page.
The Screens page adds a page-specific hint, since an app can be reporting perfectly while still sending no screen events — that means a missing navigationRef, covered in Screen tracking.
Missing values
An em dash (—) means no samples, not zero. This distinction matters: an app with no sessions at all shows — for crash-free rate, not a reassuring 100%. A real measured zero still renders as 0%.
In the Builds view, a comparison that cannot be measured — the metric is absent from one of the two builds — draws a dashed track rather than an empty bar, so "we could not measure this" never reads as "no change".