What happened
Bolt.new reported a bigger problem on June 22, 2026, starting at 14:33 UTC. It lasted about 15 minutes and was marked resolved at 14:48 UTC. Bolt.new has since confirmed the disruption is over.
Who this hits and how they usually find out
If you build or run something on Bolt.new, a 15-minute disruption can be easy to miss in the moment and painful to discover later. The typical shape is this: you are not watching the tool at 14:33 on a Monday afternoon, your workflow or app quietly stops doing what it should, and the first signal you get is a customer message asking why something is broken. By then the tool has already recovered, but the damage to trust is done. There is no alert inside Bolt.new that says “hey, we had a problem, check your work.” You find out the hard way.
Why this is especially rough without a technical background
If you are not an engineer, there is nothing to look at when something goes quiet. No log file, no red error on a screen, no stack trace. The work just stops moving. A form stops submitting, a workflow stops firing, an app goes blank. You might spend time wondering whether you broke something yourself before it even occurs to you to check whether the tool is the problem. That gap, between the moment the tool stops working and the moment you understand why, is where the stress lives.
Timeline
- 14:33 UTC, June 22, 2026 - Bolt.new reports a bigger problem begins.
- 14:48 UTC, June 22, 2026 - Bolt.new marks the disruption resolved.
- Total duration - about 15 minutes.
How a watcher catches this before your users do
Bolt.new publishes a public status page. NoCrash reads that page every minute. The moment Bolt.new flips its own status from working to having trouble, NoCrash sends you a plain-language message telling you what is wrong, in words you can act on, without you having to go check anything yourself.
That matters because the alternative is silence. You are not refreshing Bolt.new’s status page every minute. Nobody is. So a 15-minute disruption can pass entirely unnoticed until a customer surfaces it.
NoCrash also watches the things you ship: your n8n workflows through an API token, and your app through a URL you give it or a small JS snippet. So if something goes quiet on your own side, that surfaces too, sitting next to everything else you build on. The picture is in one place, in plain English.
What NoCrash does not do: it does not find the outage before Bolt.new’s own status page reports it. It reads what Bolt.new publishes, as fast as it publishes it. That is the honest version of what a watcher can do.
The authoritative account
For the official record of this disruption, go to Bolt.new’s status page: https://status.bolt.new/proxy/status.bolt.new