What actually caused this?

Bolt.new has not published a detailed cause for this outage. Their status page confirms it has been resolved. For any further detail, check https://status.bolt.new/proxy/status.bolt.new directly.

Could this happen again?

Yes. Any tool can have another outage. Bolt.new is not unusual in that regard. The question is not whether it will happen again but how quickly you find out when it does.

How do I find out the 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 manually or wait for a customer to tell you.

What if the problem is on my side, not Bolt.new's?

NoCrash also watches your n8n workflows and your app through a URL or a small JS snippet. If your own side goes quiet, that shows up in the same place, so you are not left wondering which layer the problem is in.

Bolt.new had a bigger problem on July 23, 2026

What happened

Bolt.new reported a bigger problem starting at 00:00 UTC on July 23, 2026. The disruption lasted about 12 minutes and was marked resolved at 00:12 UTC. Bolt.new has since confirmed the issue is resolved.

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

If you build on Bolt.new, a short disruption like this can stop a project mid-session, break a workflow that runs on a schedule, or leave a customer staring at something that simply will not load. The hard part is that nothing inside the tool sends you a message. You find out when a customer emails you, or when you happen to check in yourself and notice something looks wrong. By then the disruption may already be over, but the customer’s impression of your product is not.

Why this is rough if you are not an engineer

There are no logs to read. There is no error on your screen. The work just stops moving, quietly, and the first signal is usually an unhappy person on the other end. An engineer can SSH into a server and look for clues. A solo operator or a non-technical founder has none of that. You are left guessing whether the problem is your app, your workflow, or the tool underneath it all. That uncertainty is its own kind of stress, and it costs time you do not have.

Timeline

00:00 UTC, July 23, 2026 - Bolt.new’s public status page reported a bigger problem.
00:12 UTC, July 23, 2026 - Bolt.new marked the issue resolved.
Total duration - about 12 minutes.

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 turns “my customer told me something was broken” into “I got a calm heads-up within a minute of Bolt.new’s own report.”

It also watches the things you ship. If you have n8n workflows, NoCrash watches those through your API token. If you have an app, it watches it through a URL you give it or a small JS snippet you drop in. So if the trouble is on your side rather than Bolt.new’s side, that surfaces too, in the same place.

To be clear about what it does not do: NoCrash does not find outages before Bolt.new’s own status page does. It reads that page and tells you fast, in plain English, alongside everything else you build on.

The authoritative account

For the official record of this outage, see Bolt.new’s own status page at https://status.bolt.new/proxy/status.bolt.new.

Bolt.new had a bigger problem on July 23, 2026 - resolved in 12 minutes