HTTP-коди стану пояснені: що 200, 404, 502 означають для моніторингу

Коротко: HTTP-код стану - тризначне число, яким сервер відповідає на кожен запит. Група каже категорію: 2xx = OK, 3xx = redirect, 4xx = помилка клієнта, 5xx = помилка сервера. З точки зору uptime-моніторингу нас цікавлять перш за все аномалії 5xx та 4xx.

Категорії відповідей

• 1xx Informational - перехідні відповіді, клієнт зазвичай не помічає.
• 2xx Success - запит пройшов успішно. 200 OK - default.
• 3xx Redirection - клієнт має йти в інше місце. 301 permanent, 302 тимчасовий.
• 4xx Client errors - клієнт надіслав щось погане. 404, 401, 403, 429.
• 5xx Server errors - сервер впав. 500, 502, 503, 504.

2xx: успіх

200 OK - стандартна OK-відповідь. Це «healthy»-стан, для якого моніторите.

201 Created - типово відповідь на POST, що створив новий resource. Клієнти API очікують.

204 No Content - успіх, але сервер не має що повернути. DELETE endpoint'и часто використовують.

206 Partial Content - сервер повернув лише частину (range request). При стрімінгу відео або resumable download.

3xx: перенаправлення

301 Moved Permanently - URL змінився назавжди. Google переносить SEO equity на новий URL. Використовувати при міграції домену, переході з HTTP на HTTPS, переході на www/non-www.

302 Found / 307 Temporary Redirect - тимчасове перенаправлення. Google не переносить ranking. Використовувати при A/B тестуванні, обслуговуванні або коли URL повернеться з часом.

308 Permanent Redirect - як 301, але зберігає HTTP-метод (POST залишається POST). 301 може клієнт перетворити на GET.

304 Not Modified - у клієнта є cache, сервер підтверджує, що контент не змінився. Економить bandwidth.

Для моніторингу: При перевірці 3xx відповідей налаштуйте, чи має monitor слідувати redirect (follow) або вважати redirect помилкою. Деякі DNS hijack атаки проявляються як несподівані 302.

4xx: помилка на стороні клієнта

400 Bad Request - синтаксична помилка в запиті. Malformed JSON, відсутній header тощо.

401 Unauthorized - відсутні або погані credentials. Клієнт має аутентифікуватися.

403 Forbidden - клієнт аутентифікований, але не має прав. Обережно: деякі сервери повертають 403 замість 401 з міркувань безпеки (нерозкриття існування ресурсу).

404 Not Found - URL не існує. Для моніторингу не важливо, для SEO так (витікає link equity).

405 Method Not Allowed - URL існує, але не приймає даний метод (наприклад, POST на endpoint, що очікує GET).

408 Request Timeout - сервер чекав на запит надто довго і закрив з'єднання.

409 Conflict - запит у конфлікті з поточним станом (наприклад, update версії, яка вже не актуальна).

410 Gone - resource видалений назавжди. Краще, ніж 404 для Google (сигнал не намагатися переіндексувати).

422 Unprocessable Entity - запит синтаксично OK, але містить семантично невалідні дані (failed validation).

429 Too Many Requests - rate limit. Клієнт має сповільнитися. Сервер типово додає header Retry-After.

5xx: помилка на стороні сервера

500 Internal Server Error - генерична помилка. Backend кинув exception, який програма не зловила. Завжди тривога для моніторингу.

501 Not Implemented - сервер не знає HTTP-метод (наприклад, старий сервер не підтримує PATCH).

502 Bad Gateway - reverse proxy (nginx, Cloudflare) не отримав відповідь від backend сервера. Типово backend впав або у timeout.

503 Service Unavailable - сервер перевантажений або в обслуговуванні. Часто з header Retry-After. Це плановий відповідь, не crash.

504 Gateway Timeout - reverse proxy чекав backend довше, ніж timeout. Backend зазвичай ще працює, просто повільно.

520-525 Cloudflare errors - специфічно для Cloudflare. 520 = backend повернув щось нечитабельне, 522 = backend не відповів (connection timeout), 524 = backend відповів надто повільно (origin timeout).

Практичні правила alerting'у

• Alert негайно: 500, 502, 503 (якщо не дійсно планове обслуговування), 504, будь-який timeout
• Alert при повторі: одиничний 5xx може бути race condition; alert якщо той самий endpoint падає 2× поспіль
• Слідкувати за висхідним трендом: довгостроковий зріст 4xx може означати broken link, scraper attack або зламаний frontend
• Ігнорувати для alerting'у: 200-399 у межах очікуваного (стежте за response time замість коду)

Код стану + response time = повна картина

Стежити лише за кодом стану недостатньо - сервер може повертати 200, але за 30 секунд, що з точки зору клієнта - збій. Якісний моніторинг комбінує:

1. Очікуваний код стану (типово 200)
2. Максимальний response time (типово 5-10 секунд)
3. Keyword match у контенті (ключове слово, яке повинно бути в HTML)
4. SSL валідний + не перед кінцем дії

Падіння будь-якого = alert.

Моніторинг з точною класифікацією помилок

ePulz.io розрізняє код стану, response time, keyword match та SSL стан. Логи для кожної перевірки.

Спробувати на 7 днів →