Резюме
- Крупный инцидент Haiku 4.5 продолжался с 13:04:35 до 16:38:26 UTC 21 июля и после первоначального обновления о мониторинге вернулся в состояние «выявлено».
- Отдельная критическая запись о нескольких моделях сообщала, что с 15:28 до 16:26 UTC пользователи сталкивались с повышенным уровнем ошибок; страница инцидента оставалась открытой до 18:18.
- Ещё один критический инцидент нарушил создание документов и работу инструментов Claude с 17:40 до 18:03.
- Незначительный инцидент Opus 4.1 затронул API и Claude Code с 08:34 до 09:00 22 июля.
- Anthropic не опубликовал ни общей первопричины, ни числа затронутых пользователей, ни доли запросов, ни разбивки по регионам, ни вывода о компенсациях.
В 13:22 UTC Anthropic сообщил, что внедрил исправление для повышенного уровня ошибок в Haiku 4.5, и ведёт мониторинг результата. Через восемьдесят две минуты инцидент вернулся в состояние «выявлено». Этот возврат — самый полезный факт в насыщенной истории статусов: восстановление не удержалось.
Остальную часть операционного дня нельзя ответственно свести к одному сбою. Anthropic открыл другие записи с разными степенями серьёзности, компонентами и хронологиями. Вместе они показывают совокупность сервисов под повторяющимся давлением. По отдельности они сохраняют границу между фактами и диагнозом.
Haiku не прошёл первый тест на восстановление
Запись о Haiku 4.5 началась в 13:04:35 UTC и имела метку значительного воздействия. В списке компонентов были claude.ai, Console, API, Claude Code и Cowork. Anthropic перевёл статус в «выявлено» в 13:14, в «мониторинг» в 13:22, снова в «выявлено» в 14:44, снова в «мониторинг» в 15:30 и в «решено» в 16:38.
Возврат из мониторинга не объясняет, почему первое решение оказалось недостаточным. Но он доказывает, что сдвиг статуса в сторону улучшения не был устойчивым. Поэтому клиентам следует отличать статус провайдера от собственного синтетического показателя успешности и состояния очереди отложенных задач.
У записи о нескольких моделях две длительности
Критический инцидент для нескольких моделей открылся в 15:35. В последнем обновлении позже было указано, что с 15:28 до 16:26 пользователи сталкивались с повышенным уровнем ошибок. Сама страница не закрывалась до 18:18 — после выявления, мониторинга и устранения.
Это разные измерения. Первое — итоговое заявление провайдера об окне воздействия на пользователей. Второе — жизненный цикл записи об инциденте. Сообщать весь период, пока страница была открыта, как непрерывные ошибки у клиентов значило бы преувеличить сказанное Anthropic; сообщать только 58 минут значило бы упустить операционную неопределённость до закрытия.
В записи были указаны claude.ai, API, Claude Code и Cowork. Она пересекалась с Haiku, но совпадение по времени и общим компонентам не доказывает, что у обеих записей был один и тот же сбой.
Затем функции рабочих процессов стали отдельным инцидентом
В 17:40 Anthropic открыл ещё одну критическую запись о нарушении, затронувшем создание документов в claude.ai, Cowork Remote, Claude Code, Claude Code on the Web, Claude Tag и Claude Design. Статус несколько раз обновлялся как «выявлено», в 17:51 перешёл в «мониторинг», а в 18:03 — в «решено».
Эта запись короткая, но операционно самостоятельная. Модель может отвечать, пока не работает интерфейс оркестрации, удалённое окружение или документный процесс. Командам, которые полагаются на Claude в производственном процессе, нужны отдельные проверки для вывода модели, выполнения инструментов и окружающего рабочего пространства.
22 июля Opus 4.1 добавил четвёртую хронологию. Anthropic выявил повышенный уровень ошибок в 08:34, перешёл в режим мониторинга в 08:45 и закрыл незначительный инцидент API и Claude Code в 09:00.
Таксономия статусов может раздробить один рабочий день
Для клиента четыре страницы могут ощущаться как один ненадёжный день. Для инженерного анализа они остаются отдельными, пока Anthropic не представит общий механизм. Степени серьёзности также нельзя складывать: значительный инцидент модели, две критические записи и один незначительный инцидент не образуют математическую «суммарную серьёзность».
Anthropic не раскрыл ни числа пользователей, ни процента ошибок, ни географии, ни потери данных, ни подхода к компенсациям по SLA. Надёжный деловой механизм здесь более узкий. Повторяющаяся деградация моделей и рабочих процессов заставляет команды приостанавливать очереди, самостоятельно проверять восстановление и решать, можно ли перенести работу на другую модель или к другому провайдеру.
Полезный разбор инцидента сопоставил бы эти записи с общими зависимостями и объяснил, почему Haiku вернулся после первого состояния мониторинга. До тех пор дисциплинированный вывод остаётся процедурным: клиенты столкнулись с пересекающимися и последовательными сбоями на уровне моделей и рабочих процессов, но открытые данные подтверждают четыре хронологии, а не одну выдуманную первопричину.
