Forem: Karina Babcock

Let your agents query reality

Karina Babcock — Mon, 27 Apr 2026 00:00:00 +0000

Last week, we released our first step in making observability programmable and agent-ready with the bitdrift Public API. Today, we're announcing the release of bd skills, a set of skills that give your AI agents access to everything that happens on any of your customers' devices in real time. Together, bd skills and the bitdrift Public API empower the next generation of our mobile observability platform: bitdrift.ai.

Agentic AI has fundamentally changed software engineering

Observability no longer has to be a reactive exercise. Rather than drowning in a sea of alerts, charts, and logs, agents can autonomously triage, investigate, debug, and even fix issues as they happen. This allows teams to focus on what really matters: your customers and their experiences.

Now, those agents, regardless of the model and harness, must have access to high fidelity data to do their job. More importantly they need to be able to iterate in tight feedback loops. In the past that’s been impossible on mobile devices with slow app release cycles and challenging SDK syncs limiting the telemetry being collected. As a result, all other observability tools rely on sampled or stale data. This means you are always working with approximations, partial visibility, historical snapshots, false metrics, and educated guesses.

bitdrift: purpose-built for mobile observability

The bitdrift platform uniquely provides a level and quality of data on deployed mobile applications that no one else can. Data is captured on the device, aggregated in real time, and unsampled by default. When you investigate an issue, you are not querying a static dataset. You are interacting with live user behavior from the device.

Full-fidelity observability, now accessible to AI agents

Now, our real-time observability system allows you or your agents to dynamically create and collect telemetry on any device instantly. User journeys, performance metrics, and behavioral changes are all available when your agent needs them, not ten days later waiting for an app release. And with our ability to narrowly target exact cohorts and data sets, you won’t blow your context window on useless noise.

With this release, agents will be able to leverage our powerful CLI and public API to programmatically access and create the core components of the bitdrift platform: workflows, charts, issues, and captured sessions, letting them iteratively query and analyze telemetry from customer devices.

You can create and manage workflows in code, retrieve full-fidelity sessions on demand, and integrate bitdrift into your existing tooling, your deploy pipelines, or your on-call workflows, all without ever opening a dashboard.

Let your AI agents query reality today

Get started:

Learn more about mobile observability for AI agents at bitdrift.ai, or try it out by running the following in any terminal:

npx skills add bitdriftlabs/bd-skills

Full instructions at https://github.com/bitdriftlabs/bd-skills

Not quite ready to dive in but curious to learn more about bitdrift? Sign up for a free trial of bitdrift's mobile observability platform, or contact us for a quick demo.

Announcing OpenTelemetry mobile tracing (that actually works)

Karina Babcock — Fri, 24 Apr 2026 13:54:21 +0000

Why is mobile tracing very hard?

Let’s talk about why tracing from the mobile client is very difficult, especially at large scale. In any moderately large deployment, backend traces are sampled to control costs. Less sophisticated deployments use random head sampling, deciding at the beginning of the trace whether it is sampled or not). More sophisticated deployments use tail sampling, like the OpenTelemetry Tail Sampling Processor. In these deployments, a trace data is held for a period of time while waiting for a signal to flush the entire trace or not (for example if one of the operations results in an error the entire trace can be flushed).

In a best case scenario with tail sampling, the tail sampling buffer is generally tuned to hold trace data for a very short period of time (minutes at most) because the primary use cases involve back-end network calls and their associated microservices. Compare this to the length of mobile sessions which could be hours or even days!

So fundamentally an engineer who wants to see a mobile session with full backend tracing has to make sure that all network calls in that session are force sampled. But how can this be done sanely? The naive approach is to simply head sample from the client on a strict % basis. This is what every other solution on the market does, which means you’re effectively rolling the dice on whether you’ll have the data you need when something breaks.

However, bitdrift’s dynamic control allows us to fundamentally change how users think about this. bitdrift Capture can provide a tracing experience that is much more likely to capture the customer sessions with traces that engineers actually care about.

Mobile tracing in Capture

Today we are launching a few different things that together provide a novel, holistic mobile tracing experience:

The workflow engine now supports a sampled matcher. This allows flows to only progress a certain % of the time. This feature is not specific to tracing, though it is especially useful in that context.
The workflow engine now supports a “start tracing” action. This allows client side traces to be enabled based on workflow progression.
The mobile SDK now supports an “Is tracing active?” API. The out of the box network integrations have been updated to respect that API and if tracing is enabled, will initiate W3C (OTel) traces on network requests with force sampled set to true against every outbound network call. The created trace ID is then stored in network response log fields. If the session is ultimately flushed and captured, the session timeline UI has gained the ability to deep link to the user’s trace provider of choice to see the full backend trace. For those that are not using our OOTB network integrations, the API can still be used to decide whether trace headers should be added or not.

Together, these capabilities let you deterministically capture full, end-to-end traces for the sessions you care about, without permanently increasing cost or overhead. Now, let’s cover some use case examples to fully understand how this is mobile tracing finally done right.

Mobile tracing use cases

Here are a few common aspirational tracing use cases that show how the new mobile tracing support provides actionable insights quickly.

On-demand tracing of a specific target population

Let’s say that you are rolling out a new feature and want to capture sessions with tracing specific to that feature. Using workflows in bitdrift Capture, you can match on feature exposure, then start tracing. After some period of time (via timeout) or until some action occurs (the feature is used) the session can be flushed.

Between the time tracing was started until the session stops flushing, all network calls will be traced from the client. This guarantees that captured sessions have full backend traces to view. When enough sessions have been captured, the workflow can be dynamically stopped to avoid further tracing overhead. This gives you high-fidelity traces exactly when you need them, and zero waste when you don’t.

Getting traces for a specific failure flow across a very large population

In another scenario, let’s say you have a massive mobile app with hundreds of millions of users that sells widgets. Given the massive deployment size, widget checkout is going to fail for one reason or the other a bunch of times per day across the entire population. It would be extremely useful to get full end-to-end traces of a failed checkout experience. In order to do this, you can create a workflow that has the following steps:

Match on app open with a sample rate of 0.001%.
Wait until checkout fails.
Flush the session.

Probabilistically, every day you are going to capture full sessions with complete end-to-end tracing to help with our understanding of how the backend is involved with checkout failures.

Tracing done right

Gone are the days of performing head sampling on the mobile client and hoping to get lucky with matching backend traces. (Reality check: you never get lucky when you actually need it.)

bitdrift Capture’s mobile tracing integration gives you full real-time control over what session gets traced, allowing you to get the traces you need when you need them. You’ll move from hypothesis to evidence-based understanding of what’s really happening in a single session.

This is just the beginning of our tracing roadmap and we plan on adding a bunch of other features in the future, including the ability to show server spans directly in our session trace view. We can’t wait to iterate based on your feedback!

Join us for the future of observability

Mobile tracing is available today for all customers. New and existing customers can contact us to learn more.

Capture is changing the mobile observability game by adding a control plane and local storage on every mobile device, providing extremely detailed telemetry when you need it, and none when you don’t. If lack of mobile tracing was keeping you away, now is the time to give us a try!

Interested in learning more? Here are some options:

Get in touch for a demo.
Check out the sandbox or start a free trial to dive right into the product and see what working with Capture is like.

We can’t wait to see what you think.

Frequently asked questions

What is OpenTelemetry mobile tracing?

OpenTelemetry mobile tracing extends distributed tracing to the mobile client, allowing engineers to track requests from a user’s device through backend services. Unlike traditional backend-only tracing, it captures the full end-to-end flow of a user session, including client-side context and network interactions.

If you’re new to OpenTelemetry, you can start with this overview: https://blog.bitdrift.io/post/what-is-opentelemetry

What problems does mobile tracing help solve?

Mobile tracing helps engineers debug issues that are difficult or impossible to reproduce locally, such as intermittent failures, long-tail bugs, and complex backend interactions triggered from the client.

By providing full end-to-end visibility into real user sessions, it allows teams to move from guesswork to precise root cause analysis much faster.

Why is mobile tracing harder than backend tracing?

Mobile tracing is more complex because mobile sessions can last much longer (hours or days), data may arrive late or not at all, and cost constraints make continuous tracing impractical. Traditional sampling approaches used in backend systems (like head or tail sampling) don’t translate well to mobile environments and often miss the exact sessions engineers need to debug.

For a deeper perspective on the limitations of OpenTelemetry in real-world systems, see: https://blog.bitdrift.dev/post/reality-check-otel

How does bitdrift’s OpenTelemetry tracing work differently?

bitdrift uses dynamic workflows to control when tracing is enabled on the client. Instead of randomly sampling sessions, engineers can deterministically start tracing based on specific conditions, such as feature usage or error states, and ensure all related network calls are fully traced.

This approach provides complete, high-fidelity traces for the sessions that matter most, without requiring engineers to “get lucky” with sampling.

Does OpenTelemetry mobile tracing require constant sampling?

No. With bitdrift, tracing is activated only when needed using real-time workflows. This avoids the need for constant head-based sampling and reduces unnecessary overhead.

Teams can capture full traces for targeted sessions and then stop tracing dynamically, balancing visibility with cost.

Device performance signals to log for mobile observability

Karina Babcock — Thu, 23 Apr 2026 00:00:00 +0000

Mobile apps are guests on the device; respect the environment

Unlike servers, mobile apps run on hardware with constantly shifting constraints: limited memory, unpredictable networks, and thermal throttling. Monitoring system signals like memory pressure, network usage, and device temperature helps explain performance issues that traditional crash or latency metrics often miss.

In addition to logging important user experience signals (which I wrote about in my last post), mobile observability requires logging device performance signals like memory pressure, network behavior, and thermal state.

Here are some device-level signals every mobile team should be monitoring.

Memory pressure

One of the most common mobile performance killers is memory pressure. Memory leaks on mobile are often misdiagnosed as random crashes. When the OS kills your app because it’s resource hungry, it doesn’t always look like a crash in your logs.

To detect memory-related issues early, mobile teams should monitor metrics such as:

memory footprint over time
OS low memory warnings
foreground vs background memory usage
memory growth across a user session

If memory usage steadily increases during a session without returning to baseline, it’s often a sign of a leak. Identifying this trend early can prevent OS-level out-of-memory (OOM) terminations that are difficult to diagnose after the fact. Tracking memory pressure events and low memory warnings from the OS allows you to see the “cliff” before your users fall off it.

This is another pattern we’ve worked hard to surface at bitdrift by capturing deep memory footprint metrics during sessions, along with app lifecycle context. We did a deep dive on how we handle this here, but the short of it is: We can show you a memory usage graph for every captured session. bitdrift provides deep memory footprint monitoring and it can even capture if the app is in the foreground or background.

Network behavior

Mobile networks are unpredictable. A request that performs perfectly in the office on Wi-Fi may behave very differently on a congested cellular network.

Many teams track network latency, but a single latency metric rarely tells the full story. To understand how network conditions affect user experience, teams should monitor signals such as:

request latency distribution (P50, P95, P99)
network type (Wi-Fi vs cellular)
request retries and failures
bandwidth consumption per session

Bandwidth usage is particularly important on mobile. Some apps unknowingly burn through a user’s data plan due to aggressive telemetry, large payloads, or chatty third-party SDKs.

Another common blind spot is treating a network request as a single latency number. In reality, it includes multiple phases: DNS lookup, TCP/TLS handshake, request transmission, and response time. Without visibility into those steps, it’s difficult to determine whether a slowdown is caused by the backend, the network, or the device itself.

When we built bitdrift, we wanted to expose this deeper level of network visibility. Most tools tell you if an API call failed; bitdrift tells you how much that API call cost the device by looking at:

Bytes Per Minute: We monitor network consumption with high granularity. This allows you to identify “bandwidth hogs.” In practice, these are often 3rd party SDKs or even other observability tools that are over collecting data and burning through the user’s data plan.
Network Visibility: It’s excellent that some teams are tracking client-side network latency. But treating a network request as a single latency metric can lead to, you guessed it, massive blindspots on mobile. We designed bitdrift to break down the socket’s life into its actual components. We do this by tracking the fetch initialization, DNS resolution, TCP/TLS handshakes, and response latency in high resolution. By capturing and plotting these in a waterfall chart, we let you definitively distinguish between an environmental network constraint and a backend performance issue.

Thermal state tracking

Mobile devices dynamically adjust CPU performance based on temperature. When a phone starts running hot, the operating system throttles CPU performance to protect the hardware.

This means an app that performs perfectly under normal conditions can suddenly feel slow if the device is under thermal pressure. Mobile teams should monitor signals like device thermal state and correlate them with performance regressions to understand whether slowdowns are caused by software or by environmental constraints.

A phone that is running hot will throttle the CPU, making your perfectly optimized code run like a turtle.

That’s why bitdrift logs the thermal state of the device. If you see a cluster of performance issues, you can quickly check if they are correlated with high device temperatures, helping you distinguish between a software bug and environmental hardware constraints.

Summary

Device performance signals are a critical piece of the mobile observability puzzle. In Part 1 of this series, we explored the user experience signals that reveal how your app feels to users. In this post, we looked at the device-level constraints – memory pressure, network variability, and thermal throttling — that often explain why performance degrades in the real world.

In the final post of this series, we’ll examine application behavior and contextual UX signals, including lifecycle transitions, feature flag exposure, and session replay, which provide the missing context needed to reproduce and resolve the hardest mobile bugs.

Frequently asked questions

What is memory pressure in mobile apps?

Memory pressure occurs when an app consumes too much memory relative to what the device can support. This can lead to slowdowns, background kills, or out-of-memory (OOM) terminations. Monitoring memory usage over time helps identify leaks and prevent crashes that are otherwise difficult to diagnose.

Why do mobile apps sometimes crash without clear error logs?

Not all crashes are logged as traditional exceptions. In many cases, the operating system terminates the app due to resource constraints like memory pressure. These OS-level kills often leave little to no diagnostic information unless teams are proactively tracking device performance signals.

How does network variability impact mobile performance?

Mobile networks are inherently unstable and can vary based on location, congestion, and connection type (Wi-Fi vs cellular). This variability affects request latency, retries, and failures. Without logging detailed network behavior (including DNS, connection setup, and response time) it’s difficult to pinpoint the root cause of performance issues.

What is thermal throttling and why does it matter?

Thermal throttling occurs when a device reduces CPU performance to prevent overheating. This can make an app feel slow even if the code is well-optimized. Tracking device thermal state helps teams distinguish between performance issues caused by software and those caused by environmental conditions.

A sneak peek at new bitdrift Workflows UI

Karina Babcock — Thu, 26 Mar 2026 12:00:00 +0000

We're about to ship a ground-up redesign of Capture workflows that makes them fast to build, easy to read, and ready for AI agents to create and manage programmatically.

A sneak peek at our new Workflows UI

bitdrift Capture workflows have always been powerful. We're about to ship a ground-up redesign that makes them fast to build, easy to read, and (when we release our public API in the very near future) ready for AI agents to create and manage programmatically. This redesign lays the groundwork for first-class tooling support: a public API, CLI access, and the ability for LLM agents to instrument apps and manage workflows autonomously.

A quick refresher

Capture is a fundamentally different take on mobile observability. Rather than sending non-useful samples or firehosing every log from every device to a backend that processes and discards most of it, Capture keeps data on-device and only ships it when something interesting happens. The mechanism that defines "interesting" is the workflow: a state machine deployed in real time to your fleet that describes sequences of events to match on and actions to take when they do.

Workflows are powerful. They can also be humbling. Over time, as customers pushed them to their limits, we heard the same feedback again and again: too many clicks, too many advanced features, too much nuance to learn before being productive. We took that feedback seriously and rebuilt the workflow experience from the ground up.

What's coming

A faster, cleaner builder

The new builder is optimized for speed. Graph layout is now calculated automatically, drag and drop is gone, and steps are placed contextually as you build. Keyboard shortcuts cover the most common operations, so power users can move quickly without reaching for the mouse. The result is an experience that feels much more like writing code than assembling a flowchart.

The new workflow builder: Actions are attached, not floating

In the previous builder, actions (record session, plot chart, etc.) were standalone floating nodes connected to matchers by edges. This made complex workflows hard to read at a glance. Actions are now directly attached to the step that triggers them, so the relationship between a match condition and its outcome is immediately obvious.

Steps have names. Everything follows.

You can now name your workflow steps, and all titles, series names, and chart metadata are inferred from those names automatically. Less busywork, and your charts finally describe what they're actually measuring.

Exit conditions

We're generalizing and replacing the previous "timeout rule" with a more powerful and flexible concept: exit conditions. An exit condition can be a timeout or any matcher, and when it fires, it can trigger any combination of actions (charts, record sessions, etc.) just like a normal match step. This makes it straightforward to express patterns like "if the user abandons the checkout flow at any point, record the session."

Reset and entrance behavior, made visible

Reset and entrance behavior — the rules that govern when a workflow restarts or re-enters — are now surfaced clearly in the UI rather than buried in configuration drawers. Workflows can now contain multiple independent flows, each with its own entry point, running in parallel. Resets on one flow are isolated from all others.

Smarter conditionals

Match conditions now support both ANDs of ORs and ORs of ANDs. Previously, only one form was supported, which forced awkward workarounds for common cases. Both are now first-class.

Charts, simplified and split out

The previous "chart" action covered a lot of ground in a single configuration surface. We've split it into focused types (Counters, Histograms, Rate, Average, Funnel, and Sankey), each with a vastly simpler configuration. The "Advanced charts" section is gone. Chart customization (titles, series names, units) is now done directly on the chart itself rather than in the workflow, which means the same underlying data can be visualized differently depending on where it's shown.

Measure duration gets more powerful

The measure duration step now supports restricting actions to a specific duration range. For example, only record a session when the time between two steps exceeds 10 seconds. You can also attach any existing action to a measure duration step, giving you full flexibility over what happens when a timing threshold is crossed.

The big reason we rebuilt this

Customer feedback drove a lot of this. We heard clearly that workflows needed to be more intuitive, faster to learn, and less prone to surprising behavior. Every item in the list above traces back to a real conversation with a real user who got stuck.

But there's a bigger reason.

We're about to launch a public API and CLI that unlock everything the UI can do (and more). AI agents will be able to instrument apps, create workflows, and debug issues autonomously. For that to work, workflows had to be representable as clean, predictable code rather than a sprawling visual graph with implicit rules and hidden state. The redesign wasn't just about making workflows easier for humans. It was about making them machine-readable.
This is the foundation for what comes next.

blog.bitdrift.io

New Workflows UI walkthrough

Interested in learning more? Get in touch with us for a demo.

Please join us in Slack as well to ask questions and give feedback!

User experience signals to log for mobile observability

Karina Babcock — Tue, 17 Mar 2026 17:02:34 +0000

The green dashboard fallacy

Every mobile engineer has experienced this scenario in some form or another: your backend health is green, your crash free rate is at 99.9%. Yet, App Store reviews are flooding in about the app being "slow" or about a broken experience users encountered.

Here's the problem: Mobile apps fail in ways traditional observability tools can't detect and dashboards can't see. Teams log for the disaster (the crash) but they're blind to the friction (the jank). The approach is reactive, fragmented, and heavily sampled.

To build a high performance mobile app in 2026, you need to log the signals that explain how the app behaves on a real device. Your strategy should shine a light on the mobile-specific blind spots that servers simply don't have.

In this three-part series, we'll unpack the most important signals mobile teams should be capturing, starting with user experience (UX) signals.

User experience (UX) signals

The first blindspot in mobile observability is that users experience apps as interactions, not metrics. In other words: Users don't care about your uptime; they care about how the app feels.
Here are some specific metrics to help you understand user experience.

Frame drops and UI jank

Mobile users immediately notice frame drops. Even small stutters can make an app feel unreliable. This is one of the biggest blind spots on Android: micro stutters or freezes.

Aside from being annoying for end users, Google Play penalizes apps' Play Store rankings if they exceed their threshold and your app might even get a warning label on your Google Play store page. Scary, right? To make it worse, you might know your app feels laggy, or you might see a generic slow rendering percentage in Google Play Console, but how do you actually fix that?

Most tools only show aggregate rendering metrics. They don't tell you:

which screen dropped frames
what the UI state was
what the device was doing at the time

The good news is that libraries like Android JankStats do expose this information at the frame level. When you log these events with context (screen name, device state, network state), you can pinpoint exactly why rendering fell below 60fps.

That's why we've integrated bitdrift directly with the Android JankStats library. This allows us to track every single frame drop and, crucially, attach UI State to it. By capturing the specific UI state at the exact millisecond a frame exceeds 16ms, you can identify and fix the issues that actually impact your Google Play Store ranking. It's the difference between guessing where a bottleneck lives and having a frame-by-frame receipt of why your app isn't hitting its 60fps target.

"Intent-to-action" workflows

Mobile users don't experience apps as isolated functions. They experience workflows. A user taps "Add to Cart," submits a login form, or starts checkout and expects something to happen immediately. When those workflows feel slow or fail silently, users notice. Yet many observability tools focus on backend latency or crashes, leaving the client-side gap between user intent and visible result largely unmeasured.

Mobile teams should instrument the start and end of key user actions to track workflow latency, completion rate, and timeouts. Measuring the time between events like "Add to Cart tapped" and "Cart updated" reveals whether real user interactions are getting faster or slower across releases. Capturing outcomes (success, retry, failure) and basic context like device model, network type, and UI state helps engineers understand why a workflow is degrading. These signals often surface issues such as network stalls, UI deadlocks, or backend slowdowns that never show up in crash dashboards but still damage the user experience.

This is another area we've looked closely at as we built our mobile observability solution. With bitdrift, measuring the time between any two logs is trivial. You don't need to wrap your code in complex stopwatches or spans. If you have a log when a user taps "Add to Cart" and another when a "Success" message appears, you can create a dynamic span in the bitdrift dashboard using workflows to measure that duration across your entire fleet. The best part is that these dynamic spans don't require a new app store release and you can tweak them to broaden the trigger/end point. You have full control.

Here's a code sample of how you can add a custom log like "Add to Cart" to your code using bitdrift:

kotlin
import android.os.SystemClock
import io.bitdrift.capture.Capture
import java.util.UUID

fun onAddToCartClicked(productId: String, price: Double) {
    val opId = UUID.randomUUID().toString()
    val startedAtMs = SystemClock.elapsedRealtime()

    // 1) Start marker: user intent + context
    Capture.Logger.logInfo(
        fields = mapOf(
            "event" to "cart_add_initiated",
            "op_id" to opId,
            "product_id" to productId,
            "price_usd" to price.toString(),
            "ui_state" to "product_detail_view",
            "interaction_type" to "tap",
        ),
    ) { "Cart.AddInitiated" }

    cartRepository.addToCart(productId) { success, errorCode, errorMessage ->
        val durationMs = (SystemClock.elapsedRealtime() - startedAtMs).toString()

        if (success) {
            // 2) Success marker: bitdrift now has a clear 'intent-to-action' delta
            Capture.Logger.logInfo(
                fields = mapOf(
                    "event" to "cart_add_success",
                    "op_id" to opId,
                    "product_id" to productId,
                    "duration_ms" to durationMs,
                ),
            ) { "Cart.AddSuccess" }
        } else {
            // 3) Non-fatal failure marker: Captured with error context
            Capture.Logger.logWarning(
                fields = mapOf(
                    "event" to "cart_add_failed",
                    "op_id" to opId,
                    "duration_ms" to durationMs,
                    "error_type" to "network_timeout",
                    "error_code" to (errorCode ?: "unknown"),
                    "error_message" to (errorMessage ?: "unknown"),
                    "was_retry" to "false",
                ),
            ) { "Cart.AddFailed" }
        }
    }
}

And here's what the resulting log would look like:

json
{
  "message": "Cart.AddFailed",
  "level": "warning",
  "timestamp": "2026-03-03T17:41:06Z",
  "fields": {
    "event": "cart_add_failed",
    "op_id": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
    "product_id": "sku_9921_x",
    "price_usd": "45.00",
    "duration_ms": "1240",
    "error_type": "network_timeout",
    "error_code": "504",
    "error_message": "Gateway Timeout",
    "was_retry": "false"
  },
  "context": {
    "device_model": "Pixel 8 Pro",
    "os_version": "Android 14",
    "network_type": "cellular",
    "thermal_state": "nominal",
    "memory_usage_mb": "412",
    "session_id": "sess_882194",
    "app_lifecycle": "foreground"
  }
}

The "silent" timeout

Workflows aren't just for successes. You can and should also be tracking timeouts. What happens if a user starts a checkout but the order_confirmed log never fires?
One of the most damaging mobile experiences is the silent timeout:

User taps a button
A loading spinner appears
Nothing ever finishes
Because these events don't crash the app, they often go completely undetected.
Mobile teams should define expected completion windows for critical workflows. If a workflow does not complete within that window, it should be treated as a failure event.
This helps identify:
Backend stalls
Lost network requests
UI deadlocks
Dropped callbacks

Bonus: this is another area where bitdrift can help. With bitdrift's Timeout Matcher, you can set a workflow to trigger an action, like "record session", if a specific sequence of logs doesn't complete within a set timeframe (e.g., 15 seconds). This will help you catch the "spinning loading wheel of death" use cases that don't technically crash but definitely cause churn. Maybe even more important: it also means you get the full user session allowing you to see exactly what happened to the user during this eternity…errr 15 seconds.

Summary

Crash rates don't tell you how your app actually feels to users. Signals like frame drops, workflow latency, and silent timeouts reveal the friction that traditional observability tools often miss. Logging these UX signals is the first step toward understanding what's really happening on user devices.
Next in this series, we'll look at device performance signals: the memory, network, and thermal metrics that explain why perfectly good code can suddenly slow down in the real world.

Interested in learning more? Check out the sandbox or start a free trial to see what working with Capture is like.