Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.honeycomb.io/llms.txt

Use this file to discover all available pages before exploring further.

Overview

When Embrace alerts on a spike in Application Not Responding (ANR) errors or hangs, the first question is whether the cause is on the client or upstream. Use Embrace’s session data and Honeycomb’s trace analysis together to answer that question quickly and hand off to the right team with evidence.

Before you begin

Before you begin, make sure you have:

Investigate the ANR spike

1

Open the Embrace alert

When Embrace fires a critical alert (for example, ANR rate on a checkout screen crossing a threshold), the notification includes a direct link to the alert detail in Embrace. Open it to see the affected user count, the screen, and the platform breakdown.
2

Identify the pattern

In Embrace, open the ANR issue breakdown. Embrace groups ANR sessions by stack group and shows what was blocking the main thread at the time of the freeze.If the top cause is HTTP request in-flight, the issue is upstream: the app was waiting on a network response when the OS killed the activity. This rules out client-side causes like JSON parsing, disk I/O, or animation jank, and points the investigation toward the backend.
3

Open a representative session

From the issue breakdown, select a representative session to open the session timeline. The timeline shows the sequence of user actions leading up to the ANR: the screens visited, the taps made, and the network request that was in-flight when the hang occurred.The hung network request appears in the timeline as a span with a long duration and no response status, marking the point where the OS gave up waiting.
4

Find the trace ID in the forwarded span

The traceparent value on the forwarded span is the bridge between Embrace and Honeycomb. It contains the trace ID you need to find the matching backend trace.
  1. In the session timeline, expand the hung network request to view its span details. If Embrace forwarded this span to Honeycomb, the expanded row shows a Forwarded badge and the full W3C traceparent value. The traceparent value follows the format 00-<trace-id>-<span-id>-<flags>. The trace ID is the second segment: the 32-character hex value between the first and second hyphens.
  2. Copy the trace ID. You will use it to find the matching trace in Honeycomb.
5

Find the backend trace in Honeycomb

With the trace ID in hand, you can find the exact backend trace in Honeycomb and walk the full request waterfall to identify where the time was spent.In Honeycomb:
  1. Open Query Builder and filter for trace.trace_id = <your-trace-id>, replacing <your_trace_id> with the value you copied from Embrace. The query returns the matching backend trace.
  2. Select the Traces view, then the Trace ID to open the trace waterfall. The waterfall representation shows the backend service spans, with the Embrace-forwarded client span at the top.
  3. Examine the waterfall to find where the time was spent. Look for spans with unexpectedly long durations, error statuses, or external dependency calls that timed out.
6

Run BubbleUp to confirm the scope

From the waterfall, open the slow span in Query Builder and run BubbleUp to confirm whether this is an isolated event or a broader pattern. BubbleUp surfaces the dimensions that differentiate the slow spans (for example, aws.region and dependency), so you can confirm whether the issue is concentrated in a specific region or external service.

Hand off with evidence

With the BubbleUp results, you have a specific, falsifiable bug to file:
  • The trace ID
  • The name of the hung backend span
  • The external dependency or region responsible
  • The affected user count from Embrace
File the ticket against the owning backend team with the Honeycomb trace link and the Embrace session link. The mobile investigation is complete: you have confirmed the cause is upstream, identified the responsible team, and provided the evidence they need to reproduce and fix it.