HTTP status codes — это трёхзначные числа, которые сервер отправляет в ответ на каждый запрос. Для большинства разработчиков это просто 200 OK и изредка 404. Но если вы отвечаете за uptime, каждый код — сигнал, по которому нужно принимать решения. 502 в три часа ночи и 503 в три часа ночи — это два совершенно разных инцидента с разными runbook'ами.
Ниже — все HTTP status codes с точки зрения мониторинга и эксплуатации: какой код что значит, когда бить тревогу, а когда это нормальное поведение. Каждый код — с runbook'ом и практическими рекомендациями.
Как читать HTTP status codes
Первая цифра определяет класс ответа. Это самое важное, что нужно запомнить:
1xx — Informational. Промежуточные ответы. Сервер принял запрос и продолжает обработку. В мониторинге встречаются редко.
2xx — Success. Всё хорошо. Запрос принят, обработан, ответ отдан. Это то, что ваш мониторинг хочет видеть.
3xx — Redirection. Ресурс переехал. Клиент должен сделать ещё один запрос. Не ошибка, но может быть проблемой для производительности.
4xx — Client Error. Проблема на стороне клиента. Неправильный URL, нет авторизации, ресурс не найден. В мониторинге означает, что ваш endpoint жив, но что-то не так с запросом.
5xx — Server Error. Проблема на стороне сервера. Это red alert для мониторинга. Ваше приложение падает, перегружено или неправильно сконфигурировано.
2xx — коды успеха
200 OK
Самый желанный код в мониторинге. Запрос обработан, ответ получен, всё работает. Когда вы настраиваете HTTP-мониторинг, именно 200 OK — ваш главный индикатор здоровья.
Но есть нюанс: 200 OK не гарантирует, что приложение работает корректно. Страница может вернуть 200 с пустым телом или с сообщением об ошибке внутри HTML. Поэтому продвинутые мониторинг-системы поддерживают keyword checks — проверку содержимого ответа, а не только status code.
201 Created
Ресурс создан. Типично для POST-запросов к API. Если вы мониторите API-endpoint для создания записей и получаете 201 — значит, write path работает. Полезно для мониторинга API.
204 No Content
Запрос успешен, но тела ответа нет. Частый ответ для DELETE-запросов и health check endpoints. Если ваш /health возвращает 204 вместо 200, убедитесь, что мониторинг принимает этот код как "success".
3xx — редиректы
301 Moved Permanently
Ресурс навсегда переехал. Браузеры кэшируют 301 агрессивно — если вы ошибочно поставили 301, откатить будет больно. В контексте мониторинга: если ваш сайт начал отдавать 301 вместо 200 на главный URL — проверяйте nginx/Caddy конфигурацию. Часто это симптом неправильного HTTP→HTTPS редиректа или www→non-www.
302 Found / 307 Temporary Redirect
Временный редирект. Разница между 302 и 307: при 307 метод запроса сохраняется (POST остаётся POST), при 302 — метод может измениться на GET. Для мониторинга обычно неважно, но если вы проверяете API endpoints с POST-запросами, 307 — корректнее.
308 Permanent Redirect
То же, что 301, но метод запроса сохраняется. Используется реже, но набирает популярность в REST API. В мониторинге обрабатывается аналогично 301.
Совет по мониторингу: большинство инструментов по умолчанию следуют редиректам и проверяют финальный status code. Это удобно, но маскирует проблемы: если ваш сайт внезапно начал выдавать цепочку из 5 редиректов — время ответа вырастет, а мониторинг покажет зелёный 200. Настройте отслеживание response time с порогами, чтобы ловить такие деградации.
4xx — ошибки клиента
400 Bad Request
Сервер не понял запрос. Чаще всего — невалидный JSON в теле или отсутствующий обязательный параметр. Если ваш health check endpoint начинает отдавать 400, проверьте, не поменялся ли формат запроса после деплоя.
401 Unauthorized
Нет аутентификации. Самая частая причина ложных алертов в мониторинге: срок действия API-ключа или JWT-токена истёк, и проверки начинают падать с 401. Если мониторите защищённые endpoints — убедитесь, что credentials не протухнут. AtomPing поддерживает Bearer tokens и Basic Auth прямо в настройках HTTP-проверок.
403 Forbidden
Аутентификация есть, но доступа нет. В мониторинге часто означает: WAF заблокировал IP вашего мониторинга, или geo-restriction отсекла регион проверки. Если мониторите из нескольких регионов и получаете 403 только из одного — скорее всего, проблема с региональным файерволом.
404 Not Found
Ресурс не найден. Второй по узнаваемости код после 200. Для мониторинга 404 — тревожный сигнал: кто-то удалил endpoint, переименовал URL или сломал routing после деплоя. Настройте keyword check на важных страницах — если вместо контента приходит "Page Not Found", мониторинг поймает это даже при 200 OK (некоторые фреймворки отдают кастомную 404-страницу с кодом 200).
429 Too Many Requests
Rate limit. Вы отправляете слишком много запросов. В мониторинге это палка о двух концах: если ваш мониторинг сам получает 429 — уменьшите частоту проверок. Если ваши пользователи получают 429 — вы слишком жёстко ограничиваете трафик. Заголовок Retry-After подскажет, когда повторить запрос.
5xx — ошибки сервера (red alert)
Пятисотки — это то, ради чего существует мониторинг. Каждый 5xx код означает: ваш сервер не смог обработать валидный запрос. Пользователи видят ошибку, и вы теряете деньги, доверие, или и то, и другое.
500 Internal Server Error
Универсальный "что-то сломалось". Необработанное исключение в коде, ошибка базы данных, переполнение памяти — всё это часто приводит к 500. Это самый частый 5xx код и главный триггер для incident management. Если видите 500 — первым делом проверяйте логи приложения.
502 Bad Gateway
Прокси (nginx, Caddy, AWS ALB) получил невалидный ответ от upstream. На практике это почти всегда означает одно из двух: приложение упало (процесс не запущен), или приложение зависло и не ответило вовремя. 502 — один из самых частых кодов при деплое: новый контейнер ещё не поднялся, а старый уже убит.
Runbook для 502: Проверьте, что процесс приложения запущен. Проверьте порт — слушает ли приложение на том порту, куда проксирует nginx. Проверьте логи nginx на строку "upstream prematurely closed connection". Если 502 появляется после деплоя — добавьте health check в оркестратор, чтобы трафик шёл только на готовые контейнеры.
503 Service Unavailable
Сервер временно не может обработать запрос. В отличие от 502, здесь сервер жив и осознанно отвечает "я занят". Типичные сценарии: плановое обслуживание, перегрузка (все worker'ы заняты), circuit breaker сработал.
Если вы настраиваете maintenance mode — отдавайте именно 503, а не 200 с текстом "на обслуживании". Мониторинг корректно распознает 503 как downtime и посчитает его в SLA отчёте.
504 Gateway Timeout
Прокси не дождался ответа от upstream. Разница с 502: при 502 ответ пришёл, но невалидный. При 504 — ответа не было вовсе за отведённое время. 504 обычно означает: база данных зависла на тяжёлом запросе, внешний API не отвечает, или у вас deadlock.
Runbook для 504: Увеличьте proxy_read_timeout в nginx как временное решение. Затем ищите медленный запрос: slow query log в PostgreSQL, APM traces, или логи с временем ответа. 504 часто коррелирует с ростом нагрузки — проверьте CPU и memory на серверах.
520–530 (Cloudflare-специфичные)
Если вы используете Cloudflare, то увидите коды 520-530. Это не стандартные HTTP-коды — Cloudflare ввёл их для более точной диагностики. 520 означает "unknown error" (origin вернул что-то непонятное), 521 — "web server is down" (origin не принимает соединения), 522 — "connection timed out" (TCP-подключение к origin не устанавливается), 523 — "origin is unreachable", 524 — "a timeout occurred" (origin подключился, но не ответил за 100 секунд).
Эти коды особенно важны при мониторинге из внешних локаций: ваш uptime monitor увидит код Cloudflare, а не код вашего origin. Не путайте 522 (проблема с TCP до origin) с 504 (проблема с HTTP timeout).
Как настроить мониторинг HTTP status codes
Просто проверять "сайт отвечает" — недостаточно. Вот что стоит мониторить:
1. Ожидаемый status code. Для каждого endpoint укажите, какой код считать нормой. Главная страница — 200. API health — 200 или 204. Redirect — 301 или 302.
2. Keyword в теле ответа. Status code 200 + пустое тело = проблема. Добавьте проверку на ключевое слово: название компании, JSON-поле "status":"ok", или элемент DOM.
3. Response time пороги. Если время ответа выросло с 200ms до 3000ms, а код всё ещё 200 — это деградация, которую нужно ловить. Настройте alert на response time > 2x от нормы.
4. SSL certificate validity. Протухший SSL-сертификат может выглядеть как сбой подключения, а не как HTTP-ошибка. SSL мониторинг предупредит заранее.
Полная таблица HTTP status codes
Для быстрого reference — полная таблица с описанием и уровнем критичности для мониторинга.
| Code | Name | Alert level |
|---|---|---|
| 200 | OK | Healthy |
| 201 | Created | Healthy |
| 204 | No Content | Healthy |
| 301 | Moved Permanently | Warning |
| 302 | Found (Temporary) | Warning |
| 400 | Bad Request | Warning |
| 401 | Unauthorized | High |
| 403 | Forbidden | High |
| 404 | Not Found | High |
| 429 | Too Many Requests | Warning |
| 500 | Internal Server Error | Critical |
| 502 | Bad Gateway | Critical |
| 503 | Service Unavailable | Critical |
| 504 | Gateway Timeout | Critical |
Типичные ошибки при мониторинге HTTP-кодов
Мониторить только главную страницу. Главная может быть на CDN и работать даже при мёртвом backend. Добавьте проверки на API endpoints, login page, checkout flow — места, которые зависят от базы данных и backend-сервисов.
Игнорировать 3xx. Один редирект — нормально. Цепочка из 5 редиректов — потеря 2-3 секунд загрузки и повод разобраться. Некоторые CDN создают redirect loops при неправильной настройке — мониторьте это.
Не проверять тело ответа. 200 OK с текстом "Database connection failed" — это не success. Используйте keyword monitoring для проверки содержимого.
Один регион мониторинга. Ваш сайт может отдавать 200 из Европы и 503 из Азии. Мульти-региональный мониторинг ловит такие проблемы до того, как пользователи начнут жаловаться.
FAQ
What is the most common HTTP status code?
200 OK is by far the most common — it means the request was successful and the server returned the expected content. In monitoring, you'll see 200 on 99%+ of checks when everything is working normally.
Is a 301 redirect bad for SEO?
No. A 301 (permanent redirect) passes nearly all link equity to the new URL. It's the correct way to redirect pages permanently. A 302 (temporary redirect) doesn't pass link equity, so use it only for genuinely temporary moves.
What's the difference between 401 and 403?
401 Unauthorized means the server doesn't know who you are — you need to authenticate. 403 Forbidden means the server knows who you are but you don't have permission to access that resource. Think of 401 as 'show me your badge' and 403 as 'your badge doesn't open this door.'
Should I monitor for specific HTTP status codes?
Yes. Don't just check if your site responds — validate the status code. A page returning 200 with an error message in the body is a silent failure. Most monitoring tools, including AtomPing, let you assert expected status codes and even check response content with keyword monitoring.
What does 502 Bad Gateway mean in practice?
A 502 means a server acting as a gateway (like nginx or a load balancer) received an invalid response from the upstream server. In practice, this usually means your application server (Node.js, Django, Rails) crashed or is overloaded, and the reverse proxy can't get a valid response from it.
How often do 5xx errors happen on healthy sites?
On a healthy production site, 5xx error rate should be under 0.1% of all requests. If you're seeing more than 1% 5xx responses consistently, something is wrong — either with your app, your infrastructure, or your traffic patterns.