For users who spend their entire workday in the Cursor application, even infrequent crashes can be a major disruption. As the platform adds features like subagents and instant grep, maintaining stability becomes increasingly complex. The primary culprit for these crashes has been out-of-memory (OOM) errors. Over recent months, Cursor has rolled out new systems for crash observability, memory pressure monitoring, and high-confidence fixes, leading to an 80% drop in OOM-per-session rates since its late-February peak. This post details the engineering efforts behind these improvements, as reported by Cursor Blog.
Detecting and Measuring Instability
Built on Visual Studio Code and Electron, Cursor's multi-process architecture means crashes can originate in renderer processes (editor, agents) or utility processes (extensions, storage). Renderer crashes are most severe, often tied to V8 memory limits. Extension crashes can disrupt functionality but typically recover.
Every fatal crash is automatically reported via telemetry, including process details, crash type, device metadata, and stack traces. These events feed into dashboards that track metrics like OOM-per-session and OOM-per-request, allowing rapid detection of regressions after new versions ship.
Dual Debugging Strategies
Cursor employs a two-pronged approach to tackle crashes and memory issues.
