Breadcrumbs that lie

A breadcrumb trail in Crash Analytics Monitoring is a list of things that happened near a fatal event. Near is not because. The last screen is often a settings page because people open settings when something already feels wrong. Blaming settings is a category error.

We ask learners to strike half the trail. What remains should be able to appear in a sentence to product: “payment sheet opened, token refresh failed, native crash in the card module.” If you cannot say that sentence, you have a chronology, not a cause. Logging every tap fills the quota and starves the useful events.

Network retries are a classic liar. Five failed calls look dramatic and may be a captive portal in a train station. Pair them with a connectivity breadcrumb you trust, or leave them out of paging. Studio datasets include a GB commute sample for this reason — evening Thameslink Wi-Fi is not a backend incident.

Budget the trail: a small number of high-meaning events beats a novel. If your SDK caps the buffer, spend the last slots on state you cannot reconstruct from the stack. That is craft, not configuration trivia.