Live data from Hacker News

Claude outage – Resolved

status.claude.com

31–40 of 167 posts

Re: Claude outage – Resolved

#31

Demand > supply. It's impressive that customers have not migrated en masse to other providers, given the frequency of these outages. Perhaps switching costs are greater than some would believe. Or, qualitative differences between models continue to exist, despite matching on public benchmarks.

If only every outage was due to “demand”.

Do you really think it’s a coincidence claude outages always happen when US and EU workdays overlap?

Anthropic is a trillion dollar company and employs way more skilled high-paid engineers than you are btw, you really think it’s a systems issue not capacity

Re: Claude outage – Resolved

#32
post #2

Damn, I'll have to think for myself now...

Haha, I was more like: I have to think alone now. But I get the feeling, as someone who has always made a point of using only foss on my own machines (own the means of production so to say), this is a weird time. I don't like it, I hope soon local models get good. But in the mean time... We have this... dependency.

Re: Claude outage – Resolved

#33
post #14

During each forced workflow interruption I look for alternatives. No matter if I can't use the product due to a server outage or due to their weird quota limitations. This can't be good for retention numbers. Old-school VCs would've ripped them apart in the air. Where did all the expertise go?

Good day to try omp and GLM 5.3

Re: Claude outage – Resolved

#34
post #24

Demand > supply. It's impressive that customers have not migrated en masse to other providers, given the frequency of these outages. Perhaps switching costs are greater than some would believe. Or, qualitative differences between models continue to exist, despite matching on public benchmarks.

That's quite a reach. More likely someone merged and deployed their vibe-coded PR and is now figuring out how to bring the service back up. If there's a lot of demand for rollercoaster rides, the rollercoaster will not stop operating; instead the queue of people in front of it will increase. It's not like a bridge or elevator where we have a certain number of people that can use it, and if one more person joins, the…

> instead the queue of people in front of it will increase.

This can ultimately result in the system breaking. I don't think Anthropic engineers are that much worse than their peers, such that they are 10x more prone to causing outages due to bad deployments.

Re: Claude outage – Resolved

#36
post #9

Setting aside annoyance at the downtime, I'm really curious about the reasons for the failures, because I have to imagine there are some novel failure modes when serving these giant models that I haven't experienced with the kind of work I've done. Anyone out there working in this space who can elucidate us on interesting failure scenarios unique to the space?

It's (mostly?) compute shortages. Right now it seems there is an issue in the SpaceX datacentres, so they will have less compute than normal.

Re: Claude outage – Resolved

#37
The interesting thing is they changed default mode for Claude code to auto mode and auto mode uses sonnet to decide whether the command is safe or not. With their Sonnet model outage, the entire thing stopped working.

here is the error it was throwing:

> Error: claude-sonnet-5[1m] is temporarily unavailable (overloaded), so auto mode cannot determine the safety of Edit right now. Wait a moment and then try this action again. If it keeps failing, continue with other tasks that don't require this action and come back to it later. Note: reading files, searching code, and other read-only operations do not require the classifier and can still be used.

Re: Claude outage – Resolved

#39

Grok models are struggling too: https://status.x.ai/ reply Looks like trouble in the SpaceX datacenters.

What could go wrong with building them as fast as physically possible?

What works for me to avoid these problems is not scaling.
Post reply on HN