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 explanation, 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. The question is not whether it will happen again, it is how quickly you find out when it does.

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

NoCrash reads Bolt.new's public status page every minute. Within a minute of Bolt.new reporting trouble, NoCrash sends you a plain-language message. You do not have to check the status page yourself or wait for a customer to tell you. That one-minute loop is the difference between getting ahead of it and explaining yourself after the fact.

Was my project data affected?

This postmortem covers what Bolt.new reported publicly. For questions about specific projects or data, contact Bolt.new support directly or check https://status.bolt.new/proxy/status.bolt.new for any additional detail they have published.

Bolt.new outage on July 22, 2026: what happened and what to watch for

On July 22, 2026, Bolt.new reported a bigger problem starting at 13:45 UTC. It lasted about one hour and was resolved at 15:08 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, you probably found out the wrong way: a customer messaged you, a collaborator said something felt broken, or you noticed a project just was not responding. Bolt.new does not send you a personal alert when its own service has trouble. You are not watching a status page every few minutes. Nobody is. So the gap between “something went wrong” and “I know something went wrong” is filled by whoever happens to bump into the problem first, and that is usually not you.

Why this is especially rough if you are not an engineer

There is no error message that makes sense. There is no log to open. The work just stops, quietly, and you have no way to tell if it is your project, your browser, your internet connection, or the platform itself. You spend the first ten minutes ruling out things that are not the problem. By the time you land on “it might be Bolt.new,” your customer has already sent a second message. That gap, between the outage starting and you knowing about it, is where trust gets spent.

Timeline

13:45 UTC - Bolt.new reports a bigger problem begins.
15:08 UTC - Bolt.new reports the issue is resolved.
Total duration - about 1 hour.

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 is broken” into “I got a calm heads-up first, and I can tell my customer before they ask.”

It also watches the things you ship. If you have n8n workflows running, NoCrash watches those too. If you give it a URL or add a small JS snippet to your app, it watches that as well. So a quiet stall on your own side surfaces alongside anything happening at the platform level, all in one place.

To be clear about what it does not do: NoCrash reads the tool’s own public status page. It does not find the outage before Bolt.new reports it. It catches the report within a minute of Bolt.new making it, and tells you in plain English.

The authoritative account

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