OpenAI API status — это публичная страница status.openai.com, где платформа показывает состояние своих сервисов и историю инцидентов, но решение о том, что делать приложению в момент сбоя, принимает ваш код. Страница отвечает на вопрос «болеет ли платформа», а ответ API с кодом ошибки показывает, дошёл ли до неё именно ваш запрос и чем встретили. Если ответ модели стоит на пути пользователя, связку двух источников придётся строить заранее; разовый скрипт проще перезапустить.
Где смотреть статус
Статус платформы читают на status.openai.com, причину отказа конкретного вызова читают в коде ответа, а автоматическое решение о повторе или обходе принимает ваш сервис по заранее записанному правилу.
Страница статуса разбита по продуктам: на ней отдельными блоками показаны API, ChatGPT, Codex и другие продукты, у каждого свои компоненты и своя история. Из этого следует практическое правило. Сообщение об инциденте в ChatGPT молчит о доступности API, и наоборот, поэтому ориентироваться нужно на блок, который относится к тому, что вызывает ваш код. Кнопка подписки на обновления и архив инцидентов лежат на той же странице, способы доставки уведомлений открываются в её интерфейсе, и выбирает их ответственный за сервис.
Условный пример: в личном кабинете клиента интернет-магазина стоит помощник, который по обращению готовит черновик ответа оператору. Оператор видит черновик и отправляет его после проверки. Пока платформа здорова, помощник экономит оператору время на типовых вопросах. В момент сбоя главная задача другая: оператор должен продолжить работу без черновика и без загадочных окон с ошибкой.
Подписку на статус оформите на общий адрес команды, вместо личной почты одного разработчика: уведомление, пришедшее человеку в отпуске, остаётся без реакции. Ключ и доступ к проекту разобраны в статье про выдачу ключа и управление доступом, а здесь предполагается, что вызовы уже работают.
Инцидент или ошибка
Документация OpenAI по кодам ошибок различает причины, и приложению полезно различать их в том же виде. Отказ из-за ключа лечится заменой ключа, отказ из-за лимита лечится паузой или сменой лимитов, а отказ из-за сервера лечится ожиданием и обходом.
| Код ответа | Что означает по документации | Чья проблема | Действие приложения |
|---|---|---|---|
| 401 | Неверный или отозванный ключ, либо адрес вне разрешённого списка | Ваша настройка | Остановить повторы, поднять тревогу владельцу ключа |
| 429, частота | Слишком частые запросы | Ваша нагрузка | Повтор с нарастающей паузой, учёт заголовка Retry-After |
| 429, лимит расходов | Достигнут лимит расходов организации или проекта | Ваши настройки проекта | Повтор бесполезен: сообщить ответственному, включить запасной режим |
| 500 | Ошибка на стороне платформы | Платформа | Повтор после короткой паузы, проверка страницы статуса |
| 503 | Модель временно перегружена | Платформа | Выдержать паузу из Retry-After, затем запасной маршрут |
Особенно важна пара 429. Один и тот же код прячет две разные ситуации, и повтор помогает только в первой: пока вы превышаете частоту, пауза решает дело, а упёршись в лимит расходов, вы будете получать отказ снова и снова. Приложение разбирает тело ошибки и по нему выбирает ветку, опираясь на текст причины рядом с числом в статусе.
Для серверных ответов документация советует схожую линию: при коде 500 повторить после короткой паузы и заглянуть на страницу статуса, если ошибка держится, а при коде 503 выдержать указанную паузу. Приложению остаётся записать обе реакции в код, чтобы они срабатывали без участия человека в три часа ночи.
Правило выбора такое: клиентская ошибка в диапазоне 4xx без 429 повторять незачем, потому что тот же запрос даст тот же отказ. Серверные 5xx и 429 по частоте допускают ограниченное число повторов. Если страница статуса одновременно показывает инцидент в блоке API, вы получаете подтверждение, что дело в платформе, и ставите заметку в журнал со ссылкой на запись об инциденте.
Повтор и запасной путь
Повтор запроса оформляют по нескольким правилам. Пауза растёт от попытки к попытке и получает небольшую случайную добавку, чтобы десятки одновременных запросов вернулись на платформу вразнобой. Если в ответе есть заголовок Retry-After, его значение главнее собственной арифметики. Число попыток ограничено, а общее время ожидания укладывается в терпение пользователя: оператору интернет-магазина полезнее увидеть пустое поле и продолжить, чем смотреть на крутящийся индикатор.
Запасной путь придумывают для каждой функции отдельно. Для помощника оператора лучший запас — рабочий процесс без модели: форма ответа остаётся пустой, оператор пишет сам, а заявка помечается в очереди как обработанная вручную. Для задач, которым необходим собственный контур, возможна резервная модель с открытыми весами на вашем сервере; ей посвящена статья про подключение локальной модели к своим сервисам. Цена такого запаса — отдельная эксплуатация, и оправдан он там, где простой дороже содержания второго контура.
Переключайтесь на запасной путь автоматически только по узким признакам: серия серверных ошибок подряд либо исчерпанное время ожидания. Возврат на основной маршрут также делают осторожно, одним запросом-пробником, а затем плавным увеличением доли. Так приложение избегает качелей, когда каждый всплеск ошибок переключает всех пользователей туда и обратно.
Что увидит ваш пользователь, если ответ модели недоступен?
Журнал вызовов
Без журнала различие между инцидентом платформы и ошибкой своего запроса остаётся догадкой. Для каждого вызова записывайте время, имя окружения, идентификатор модели, код ответа, тип ошибки из тела, номер попытки, итоговое решение приложения и задержку. Тексты обращений, ключи и ответы модели в запись исключены: для диагностики хватает технических полей и ссылки на внутреннюю карточку.
Из таких записей собираются два простых показателя: доля вызовов с ошибкой по кодам и доля обращений, ушедших в запасной режим. Когда доля 5xx растёт и страница статуса отмечает инцидент, у вас есть объяснение для руководителя. Когда доля 401 или 429 по расходам растёт при чистой странице статуса, причину ищут в своих настройках, и тревога уходит владельцу проекта, а чат платформы можно оставить в покое.
Заголовки с данными о лимитах, такие как x-ratelimit-remaining-requests и x-ratelimit-remaining-tokens, описаны в руководстве по лимитам запросов. Сохраняйте их значения в журнале: по ним видно приближение к потолку раньше, чем придёт первый отказ. Смысл замеров с задержкой подробнее объясняет термин задержка p95.
Допуск в работу
Перед запуском проведите учебную остановку. Она показывает, что приложение ведёт себя по записанным правилам, без опоры на надежды разработчика.
- Сымитируйте отказ: подставьте отозванный тестовый ключ и убедитесь, что повторов нет, а владелец ключа получил сообщение.
- Сымитируйте перегрузку: заставьте тестовый клиент вернуть 503 и проверьте паузу, число попыток и переход на запасной режим.
- Откройте страницу статуса и сверьте, на какой блок вы подписаны и кому приходят уведомления.
- Проверьте, что оператор в запасном режиме получает рабочую форму, а заявка остаётся в очереди с понятной отметкой.
- Запишите порог тревоги и владельца решения в рабочую инструкцию команды.
После учений ведите короткий регламент: кто читает уведомления статуса, кто отвечает за ключ и лимиты, кто решает о ручном режиме для всех пользователей. Регламент уместится на одной странице, а проверять его раз в квартал дешевле, чем разбираться с одним настоящим сбоем без него. Когда нужен проектный маршрут с журналом, тревогами и приёмкой, посмотрите, как мы ведём внедрение ИИ в рабочие сервисы.
Запишите на листе три строки: кто получает уведомление статуса, при какой серии ошибок включается ручной режим, кто возвращает основной маршрут. Затем проведите одну учебную остановку с тестовым ключом. Показателем возьмите время, за которое оператор переходит на ручную работу без вопросов к разработчику.