Skip to main content
Docs·Concepts·Crashes

Triage like a senior engineer

Three questions to ask of every new crash signature, in order.

📖 3 min read·🎬 90s watch

A new crash report comes in. Pager fires. Heart rate spikes. Before you panic, ask three questions in order. The answer to the first one usually tells you whether to keep going.

Question 1: Is it new?

A crash signature that's been firing for six months at one-per-day is a "known issue" with a ticket. A crash signature that started this morning is a regression. The Sheepit timeline tells you instantly — new signatures get a yellow "new" badge.

Question 2: Is it spiking?

Five crashes total = probably one weird user with a corrupted state. Five thousand crashes in the last hour = something broke for a chunk of your install base. The crashes view sorts by rate-of-change so you see spikes first, not totals first.

Question 3: Is it user-facing?

A crash in a background sync that retries on next launch is annoying. A crash on app startup is a five-alarm fire. Sheepit tags each signature with where in the lifecycle it fires so you can sort by "actually visible to the user."

The release-link rule

If a new signature started within an hour of a deploy, it's that deploy. Don't search the codebase from scratch — open the release in Sheepit, see the PRs that landed, find the suspect in two clicks. The integration with releases is the whole point.