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:- Configured the Embrace integration and are forwarding network spans to Honeycomb.
- Configured an Embrace alert on ANR rate or hang rate for the relevant screen or flow.
Investigate the ANR spike
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.
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.
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.
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.-
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
traceparentvalue. Thetraceparentvalue follows the format00-<trace-id>-<span-id>-<flags>. The trace ID is the second segment: the 32-character hex value between the first and second hyphens. - Copy the trace ID. You will use it to find the matching trace in Honeycomb.
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:
-
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. - 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.
- 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.
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