Код 422 Unprocessable Entity означает, что сервер понял запрос — формат и синтаксис в порядке, — но не смог обработать его содержимое. Обычно так API отвечает на данные, не прошедшие валидацию: пустое обязательное поле, неверный формат даты, недопустимое значение. Для владельца сайта это сигнал: сервер работает, проблема — в данных запроса или в правилах их проверки.
Что означает код 422
422 — клиентская ошибка из группы 4xx. Изначально код появился в стандарте WebDAV (RFC 4918) под именем Unprocessable Entity, а сейчас закреплён в основном стандарте HTTP — RFC 9110 — как Unprocessable Content. Смысл: сервер распознал тип содержимого и корректно разобрал запрос, но выполнить его не может — данные семантически неверны.
Отличия от смежных кодов важны для диагностики. 400 Bad Request — сервер вообще не смог разобрать запрос: сломан синтаксис, повреждён JSON. 415 Unsupported Media Type — формат содержимого не поддерживается, например XML вместо JSON. 422 — формат понятен и синтаксис цел, но значения не проходят проверку. Место кода среди остальных — в полном списке кодов ответа HTTP.
Считает ли Tracker.ru 422 падением
Да. Успешной Tracker.ru считает только проверку с кодом 2xx. Ответ 422 помечает сайт недоступным, тип ошибки — «HTTP-ошибка», и вы получаете уведомление на email, в Telegram или по webhook. Проверки идут из нескольких регионов. Если 422 отдаёт основной адрес сайта — это почти всегда реальная проблема: обычная страница не должна требовать от посетителя данных. Периоды недоступности отражаются в статистике аптайма.
Типичные причины
- Ошибки валидации в API. Laravel, Ruby on Rails, FastAPI и другие фреймворки возвращают 422 вместе с JSON-описанием проблемных полей, когда данные запроса не прошли проверку: пустое обязательное поле, неверный e-mail, дата в недопустимом формате.
- На мониторинг поставлен API-эндпоинт. Адрес ждёт запрос с телом и параметрами, а проверка приходит без них. Каждая проверка получает 422, хотя сам сервис исправен.
- Изменение схемы API после релиза. В валидацию добавили обязательное поле, а клиенты и интеграции продолжают слать старый формат — запросы, которые раньше проходили, стали невалидными.
- Обработчик форм отклоняет отправку. Плагин формы или headless CMS возвращает 422 на пустые обязательные поля либо на срабатывание спам-проверки.
- Бизнес-правила приложения. JSON синтаксически корректен, но значения нарушают логику: отрицательная сумма заказа, дата бронирования в прошлом, дубликат e-mail при регистрации.
- WebDAV-сервер. В исходной области применения 422 означает: XML-тело разобрано, но выполнить содержащиеся в нём инструкции невозможно.
Что проверить владельцу сайта
- Откройте онлайн-проверку кода ответа своего сайта — она покажет реальный ответ сервера без кэша и расширений браузера.
- Прочитайте тело ответа: фреймворки обычно возвращают JSON со списком полей и причин, по которым валидация не прошла.
- Убедитесь, что на мониторинге правильный адрес: обычная страница, а не API-эндпоинт, требующий параметров. Если нужен именно эндпоинт — выбирайте тот, что отвечает 200 на простой GET-запрос.
- Сверьте формат запросов с документацией API: обязательные поля, типы значений, формат дат. Особенно если 422 начали получать интеграции и мобильные приложения.
- Проверьте последние изменения кода: не ужесточали ли правила валидации, не добавляли ли новые обязательные поля.
- Посмотрите логи приложения — в них видно, какие именно данные сервер отклонил и почему.
Как часто встречается 422 на практике
Код 422 встретился в выборке Tracker.ru 21 раз на десять с лишним миллионов проверок (по данным на июль 2026). Это ожидаемо: на мониторинг ставят страницы и главные адреса, которые отвечают на простой GET-запрос, а 422 — ответ на отправку данных в формы и API.
Частые вопросы
Почему мониторинг показывает 422, а в браузере сайт открывается?
Скорее всего, на мониторинге другой адрес. В браузере вы открываете обычную страницу, а проверяется API-эндпоинт, который без параметров отвечает 422. Сравните адрес монитора с адресом из браузера и проверьте оба через онлайн-проверку кода ответа.
Чем 422 отличается от 400 Bad Request?
400 — сервер не смог разобрать запрос: сломан синтаксис, повреждён JSON, некорректные заголовки. 422 — запрос разобран успешно, но содержимое не проходит проверку. Короче: 400 — «не понял», 422 — «понял, но принять не могу».
Является ли 422 ошибкой сервера?
Нет, это клиентская ошибка: сервер исправен и сознательно отклоняет невалидные данные. Для API такой ответ штатный. Проблема есть, если 422 получают корректные запросы — тогда ищите изменения в правилах валидации. Ошибки самого сервера — это группа 5xx, например 500 Internal Server Error.