The dashboard is not the system.

Every live game has a crash dashboard. Most studios watch it the way people watch weather: with concern, and without a plan. The number climbs, everyone feels bad about it, a meeting gets scheduled.

I ran crash triage on a live shooter with 2M+ peak concurrent players, three platforms on one shared codebase, and a crash-rate target of under 3% per platform. When I picked the program up there was no board to watch; I stood the dashboards up first. But the dashboard was the input, not the operation. A dashboard is a thermometer. It reads the temperature. It has no opinion about what to do next, and it has never once fixed a crash.

The real system was a daily question: does every crash at the top of the board have an owner, and is it moving? Daily, not weekly. Crash data ages fast, and a spike parked until a weekly meeting is a weekend of players crashing while it waits. Every morning I read the board, confirmed the top crash classes each had a named owner and a current status, and chased the ones that didn’t.

That status lived on a wiki page the whole studio could read: every active crash class, its priority, its owner, a link to the tracking issue. QA and engineering and leadership all saw the same page, so nobody needed a status meeting to learn where things stood. Which is most of what status meetings are for.

Here is the piece I would keep above all the others: crashes have to become searchable text, or you will work the same crash five times under five different names.

Crash dumps come off the console makers’ crash portals as binary files. I pulled each one down, extracted the callstack, and pasted that callstack into the tracking issue itself. It’s an unglamorous habit that changes the economics of triage. When a new crash comes in, you search the tracker for a frame from its callstack, and half the time it turns out to be a crash you already know wearing a different symptom. Five new problems collapse into one known crash class with an owner and a plan. That habit is the difference between a morning that starts with twelve alerts and one that ends with four real problems.

The system ran on influence, not org-chart rank. Every issue I sent over looped in the right people from the start: the QA manager, the team’s producers, the engineering lead. Nobody learned about a crash second-hand, and nobody had to chase me for status. I led by example, first one on the board every morning, pulling the dumps and writing the state down myself. The process stuck because it made everyone’s morning shorter, not because somebody senior ordered it. If a process only runs while someone with rank is enforcing it, it isn’t a process yet.

The target held: under 3% per platform. But the result I’m proudest of is quieter. Once the loop had proven itself, I started delegating it so I could take on problems that didn’t have a system yet, and it kept running without me. Who ended up running it, and what that proves, has its own note: Built to outlive you.

The dashboard is not the system. The dashboard is where the system reports.