What actually caused this?

Bolt.new has not published a detailed cause for this outage. For the most current explanation, check the official status page at [https://status.bolt.new/proxy/status.bolt.new](https://status.bolt.new/proxy/status.bolt.new).

Could this happen again?

Yes. Any tool can have another outage. That is not a criticism of Bolt.new specifically, it is just true of every service. The question is whether you find out from a customer or from a calm heads-up you got first.

How do I find out sooner next time something like this breaks?

NoCrash reads Bolt.new's public status page every minute and sends you a plain-language message within a minute of Bolt.new's own report. You do not have to check anything yourself. It sits next to all the other tools you build on, so one place covers the whole picture.

Was my own app or workflow affected?

That depends on what you were running at the time. If your app or n8n workflows touch Bolt.new, they were likely affected during the three-hour window. NoCrash watches your workflows and your app directly, so a stall on your own side shows up there too, separate from what Bolt.new's status page says.

Bolt.new outage on July 29, 2026: what happened and what to know

What happened

Bolt.new had a significant problem starting at 03:04 UTC on July 29, 2026. It lasted about three hours and was resolved at 07:01 UTC. Bolt.new has since confirmed the issue is resolved. The cause has not been published in detail.

Who this kind of outage hits, and how they usually find out

If you build on Bolt.new, you are probably not watching its status page at three in the morning. Most people find out something went wrong when a customer writes in, or when they sit down to work and notice a project that should have moved has not. By then the outage is already over, but the damage, a confused customer, a missed deadline, a half-finished build, is already done. The gap between “the tool stopped working” and “I found out” is usually measured in hours, not minutes.

Why this is especially rough if you are not an engineer

There is no error on your screen. Nothing crashes visibly. The work just stops moving, quietly, and you have no log to read and no alert to check. If you are running automations or building something for a client, the first signal is often an unhappy message from someone who expected a result and did not get one. That is a bad way to find out. It puts you in the position of explaining something you did not know was happening.

Timeline

03:04 UTC, July 29, 2026 - Bolt.new begins experiencing a bigger problem.
03:04 to 07:01 UTC - The disruption runs for about three hours.
07:01 UTC, July 29, 2026 - Bolt.new recovers and confirms the issue is resolved.

How a watcher catches this before your users do

NoCrash reads Bolt.new’s public status page every minute. The moment that page flips from working to having trouble, NoCrash sends you a plain-language message, in words you can act on, without you having to go looking. That is the difference between hearing it from a customer and hearing it first yourself, with enough time to set an expectation or pause work before anyone notices.

It also watches the things you ship. If you have n8n workflows, NoCrash watches those too. If you have an app or a page, you can give NoCrash a URL or drop in a small JS snippet and it will watch that as well. So if the problem is on your side rather than Bolt.new’s side, that surfaces too. NoCrash does not find the outage before Bolt.new’s own status page does. It reads that page and tells you within a minute of Bolt.new’s own report, in one place, alongside everything else you build on.

The authoritative account

For the official record of this outage, go to https://status.bolt.new/proxy/status.bolt.new.