What is a crash cause category?

A coarse-grained bucket a crash falls into: null dereference, out-of-memory, GPU driver error, network timeout, assertion failure, stack overflow. You get 5-10 categories total. Individual crashes are specific; categories surface systemic patterns.

Why track categories instead of individual crashes?

Individual crashes get fixed and you forget them. Categories surface when 'null deref' rate climbs every week for a month - a pattern one crash doesn't reveal. Tracking categories shows whether the team is improving structural reliability or just playing whack-a-mole.

How do I categorize a crash automatically?

Match the exception type and top stack frame against a rule set. NullReferenceException + any .NET stack is 'null deref'. OutOfMemoryException is 'OOM'. Fallback: unknown. Review unknowns weekly and expand the ruleset; after 3 months your categorization coverage should be above 95%.

How to Track Crash Cause Trends Weekly

Quick answer: Bucket every crash into 5–10 coarse categories (null deref, OOM, GPU driver, etc), classify on ingest with stack + exception rules, plot stacked area charts weekly. Categories surface patterns individual crashes hide.

Every week you fix the top 10 crashes. Next week there are 10 new top crashes. The dashboard feels like a treadmill because you’re solving specific bugs, not patterns. Grouping crashes by root cause category shows whether the team is actually making the game more reliable or just treading water.

The Categories

Pick a small, fixed set that covers 90%+ of your crashes. A typical Unity/C# game:

null_deref: NullReferenceException
oom: OutOfMemoryException, native heap exhaustion
gpu_driver: DXGI, Vulkan, Metal driver errors
network_timeout: WebException, SocketException
assertion: Debug.Assert, UnityEngine.Assertions
platform_api: Steam/Xbox/PSN SDK crashes
serialization: save file parse failures
unknown: fallback

Classification Rules

def classify_crash(report):
    if "NullReferenceException" in report.exception_type:
        return "null_deref"
    if "OutOfMemory" in report.exception_type:
        return "oom"
    if any(f in report.top_frame for f in ["d3d11", "vulkan", "metal"]):
        return "gpu_driver"
    # ... more rules ...
    return "unknown"

Review the unknown bucket every week. Any new cluster becomes a rule. After a few months, unknown should be under 5%.

The Weekly Chart

Stacked area chart, one band per category, y-axis normalized to crashes per 10K sessions. The stacked shape shows both total volume and category mix at a glance. A rising null_deref band means structural issues in specific systems — investigate the code architecture, not individual crashes.

Actionable Signals

A category growing week-over-week by >10% for 2+ weeks — start a structural fix project.
A category spike in one week — recent release likely caused it; look at what shipped.
A category you’ve never seen before — platform update, driver release, or new exploit.

Beyond Crashes

The same pattern works for non-fatal errors, performance incidents, and bug reports. Categorize once, review weekly, fix patterns. Individual fixes are tactical; category work is strategic.

“Fixing one crash is good. Fixing the class of crashes that made it possible is ten times better. Categories make the class visible.”

Related Issues

For the crash deduplication pipeline that feeds this, see how to build a crash report deduplication system. For longer-term crash rate tracking, see how to track and reduce crash rate over releases.

Review the unknown bucket every week. It’s where new failure modes hide, and leaving it untouched means you’re categorically blind.