Cursor made a name for itself by building an AI-powered code editor that developers actually want to use. For many engineers, it was one of the first AI coding products that convinced them to change the way they work.
The dev-focused approach earned them a lot of fans, fast. Just a few years after being founded, their customer list was already a who’s who of tech, citing teams at companies like Figma, Ramp, Stripe, and more as users. Their testimonials section has a hype quote from Jensen Huang — quite the flex, for any AI co. The company’s ARR went through the roof in no time flat; fittingly, SpaceX has exercised an option to acquire Cursor for a reported $60 billion.
The Cursor desktop client is the kind of app that engineers leave open for hours upon hours each day. Keeping that experience stable — with lots of huge open files, multiple lengthy agent conversations, and more across multiple processes — is an engineering challenge of its own.
When Cursor’s client infrastructure team needed visibility into what was breaking (and why) at scale, there was no question: they’d use Sentry. We sat down with Andrew Chan from Cursor’s client infrastructure team to learn more about how they use Sentry to find what’s broken and fix it fast.
Before Sentry: Desk-side debugging
As is true of a lot of hyper-growth startups, many things were being hashed out in-flight early on. This included the debugging workflow; when Andrew joined, hunting down bugs was still a very manual process.
“We were mostly running around debugging internal bug reports in person. Somebody would mention a stuck chat with a weird error and I’d run over to their desk and ask to see their DevTools console and live debug it. It was… very labor intensive; kind of all-hands-on-deck all the time.”
Andrew Chan, Software Engineer
“There was no way we could sustain that sort of practice. It was fast! But not scalable.”
Andrew Chan, Software Engineer
No Bake-Off
So why’d they pick Sentry? Because much of the team already knew and loved it. It’s a story we hear a lot, but will never get tired of: people like to bring Sentry with them. Sometimes it’s from using Sentry on personal projects; sometimes they used it at a former company.
In Cursor’s case, there wasn’t a debate.
“A bunch of us had used Sentry before. My coworker had used Sentry at some of his previous companies and he added it. I’d used Sentry before too at a previous job, so I hopped in and immediately was like: yep, I know how to use this, this is great. I’m very thankful to my co-worker for just doing the thing.”
Andrew Chan, Software Engineer
How They Use It
Cursor’s IDE is built on Electron, and is split across multiple processes running simultaneously — one for the app itself, others for rendering, extensions, etc. Getting reliable error data across all of those processes isn’t a given, especially if part of the network stack isn’t available when a crash occurs.
But Sentry’s Electron integration worked everywhere they needed it, and gave them consistent, reliable error data regardless of where in the app something went wrong.
Cursor uses errors and stack traces to find issues, breadcrumbs to reconstruct the scene right before an error occurred, and Session Replay (for internal users) when they need to see what was happening on screen.
“Breadcrumbs have served us very well. They help us figure out what the user was doing leading right up to the error.”
Andrew Chan, Software Engineer
Sentry also helps them figure out which errors are real today, and which are lingering artifacts of builds prior. Because Cursor includes a desktop app, they can’t always depend on users having the latest and greatest build. Some users might go days or weeks without hitting that update button, and version metadata in Sentry helps the team distinguish which errors are still live problems and which they’ve already shipped a fix for.
Cursor also built a custom dashboard that periodically pulls in Sentry event data, giving them a real-time view of crash rates broken down by app version. Those dashboards update within minutes of a crash event, allowing them to catch regressions in a new release before it spreads.
The Case of the Disappearing Messages
Not long after getting Sentry up and running, Andrew got a chance to put it to work on a particularly curious bug: chat messages were disappearing from the chat pane and agent sidebar without any immediately obvious trigger.
It’s the kind of issue that can be hard to recreate, and can happen for all sorts of reasons, from user error, to rendering glitches, to memory issues.
“It wasn’t one we anticipated. It’s not [the kind of bug] you think about until it happens.”
Andrew Chan, Software Engineer
Conveniently, an employee reported seeing the bug occur on their own machine shortly thereafter. Cursor enables Session Replay just for employee/internal users, allowing them to see exactly what was going on at the precise time the messages disappeared.
“Because they were an internal user, we were able to use Replay to scrub through what they were doing. There was a clear correlation between a suspicious looking error and the chat bubbles disappearing, so we could say ‘Ok, this probably points to the root cause. Here’s how we’re going to track the frequency of this bug, and verify that it’s fixed by watching that go to zero.’”
Andrew Chan, Software Engineer
(For the curious: the team traced the issue back to a stack overflow bug in the rendering framework they use.)
Automating the bug hunt
Sentry helps Cursor’s developers find and fix bugs faster. More recently, it’s become a key component of something more ambitious: an automated pipeline that drafts bug fixes for them, too.
Cursor’s client infrastructure team runs a daily automation built on top of Sentry’s crash data. This automation pulls crash stacks, feeds them to an AI agent for analysis, and asks two questions: which feature caused the crash, and does the stack actually point to a fixable root cause — or just code that happened to be running at the time?
Their automation generates a score as to how confident it is that a crash stack in question points to the real root cause; if confident enough, it dispatches another agent to propose a fix.
Andrew notes that no code is auto-merged at this point, and all PRs get human review. But for one of their most common crashes (wherein the app is trying to read a massive file without sufficient memory guard rails in place, causing the app to run out of memory) their automations are doing some heavy lifting to help them clean up.
“A lot of the crashes that we’ve run into are following this particular pattern, and that’s where the automations really come in handy.”
Andrew Chan, Software Engineer
Andrew wrote in depth in April about improving the stability of the Cursor app, noting that they’ve managed to reduce these out-of-memory issues by up to 80% from their peak.
The Async Advantage
Before Sentry, tackling bugs at Cursor required someone in the room. When a crash would happen, someone would run over, pull up a DevTools console, and start tearing through the haystack. It worked, but it was unscalable.
“The main benefit of Sentry is that it allows us to work asynchronously, and it allows us to track the impact of our fixes over time.”
Andrew Chan, Software Engineer
Sentry gives the Cursor team the signal they need, when they need it, wherever and whenever that crash might’ve occurred.
“It’s extremely powerful to have these signals feeding directly back to you.”
Andrew Chan, Software Engineer