Direct answer
Instrument the client itself (the mobile app), not just the servers, because server metrics only see requests that actually reach the server: a client stuck in a retry loop, on a degraded network, or crashing before it can even send a request is invisible server-side. Collect a small set of client signals, aggregate and anonymize them centrally, and feed the aggregate (never a single user's raw trace) into the same automated-response path your server-side detection already uses.
Structured elaboration
Signals to collect on the client. Three categories cover most real client-side degradation: (1) latency histograms per API call, bucketed client-side so you get percentile shape, not just an average that a few slow devices can hide; (2) error events, both network-layer (timeout, connection reset, DNS failure) and application-layer (a 5xx, a malformed response the app failed to parse); (3) UI-hang telemetry, specifically the main-thread-blocked duration, since a slow backend and a slow render both feel like "the app froze" to a user even though only one of them is your server's fault.
Aggregation and anonymization. Never ship raw per-request client traces to a central collector at full fidelity; that is both a privacy problem (device identifiers, precise timestamps, and location can re-identify a user) and a cost problem (mobile telemetry at scale is enormous). Aggregate on-device first: roll each signal into a small periodic summary (e.g., a histogram of the last N latencies, a count of each error type) keyed by coarse dimensions (app version, OS version, region, not device ID), and only ship the summary. Strip or hash anything that could identify an individual user before it leaves the device, and apply k-anonymity style suppression server-side (do not surface a metric bucket with too few contributing devices, since a bucket of size 1 is effectively a single user's data).
Triggering automated responses. The value of client signals is that they can detect a problem servers cannot see at all (a broken CDN edge node serving one region, a client library bug shipped in the latest release) or detect it faster (client error rate spiking before server-side alerting has enough samples). Feed the aggregated client signal into the same decision layer as server signals, with two safeguards: (a) require the signal to be corroborated by a minimum number of distinct devices/regions before it can trigger anything, so one user's flaky home wifi never fires a global rollback; (b) prefer client-triggerable actions that are inherently safe to invoke speculatively, such as a feature-flag rollback (turns off a recently shipped client feature) or server-side throttling of a specific endpoint, over anything destructive, since client signals are noisier than server signals and a false trigger should be cheap to undo.
Worked example
Suppose the last app release shipped a client bug that causes a new checkout screen to hang the main thread for 2+ seconds on older Android devices. Server-side, nothing looks wrong: requests that do get sent complete normally, so server p99 latency and error rate stay flat. Client telemetry aggregated by app version shows: version 4.2.0, Android, UI-hang-duration p95 jumps from 180ms (baseline, previous version) to 2400ms, corroborated across 340 distinct devices in the first 10 minutes post-release across 6 regions. That crosses the minimum-corroboration bar (multiple regions, hundreds of devices, not a handful), so it triggers a feature-flag rollback of the new checkout screen for version 4.2.0 specifically, while a server-only detection system would not have flagged anything at all.
Trade-offs and pitfalls
The central trade-off is signal richness versus privacy and bandwidth: every additional client signal you collect is both a detection improvement and a privacy/cost liability, so default to aggregates and only add a new raw-event type when you have a concrete detection gap it closes. A common pitfall is treating client-reported errors with the same trust as server-reported ones; client environments are wildly heterogeneous (old devices, bad networks, ad blockers, corporate proxies), so a spike that looks alarming in raw client error counts is often just noise from one device class, which is why the region/device-count corroboration threshold above is not optional scaffolding, it is the mechanism that keeps this system from paging on individual users' bad wifi.
