Background:
The inherent nature of how people use mobile apps means that there will always be a delay in sending certain types of data across the network to an external service. Crashes are a prime example of how and why this delay works.
When an app crashes, it is no longer active on a device. Therefore, while information about this crash may have been captured and stored on the device, it can’t be sent to the service until the user re-opens the app and re-establishes a network connection. This delay in sending information is dependent on the user and when they choose to re-open the app – it could be a few seconds, a few hours, or they might choose to never open the app again.
This delay has implications for what kind of data you see when using an observability service.
Data discrepancy:
In the Embrace dashboard, all retroactive crash data is captured and timestamped according to when the event happened (not when the event was received). There is no appreciable time limit to our data capture in terms of how far into the past an event happened before it can be received. We will capture retroactive data as far back as our data retention policies allow, which varies based on customer account settings.
When looking at Embrace data that is sent to other platforms via OTLP, this is not the case.
Embrace pushes data to other platforms as (1) hourly aggregates and (2) daily aggregates. In the case of hourly aggregates, any app data not sent within the hour will not appear. In the case of daily aggregates, app data not sent within the past hour but sent within the past day will appear. However, any app data not sent within the past day will not appear.
| App re-opened / Crash data sent | Captured in Embrace dashboard | Captured in OTLP receiver platform |
| Within 1 hour of crash event | yes | Yes, in hourly aggregate metric |
| Within 1 day of crash event | yes | Yes, in daily aggregate metric |
| 1 day or more after crash event | yes | No |
Benefits and drawbacks of each case:
When crash data is received a considerable amount of time after the event happened (for example, 1 day++), this can cause aggregate metrics (such as crash-free sessions %) to change in unexpected ways.
This can be helpful or not, depending on what you need to look at.
If you want a real-time barometer of your app health as it stands today, receiving retroactive data is not helpful. This is because it can artificially swing your aggregate metrics up/down based on events that have happened in the past and which are not actively impacting your users currently.
If you want to deep-dive into particular issues that have surfaced time and again, receiving retroactive data is helpful. This is because it ensures that all data points are captured and available for you to examine forensically.