App start
App start in the Monitor area (Performance) — route /monitor/app-start.
App start lives in the Monitor area of the dashboard, under Performance.
At a glance#
| Dashboard route | /monitor/app-start |
| Area | Monitor (monitor) |
| Group | Performance |
| Platforms | Mobile apps only (iOS, Android, React Native, Flutter). Hidden for web apps. |
What it does#
App start measures launch time, broken into the launch types the OS distinguishes — cold, warm and hot — and shows where the time went as a waterfall across the launch phases. Alongside it: a KPI row, percentiles, a trend over the window, and a list of the slowest individual launches you can open directly.
Cold, warm and hot are separate populations, not one metric with variance. Averaging them together produces a number that describes nobody's experience, which is why the page keeps them on separate tabs.
When to use it#
Before and after any change to app startup — a new dependency, an SDK, an eagerly-initialised service, a migration that runs at launch. Launch time is the first thing every user experiences and the easiest thing to regress accidentally, because a 200 ms addition is invisible on a developer's device and obvious on a three-year-old phone.
Workflow#
Work on cold start first
Cold start is the slowest and the one users notice. Warm and hot mostly track it.
Read the waterfall, not the total
The total tells you there is a problem. The phase breakdown tells you whether it is process init, framework bootstrap, or your own first-screen work — three completely different fixes.
Compare p50 against p95
A high p50 is everyone's problem and usually architectural. A normal p50 with a bad p95 is a device or cold-cache problem, and the slowest-launches list is where you find out which.
Verify against the release
Filter to the version you shipped and compare to the one before it. This is the only comparison that answers "did my change help".
Permissions and prerequisites#
Mobile only — iOS, Android, React Native and Flutter. Hidden for web apps, which measure Page load instead. Requires the SDK to be initialised early enough in the launch sequence to observe it.
Limits and edge cases#
Initialise the SDK early or under-report. Anything that happens before the SDK starts cannot be attributed. Late initialisation does not produce a wrong number — it produces a flattering one.
Debug builds are not comparable. Unoptimised binaries and development bundling make launch numbers meaningless. Measure release builds.
The OS may pre-warm your process. A "cold" launch on a device that prewarmed you is faster than a genuine one, which is one source of low-end p50 noise.
Troubleshooting#
Numbers look impossibly good. Check where the SDK initialises. If it starts after your first screen renders, you are measuring the tail of launch, not launch.
No hot launches recorded. Expected on some platforms and usage patterns — hot launch requires the process to still be resident. Nothing is broken.
Where the data comes from#
Fed by the Tier-1 app-launch collector, which is enabled by default.
From the SDK
Served by
Analytics