--- title: "End-to-end observability is not mobile-to-backend observability" metaTitle: "Rethinking end-to-end observability for mobile-to-backend" slug: "end-to-end-observability" blurb: "End-to-end observability looks different when the frontend is a mobile app, not a browser. Here’s why mobile tracing and user experience data need a mobile-native approach." metaDescription: "Datadog defines end-to-end observability from infrastructure to frontend. Here's why that model breaks when the frontend is a mobile app, not a browser." tags: - "mobile" - "observability" - "engineering" cover: url: "/assets/posts/end-to-end-observability/feature-end-to-end-observability-desktop@1x.webp" alt: "End-to-end observability is not mobile-to-backend observability" socialThumbnail: url: "/assets/posts/end-to-end-observability/feature-end-to-end-observability-desktop@1x.webp" alt: "End-to-end observability is not mobile-to-backend observability" author: - "iain" publishedDate: "2026-10-01T12:00:00Z" modifiedDate: "2026-10-01T12:00:00Z" --- *If your SRE team says they've got you covered end-to-end, ask what they're doing about mobile-to-backend. It's not the same problem.* Datadog's recent eBook, *The Benefits of End-to-End Observability*,[^1] opens with a definition we don't disagree with: > "End-to-end observability is the act of monitoring and gaining insights from an application's entire architecture, from its foundational infrastructure to the user-facing frontend, so teams can detect, diagnose, and remediate issues rapidly and effectively." That's a good definition. The problem isn't the definition. The problem is that a browser and a mobile device are not the same kind of user-facing frontend. The eBook occasionally mentions mobile, but it never addresses the complexity a mobile frontend adds to your observability stack. Backend-first tools like Datadog have spent over a decade getting genuinely good at end-to-end observability when the frontend is a browser. Their own definition of what "end-to-end" actually requires breaks into three pillars: metrics, traces, and frontend/user experience data. Going through each one for mobile specifically shows exactly where that model holds and where it doesn't. ## Metrics: no argument here The eBook defines metrics as: > "Key performance indicators from infrastructure host/resource metrics, microservices, containers, databases, and third-party services." Backend tools do this very well. They were built from the ground up to do it and have been doing it for decades. This is the one pillar where legacy tooling doesn't need mobile-specific help, and we're not going to pretend otherwise. ## Traces: the first place mobile breaks the model The eBook goes on to define traces as: > "In-depth diagnostic information that maps the journey of requests through various applications and services." Tracing is difficult to set up well when the frontend is a browser. It gets categorically harder when the frontend is on a mobile device, due to an impedance mismatch unrelated to tooling maturity. A mobile SDK has to decide, on-device, whether to attach trace context to a given request before it knows whether that request will turn out to matter. That's a blind head-sampling decision, and it exists for the same reason head sampling exists everywhere in distributed tracing: **full-fidelity tracing is expensive, especially with chatty mobile apps.** Meanwhile, the backend makes its own independent tail-sampling decisions. The odds of ever finding an “end-to-end” trace in mobile are slim to none. Mobile adds a second problem: timing. A session can sit backgrounded for days before the user reopens the app, and the crash or error that makes you want that trace might not happen, or get reported, until then. Even a trace that survived every sampling decision along the way is racing against a retention window, and full-fidelity trace storage is retained for days at most. By the time anyone looks into what happened in that session, the trace has very likely aged out. bitdrift's answer to this isn't a better sampling rate. [It's workflows](https://blog.bitdrift.io/post/opentelemetry-mobile-tracing): instead of deciding blind at the point of the request, you define the conditions you actually care about (feature flag exposures, janky frames, memory pressure), and only inject trace headers on the requests you already know you want. Sampling stays off everywhere else, and workflows can be configured to expire after a set time. You get the traces that will actually matter, deterministically, instead of hoping a percentage-based sample happens to catch them. ## Frontend and user experience data: the second place mobile breaks the model > "Real-time analytics on load times, interaction patterns, conversion rates, and more performance indicators from mobile and browser-based clients." We agree with the eBook here too. Without user-centric metrics, it's impossible to fully validate whether performance issues actually affect real users and, by extension, the bottom line. That's exactly why you can't afford to sample this data either. Sample it, and [your p99s don't tell the true picture](https://blog.bitdrift.io/post/reason-4-crashes), you miss issues altogether, and you don't have the session context you need to debug when something does go wrong. The other problem is that UX data usually doesn't live in an observability tool at all. It lives in a separate analytics product, sampled, with none of the trace or log context that would let you explain why a metric moved. bitdrift ingests the full volume of these events unsampled, in the same platform as your logs, traces, and sessions. Not estimated. Not siloed off in a different tool. ## Why this adds up to a different discipline: mobile-to-backend observability Two of the three pillars Datadog uses to define end-to-end observability behave differently when the frontend is a phone, not a browser. That's not a problem you solve by bolting a mobile SDK onto a backend observability tool. Mobile data can't be sampled the way browser telemetry can, and getting a usable trace from a mobile session requires a fundamentally different approach to deciding what to capture and when. You can use Datadog for browser-to-backend observability today, and it will do a good job. For mobile-to-backend, you need a mobile-native tool: * one that doesn't sample by default; * one that can handle real mobile log and event volume without trading away cost, performance, or visibility; * and one that talks cleanly to the backend tooling you already run. That's not legacy end-to-end. That's ***mobile-to-backend***, and it deserves its own name. --- ## Frequently asked questions ### What is end-to-end observability? End-to-end observability is the practice of monitoring an application's entire architecture, from backend infrastructure and services to the user-facing frontend, so teams can detect, diagnose, and fix issues quickly[^1]. It usually combines infrastructure metrics, distributed traces, and frontend user experience data. Most end-to-end observability tools were built for backend-to-browser architectures and treat mobile apps as just another frontend, even though mobile devices challenge many of the assumptions those tools rely on. ### Does end-to-end observability cover mobile apps? “End-to-end observability” assumes mobile devices are just another browser, but typically doesn’t fully cover mobile. Traditional end-to-end observability tools treat mobile as one more frontend. But mobile apps run on devices teams don't control, go offline, sit in the background for days, and can only change instrumentation with a new app release. Those limits break the sampling and trace-retention models that work in browsers. End-to-end observability for mobile apps, or mobile-to-backend observability, needs tooling designed around the device. ### How do you get end-to-end observability for a mobile app (a.k.a. mobile-to-backend observability)? Mobile-to-backend observability requires a mobile-native observability tool that connects device data to your existing backend tools. bitdrift's mobile observability platform captures unsampled telemetry in a ring buffer on each device and uses workflows to decide which sessions and requests to trace based on conditions you define, such as a crash, janky frames, or exposure to a feature flag. bitdrift supports OpenTelemetry trace ID propagation, so mobile traces connect to the backend observability tools you already use, such as Datadog. [^1]: [The Benefits of End-to-End Observability](https://www.datadoghq.com/resources/end-to-end-observability-benefits-ebook/) Interested in learning more? Check out [the sandbox](https://bitdrift.io/sandbox) or start a [free trial](https://bitdrift.io/signup) to see what working with Capture is like. You can also [get in touch](https://bitdrift.io/contact-us) for a demo or [join us in Slack](https://communityinviter.com/apps/bitdriftpublic/bitdrifters) to ask questions and share feedback.