About Bolt
Launched by Stackblitz in 2024, Bolt was one of the first tools to allow non-developers to build full-stack applications with natural language prompts. Its reach spans startups, Fortune 500s, and entrepreneurs who’ve never written a line of code — all using it to prototype and ship on top of their production codebases.
The team is roughly 60 people, with engineering distributed across the US and Europe. After launching and going from zero to roughly 250,000 weekly active users in its first two months, Bolt needed an observability platform that could keep up with its scale.
One application, two monitoring stacks
Bolt runs on a modern JavaScript stack: built with Remix, deployed via Cloudflare Workers, with its own database. But the team’s observability tooling was chosen for an earlier iteration of their product, which ran on a Rails backend. Support for Cloudflare Workers existed, but it felt like an add-on rather than a first-class feature. When Bolt’s traffic scaled, bug reports flooded in and triaging them became a fire drill.
“Not having good observability on our Bolt stack just wasn’t an option. We were hitting record traffic highs for months straight after we launched, and that comes with a lot of user requests and bug reports. We had to scramble to solve for that.”
— Albert Pai, Co-founder and CTO
Why Sentry: first-class support where it actually mattered
When the team went looking for an alternative, runtime coverage was a critical factor. Sentry’s first-class support for both Remix and Cloudflare Workers meant the team could get the depth of visibility they needed without stitching together partial solutions.
Sentry’s AI SDK integrations were also a draw early on. As Bolt’s usage of AI models scaled rapidly, out-of-the-box instrumentation for AI workloads gave the team visibility into what was happening under the hood, without requiring manual instrumentation from scratch.
Engineers who had used Sentry at previous companies felt at home, and early results were strong.
Knowing before the status page does
Sentry now monitors roughly a dozen distinct services across Bolt’s platform. They don’t just get value from catching their own bugs — they can also stay ahead of other providers’ issues.
Because Sentry captures all of Bolt’s API interactions with third-party services, the engineering team can detect a degradation in an upstream service before that provider has even updated their own status page. The common question “is this us, or is this them?” now gets answered right away.
“Without good observability, we’re usually left scrambling to see: is this our problem? Do we need to dig deeper? Now we can front-run what other status pages are even showing.”
— Albert Pai, Co-founder and CTO
Catching the bugs that hit the bank account
As an AI-native company, Bolt’s unit economics are tied directly to model inference.
During one incident, the team noticed token consumption discrepancies that didn’t add up. Because Bolt’s user profiles were connected to their Sentry data, engineers could drill down to individual users and inspect their specific token consumption patterns to isolate where the variance was coming from. Luckily, they caught it quickly and contained the blast radius. But the incident signaled something larger: for AI-native products where token consumption equals dollars spent, fast detection isn’t optional.
How Bolt uses Seer: first pass on errors, faster PRs
Beyond error monitoring, Bolt’s engineering team has integrated Seer (Sentry’s AI debugger) into their daily workflows. When an error surfaces in the Sentry dashboard, Seer handles the initial triage: summarizing what’s wrong, identifying likely causes, and flagging the relevant code paths.
When a fix is needed, the team routes it through their coding agent using Seer’s root cause analysis as the starting context. Seer identifies the problem, the agent implements the fix, the PR comes back for review.
“When there’s an error, we can have Seer take a first pass at it. Developers get a summary of what’s happening, and they can take a look at the issue themselves. Seer pointing out a potential issue in a PR before merging. That’s a huge lift.”
— Albert Pai, Co-founder & CTO
What’s next: Sentry inside Bolt
On the Sentry front, Bolt is building a native Sentry connector inside Bolt itself. If a bug is happening in production, a developer can pull the Sentry issue into Bolt, use it as context to prototype a fix, and ship a PR without leaving the environment.
In addition to error monitoring and Seer, the Bolt team is actively exploring session replay in Sentry to understand how errors surface to users at the UI level.
More broadly, the team sees observability as a discipline that requires deliberate choices as AI-generated code becomes a larger share of what gets shipped. AI agents can instrument code correctly when asked to, but the human decision to trace a workflow, set an alert, or instrument a transaction still matters. For engineering teams building with or for AI, that intentionality will only become more important.