How a crash investigation runs

An investigation at App Garden Base is a reading, not a war room takeover. The sequence below is what you should expect if you book the flagship crash and stability review or a hotfix study. It exists so a product owner in Petaling Jaya can brief their own team before we arrive.

Access without a second console

We work in the crash product you already pay for. On day one we confirm read-only seats, version filters, and whether mapping files exist for the two builds in dispute. If they do not, the investigation still runs, but every stack is labelled “unmapped” in the brief.

Timeline before traces

Before anyone opens a stack, we write a one-page timeline: store push hour, staged rollout percentage, first support tickets, first spike in a named cluster. Crash and stability analytics without that timeline produces ghost causes — a cluster that looks new but began two versions ago.

Cluster reading, then freeze reading

Crashes, application-not-responding traces, and watchdog kills are listed separately. Mixing them is how a checkout freeze gets treated as a native crash. We keep three columns on paper in the room. Only then do we pick the cluster that explains this week’s mail.

The cut list

The last artefact is short: keep, patch this week, watch on two device classes, or ignore as aged noise. We will argue if product wants a prettier list than the traces support. After the close, you own the patches; the investigation page is finished.

If this sequence matches the week you are in, ask for a crash review and name the two version numbers in the message.