What actually caused this?

Bolt.new has not published a detailed cause for this disruption. Their status page noted it as a bigger problem that has since 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. The question is not whether it will happen again but whether you will hear about it before your users do.

Was my app or my workflows affected?

That depends on what you were running and when. If you had workflows or an app running on Bolt.new between 03:35 and 03:52 UTC on July 9, it is worth checking whether anything stalled or produced unexpected results during that window.

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

NoCrash reads Bolt.new's public status page every minute and tells you in plain language within a minute of Bolt.new's own report. You get a calm heads-up in one place, rather than a confused message from a customer.

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

What happened

Bolt.new reported a bigger problem starting at 03:35 UTC on July 9, 2026. It lasted about 16 minutes and was marked resolved at 03:52 UTC. Bolt.new has since confirmed the disruption is over.

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

If you build on Bolt.new, a short outage like this often goes completely unnoticed until someone else notices for you. That someone is usually a paying customer. They try to use something you built, it does not work, and they send you a message. By the time you read it, the tool has already recovered, but the damage to trust is done. You are left explaining something you did not even know had happened.

That gap, between the moment the tool stopped working and the moment you heard about it, is the whole problem. It is not a technical failure you could have prevented. It is a visibility gap.

Why this is especially rough if you are not an engineer

There is no error on your screen. Nothing in Bolt.new sends you a personal alert when its own service has trouble. The work just quietly stops moving. If you have automations or workflows running on top of it, they stall without a word. You find out when a customer complains, or when you happen to check and notice something looks wrong. At that point you are already behind, already apologizing, already guessing at what broke and when.

That is the shape of most quiet outages. Not dramatic. Just silent.

Timeline

03:35 UTC, July 9, 2026 - Bolt.new reports a bigger problem begins.
03:52 UTC, July 9, 2026 - Bolt.new marks the disruption resolved.
Total duration - about 16 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 plain English, sitting next to everything else you build on. You do not have to check anything. You do not have to know what a status page is or where to find it.

For a 16-minute disruption like this one, that means you could have known within a minute of Bolt.new’s own report, instead of hearing it from a customer. NoCrash also watches the things you ship: your n8n workflows through an API token, and your app through a URL or a small JS snippet you add. So if something goes quiet on your own side, that surfaces too.

To be clear about what this is: NoCrash reads what Bolt.new publishes about itself. It does not find problems before Bolt.new does. It just makes sure you hear about it in plain language, fast, in one place.

The authoritative account

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