Bitdrift ships OTel for mobile sessions

Mobile tracing is one of those things that sounds solved until you try to debug a real bug from a real phone. Backend teams already have OpenTelemetry everywhere. But the moment a request starts on a user’s device, the trail often gets thin, sampled away, or lost entirely. That gap is what bitdrift is trying to close with a new OpenTelemetry-compatible tracing release for its Capture product, announced last week. (blog.bitdrift.io) ### What actually shipped? Bitdrift shipped OpenTelemetry-compatible distributed tracing for mobile sessions inside Capture. The basic move is simple — the SDK can attach an OpenTelemetry TraceID to selected network requests, then link that request back to the full mobile session and its logs. The company is pitching this as a way to extend an existing APM stack out to “the infinite edge” instead of replacing it. (blog.bitdri([blog.bitdrift.io)mobile the hard part? Servers are stable. Phones are not. Mobile apps run in short bursts, get backgrounded, lose connectivity, hit battery constraints, and operate on wildly different hardware. That means the normal backend assumption — always-on processes emitting steady telemetry — just does not hold up on a device. Even bitdrift’s own OpenTelemetry explainer makes the point that OTel includes only limited mobile SDK support and that mobile is not a primary focus for the project. (cncf.io) ### What’s broken with normal tracing? The main problem is sampling. Most observability systems keep cost under control by collecting only a fraction of sessions and traces. That works fine for aggregate trends, but it is rough for one weird customer issue that happened once on one device under one bad network condition. Bitdrift’s whole model is built around buffering rich telemetry on-d(cncf.io) (bitdrift.io) ### So how does bitdrift handle it? Instead of tracing every request from every device all the time, bitdrift uses workflows on the device to decide when to capture more detail or add tracing metadata. Those workflows can trigger on specific conditions and actions, including adding an OpenTelemetry trace identifier to a request. That lets a team start with mobile-side evidence — the user action, device state, logs, and session timeline — and then jump into the backend trace tied to that exact request. (bitdrift.io) ### Why does “session context” matter so much? Because the bug is often not in one request. A failed checkout or broken voice interaction can be the end result of a whole chain — app state, retries, degraded connectivity, UI timing, and then a backend error. A backend trace alone shows the server’s slice of reality. A mobile session shows the lead-up. Put them together and you get something closer to the full story. That is the real value here. (blog.bitdrift.io) ### Is this replacing OpenTelemetry? No — basically the opposite. Bitdrift is leaning into OTel as the handoff format while arguing that OTel by itself is not enough for mobile observability. The company’s pitch is bring your own backend, keep your existing tracing tools, and use bitdrift to supply the missing device-side context. That is a pragmatic position, and probably the only one buyers will accept right now. (bitdrift. ([blog.bitdrift.io)he catch is that this is still a vendor layer on top of the standard. OpenTelemetry gives portability, but bitdrift’s special sauce is its own workflow engine, local buffering model, and session capture. So the “compatible” part is real, but the differentiated part still lives inside bitdrift’s system. (bitdrift.io) ### Bottom line? This release matters because it (bitdrift.io)d, not just from the backend backward. If bitdrift’s approach works in practice, teams get something they usually do not have today: a clean path from “the app felt broken” to the exact distributed trace that explains why. (blog.bitdrift.io)