Digital Quality

The crash your rating is about to be about.

Crash issues for iOS and Android with impact, affected sessions and the screen they happened on. A crash on a screen nobody visits and a crash in checkout are not the same problem, and a raw count will not tell them apart.

app.cxorbi.com/errors
Last 7 days ⌄

Error Analysis

Prioritize technical errors, UX friction, and product-flow issues by session impact.

WebiOSAndroid
Error Rate
12.4%
312 / 2514 sessions
Flow Issues
3.1%
handled form/upload/OTP
Technical Errors
8.7%
console + network + JS
Regressed
4
issues
Escalating
7
issues
Active (128)Regressed (4)Escalating (7)Resolved (32)Ignored (9)
ErrorTypeEventsSessionsUsersLast Seen
Order submit failedRegressed
checkoutcriticalstep: payment
/trade/place-order · Chrome 121
Network12,4803,1021,2042h ago
KYC document timeoutEscalating
onboardingmajorstep: kyc
/account/kyc-upload · Safari 17
Flow Issue6,2401,8807425h ago
Watchlist sync error
portfoliominor
/portfolio/watchlist · Chrome 120
Console3,4109804121d ago

Showing 3 of 128 issues

Impact before volume

Ranked by the sessions each crash spoils, so a rare crash in a high-value flow can outrank a common one nobody notices.

Both platforms, one list

iOS and Android in the same view, so a cross-platform regression is one issue rather than two teams comparing notes.

Tied to a release

Crash rate per build, so a bad ship is visible before the review scores catch up with it.

What Mobile Crash Reporting does

Rank what matters

The prioritisation view a mobile team can actually work from on a Monday morning.

  • Crash issues ranked by sessions affected
  • iOS and Android side by side
  • Trend per issue so a regression separates from a long-standing fault

Know where it happened

The context that turns a crash into a reproduction.

  • The screen the crash occurred on
  • Release and device class
  • Frequency over time, so intermittent faults are recognisable

See it happen

The last thing the user did before the app disappeared is usually the whole answer.

  • Open the replay of a session that crashed
  • See the crash flagged on the session timeline
  • Check what the user did next — recovered, retried or never came back

Better with the rest of it

Every module reads the same identity, events and sessions, so an investigation that starts here does not have to be rebuilt to continue somewhere else.

Frequently asked questions

Does this replace a dedicated crash reporter?

It answers a different question. A crash reporter is built around the symbolicated stack trace; this is built around deciding which crash to fix first and seeing what the user was doing when it happened.

Which platforms are covered?

iOS and Android, through the same SDK that provides session replay and surveys. There is nothing extra to install if the SDK is already in the app.

Can I tell whether a crash cost me users?

The affected sessions resolve to real people, so you can look at what those users did afterwards — including whether they came back at all.

Ready to start?

Bring the whole user story into one workflow

Free plan availableNo credit card requiredWeb, iOS & Android