Сайт, который не работает, — это сайт, которого не существует. Для пользователя разница между даунтаймом и закрытым бизнесом равна нулю. Каждая минута недоступности — это потерянные заказы, испорченная репутация и падение позиций в поисковой выдаче. При этом большинство владельцев узнают о проблемах от клиентов, а не от системы мониторинга. Потому что системы мониторинга у них попросту нет.
В этом руководстве разберём, как устроен мониторинг доступности, какие метрики важны, как правильно настроить оповещения и что делать, когда сайт всё-таки упал.
Зачем мониторить доступность
SLA и обязательства перед клиентами
Если у вас SaaS-продукт, маркетплейс или любой сервис, от которого зависят клиенты, — у вас есть SLA (Service Level Agreement). Явный или неявный. Клиенты ожидают, что сервис работает. Нарушение этих ожиданий стоит дорого: от компенсаций до расторжения контрактов.
Без мониторинга вы не знаете свой реальный аптайм. А значит, не можете ни отчитаться перед клиентами, ни понять, соблюдаете ли собственные обязательства.
Потеря денег
Для интернет-магазина с выручкой 3 000 000 ₽ в месяц час простоя стоит:
3 000 000 ₽ / 30 дней / 24 часа ≈ 4 167 ₽/час
Это без учёта пикового трафика. Если сайт падает в Чёрную пятницу или во время рекламной кампании, потери вырастают в 5-10 раз. Добавьте сюда стоимость привлечённого трафика, который уходит к конкурентам, — сумма перестаёт быть символической.
Влияние на SEO
Поисковые системы регулярно обходят сайты. Если в момент обхода Googlebot получает 5xx-ошибку, страница временно выпадает из индекса. При повторных инцидентах краулинговый бюджет сокращается, а позиции снижаются.
Google Search Console фиксирует ошибки сервера, но с задержкой в несколько дней. Мониторинг в реальном времени даёт информацию за секунды, а не за дни.
Доверие пользователей
Пользователь, столкнувшийся с недоступным сайтом, редко возвращается. Исследования показывают, что 88% пользователей не вернутся на сайт после неудачного опыта. В конкурентных нишах это фатально — клиент просто уйдёт к конкуренту.
Как работает мониторинг доступности
Принцип прост: внешний сервис периодически отправляет запросы к вашему сайту и проверяет ответ. Если ответ не соответствует ожиданиям — срабатывает алерт.
HTTP(S)-проверки
Самый распространённый и полезный тип мониторинга. Сервис отправляет HTTP-запрос и проверяет:
- Статус-код ответа — ожидается 200, 301 или другой допустимый код
- Время ответа — укладывается ли в заданный порог
- Содержимое страницы — присутствует ли ключевое слово или фраза
- SSL-сертификат — валиден ли, не истекает ли в ближайшее время
GET / HTTP/1.1
Host: example.com
User-Agent: UptimeMonitor/1.0
--- Ожидаемый ответ ---
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Если сервер отвечает 503 или вообще не отвечает в течение таймаута — инцидент.
TCP-проверки
Проверка на сетевом уровне: можно ли установить TCP-соединение с определённым портом. Полезно для мониторинга:
- Баз данных (порт 3306, 5432)
- Почтовых серверов (порт 25, 587)
- FTP (порт 21)
- Произвольных сервисов
TCP connect → example.com:443
Результат: соединение установлено за 45 мс ✓
TCP-проверки не анализируют содержимое ответа, но надёжно фиксируют сетевую недоступность.
DNS-проверки
DNS — фундамент доступности. Если DNS-сервер не резолвит домен, сайт недоступен, даже если сервер работает идеально.
DNS-мониторинг проверяет:
- Резолвится ли домен вообще
- Возвращается ли правильный IP-адрес
- Время DNS-резолва
- Корректность MX, TXT и других записей
Для диагностики DNS-проблем удобно использовать DNS Lookup — инструмент покажет все записи домена и время ответа DNS-серверов.
Ping (ICMP)
Простейшая проверка — ICMP echo request. Показывает, доступен ли хост в сети. Минус: многие серверы и файрволы блокируют ICMP, поэтому ping-мониторинг ненадёжен как единственный метод.
Комбинирование методов
На практике стоит использовать несколько типов проверок одновременно:
| Тип проверки | Что мониторит | Глубина | Скорость |
|---|---|---|---|
| Ping (ICMP) | Доступность хоста | Низкая | Быстрая |
| TCP | Доступность порта/сервиса | Средняя | Быстрая |
| DNS | Резолв домена | Средняя | Быстрая |
| HTTP(S) | Работа приложения | Высокая | Средняя |
| Content check | Корректность контента | Максимальная | Медленная |
Ключевые метрики мониторинга
Uptime (%)
Главная метрика — процент времени, когда сайт доступен. Считается за период (день, неделя, месяц, год):
Uptime % = (Общее время − Время простоя) / Общее время × 100
Пример: сайт был недоступен 43 минуты за месяц:
(43 200 мин − 43 мин) / 43 200 мин × 100 = 99.90%
Цифра 99.9% звучит впечатляюще, но за год это 8 часов 46 минут простоя. Подробнее о допустимых значениях — в разделе про SLA.
Response Time (время ответа)
Время от отправки запроса до получения полного ответа. Включает:
- DNS lookup
- TCP handshake
- TLS handshake
- Ожидание первого байта (TTFB)
- Загрузка тела ответа
Общее время ответа = DNS + TCP + TLS + TTFB + Transfer
Нормальные значения для главной страницы:
| Метрика | Хорошо | Допустимо | Плохо |
|---|---|---|---|
| DNS | < 50 мс | 50-150 мс | > 150 мс |
| TCP | < 100 мс | 100-300 мс | > 300 мс |
| TLS | < 100 мс | 100-300 мс | > 300 мс |
| TTFB | < 200 мс | 200-600 мс | > 600 мс |
| Полный ответ | < 500 мс | 500 мс — 1.5 с | > 1.5 с |
TTFB (Time To First Byte)
Время до первого байта ответа — критичный показатель серверной производительности. Высокий TTFB указывает на проблемы:
- Медленные запросы к базе данных
- Нехватка серверных ресурсов (CPU, RAM)
- Отсутствие кэширования
- Далёкий от пользователя сервер (географическая задержка)
TTFB входит в метрику Core Web Vitals как компонент LCP. Если хотите комплексно оценить производительность, загляните в Web Vitals — там можно проверить LCP, FID, CLS и другие ключевые показатели.
Частота проверок
Как часто нужно проверять сайт? Зависит от критичности:
| Тип сайта | Интервал проверки | Обоснование |
|---|---|---|
| E-commerce, SaaS | 30 сек — 1 мин | Каждая минута простоя = потеря выручки |
| Корпоративный сайт | 2-5 мин | Важен, но не критичен посекундно |
| Блог, портфолио | 5-10 мин | Кратковременный даунтайм допустим |
| Внутренний сервис | 1-3 мин | Влияет на продуктивность команды |
Проверки с Uptime Monitor на reChecker можно настроить с интервалом от 30 секунд, что закрывает потребности даже высоконагруженных проектов.
SLA и расчёт допустимого даунтайма
SLA определяет, сколько простоя «разрешено» за период. Разница между 99% и 99.99% выглядит незначительной, но в абсолютных числах — колоссальной.
Таблица допустимого даунтайма
| SLA | Даунтайм в день | Даунтайм в месяц | Даунтайм в год |
|---|---|---|---|
| 99% | 14 мин 24 сек | 7 ч 18 мин | 3 дня 15 ч |
| 99.5% | 7 мин 12 сек | 3 ч 39 мин | 1 день 19 ч |
| 99.9% | 1 мин 26 сек | 43 мин 50 сек | 8 ч 46 мин |
| 99.95% | 43 сек | 21 мин 55 сек | 4 ч 23 мин |
| 99.99% | 8.6 сек | 4 мин 23 сек | 52 мин 36 сек |
| 99.999% | 0.86 сек | 26 сек | 5 мин 16 сек |
Что стоит за каждым уровнем
99.9% (три девятки) — стандарт для большинства коммерческих сайтов. 43 минуты в месяц — один серьёзный инцидент или несколько мелких.
99.99% (четыре девятки) — для платёжных систем, банков, критичных SaaS. Достижимо только с резервированием, автоматическим failover и отсутствием плановых даунтаймов.
99.999% (пять девяток) — уровень телекоммуникаций и облачных провайдеров. 5 минут даунтайма в год. Требует мультирегиональной инфраструктуры.
Как выбрать целевой SLA
Чем дороже минута простоя, тем выше должен быть SLA. Ответьте на три вопроса: сколько денег теряет бизнес за час простоя? Сколько стоит инфраструктура нужного уровня? Какие SLA обещают конкуренты? Нет смысла гнаться за 99.99%, если бизнес не теряет критичных сумм при простое в 40 минут в месяц.
Типы алертов и каналы оповещения
Мониторинг без уведомлений — просто сбор статистики. Смысл системы в том, чтобы нужный человек узнал о проблеме за секунды.
Базовый канал. Подходит для некритичных уведомлений и отчётов:
- Еженедельные/ежемесячные сводки по аптайму
- Предупреждения об истечении SSL-сертификата
- Отчёты о производительности
Минус: задержка доставки, письма могут попасть в спам, не все проверяют почту в реальном времени.
Telegram
Оптимальный канал для русскоязычных команд. Сообщения приходят мгновенно, поддерживают форматирование, можно создать отдельный канал для алертов.
🔴 САЙТ НЕДОСТУПЕН
example.com — HTTP 503
Время: 2026-03-07 14:23:05 MSK
Длительность: 2 мин
Последний успешный ответ: 200 OK (342 мс)
Slack
Стандарт для команд, использующих Slack как основной мессенджер. Интеграция через incoming webhook — алерты попадают прямо в рабочий канал команды.
Webhook
Универсальный способ интеграции с любой системой. Мониторинг отправляет POST-запрос на указанный URL с данными об инциденте:
{
"event": "site_down",
"url": "https://example.com",
"status_code": 503,
"response_time_ms": null,
"timestamp": "2026-03-07T14:23:05Z",
"check_location": "Frankfurt, DE",
"consecutive_failures": 3
}
Через webhook можно подключить PagerDuty, OpsGenie, кастомные автоматизации — вплоть до автоматического перезапуска сервиса.
Эскалация
Правильная система оповещений — многоуровневая:
- 0-2 минуты — уведомление в Telegram/Slack дежурному инженеру
- 5 минут — повторное уведомление + звонок
- 15 минут — эскалация на тимлида
- 30 минут — уведомление CTO / руководства
- 1 час — уведомление клиентам через статус-страницу
Чем критичнее сервис, тем агрессивнее эскалация.
Что проверять кроме доступности
Сайт может возвращать 200 OK, но при этом быть «сломанным». Мониторинг только статус-кода — это необходимый минимум, но недостаточный.
SSL-сертификат
Просроченный SSL-сертификат — одна из самых частых причин «поломки» рабочего сайта. Браузер показывает пугающее предупреждение, и пользователи уходят.
Что мониторить:
- Срок действия сертификата (алерт за 30, 14, 7 дней)
- Корректность цепочки сертификатов
- Используемый протокол (TLS 1.2+)
- Соответствие домена сертификату
Проверить текущий статус сертификата можно через SSL Checker, а для постоянного контроля настройте SSL Monitor — сервис предупредит об истечении заранее.
Содержимое страницы (Content Check)
HTTP 200 не гарантирует, что пользователь видит корректную страницу. Приложение могло вернуть пустую страницу, CDN — устаревшую версию, а балансировщик — заглушку. Решение — проверка наличия ключевого слова в ответе. Если мониторинг ожидает фразу «Добро пожаловать», а её нет — срабатывает алерт, хотя статус-код 200.
Статус-коды
Не все страницы сайта одинаково важны. Имеет смысл мониторить:
| Страница | Ожидаемый код | Почему важна |
|---|---|---|
Главная / | 200 | Точка входа для большинства пользователей |
Каталог /catalog | 200 | Основная коммерческая страница |
API /api/v1/health | 200 | Работоспособность бэкенда |
Оплата /checkout | 200 | Критична для конверсии |
| Редирект с www | 301 | Корректность перенаправления |
| Несуществующая страница | 404 | Правильная обработка ошибок |
Производительность
Даже если сайт доступен, замедление работы влияет на конверсию не меньше, чем полный даунтайм:
- Рост времени ответа на 1 секунду снижает конверсию на 7%
- Задержка более 3 секунд — 53% мобильных пользователей покидают сайт
Мониторинг производительности дополняет мониторинг доступности. Если response time стабильно растёт — это предвестник инцидента.
Срок действия домена
Домены забывают продлить чаще, чем кажется. Истекший домен — полная недоступность плюс риск перехвата третьими лицами. Настройте напоминания за 30 и 7 дней до истечения.
Реагирование на инциденты
Мониторинг обнаружил проблему. Что дальше? Без заранее подготовленного плана действий (runbook) команда тратит драгоценное время на выяснение «кто что делает».
Runbook: пошаговый план
Шаг 1. Подтверждение инцидента (0-2 минуты)
# Проверить доступность из нескольких точек
curl -o /dev/null -s -w "HTTP: %{http_code}, Time: %{time_total}s\n" https://example.com
# Проверить DNS
dig example.com +short
# Проверить SSL
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates
Убедитесь, что проблема реальная, а не ложное срабатывание мониторинга. Проверьте с другого устройства, сети, через VPN.
Шаг 2. Классификация (2-5 минут)
| Уровень | Описание | Пример |
|---|---|---|
| P1 (Critical) | Полная недоступность | Сайт не открывается, 5xx на всех страницах |
| P2 (Major) | Частичная недоступность | Не работает оплата, API отдаёт ошибки |
| P3 (Minor) | Деградация производительности | Response time вырос в 3 раза |
| P4 (Low) | Косметическая проблема | Битая картинка, неправильная вёрстка |
Шаг 3. Диагностика (5-15 минут)
# Логи приложения
journalctl -u myapp --since "5 minutes ago"
# Ресурсы сервера
top -bn1 | head -20 && df -h && free -m
Типичные причины даунтайма:
- Сервер перегружен — высокий CPU/RAM, нехватка дискового пространства
- Приложение упало — ошибка в коде, утечка памяти, исчерпание пула соединений к БД
- Сетевая проблема — DDoS, проблемы хостинга, сбой DNS
- Истёк SSL-сертификат — забыли продлить, сломался автообновление Let's Encrypt
- Ошибка деплоя — новая версия содержит баг
Шаг 4. Устранение (параллельно с диагностикой)
Если причина очевидна — действуйте немедленно:
sudo systemctl restart myapp # перезапуск приложения
git revert HEAD && deploy # откат деплоя
sudo nginx -t && sudo systemctl restart nginx # перезапуск nginx
Шаг 5. Верификация
После устранения убедитесь, что мониторинг показывает сайт доступным, response time вернулся к норме, нет ошибок в логах, а ключевые сценарии (оформление заказа, авторизация) работают.
Шаг 6. Постмортем
После каждого серьёзного инцидента (P1, P2) — письменный разбор. Структура постмортема:
1. Длительность и влияние (сколько пользователей затронуто)
2. Таймлайн — поминутная хронология событий
3. Корневая причина — что именно сломалось и почему
4. Действия — что сделать, чтобы это не повторилось
Постмортем — не поиск виноватых, а инструмент улучшения системы. Каждый инцидент должен заканчиваться конкретными задачами в трекере.
Стоимость простоя
Мониторинг — это инвестиция. Чтобы обосновать бюджет, нужно посчитать стоимость простоя.
Формула расчёта
Стоимость простоя = (Выручка/час) + (Стоимость привлечения × Потерянные посетители)
+ (Стоимость труда × Часы восстановления) + Репутационные потери
Пример расчёта
Интернет-магазин:
- Выручка: 5 000 000 ₽/мес
- Трафик: 50 000 посетителей/мес
- CPC в нише: 45 ₽
- Команда: 2 инженера × 2 500 ₽/час
Простой 1 час:
Прямые потери: 5 000 000 / 730 = 6 849 ₽
Потеря трафика: (50 000 / 730) × 45 = 3 082 ₽
Труд инженеров: 2 × 2 500 = 5 000 ₽
─────────────────────────────────────────────────────
Итого за 1 час: ≈ 14 931 ₽
За год при SLA 99.9% (8.76 часа даунтайма):
14 931 × 8.76 ≈ 130 800 ₽/год
Мониторинг, который стоит несколько тысяч рублей в месяц, окупается при предотвращении одного серьёзного инцидента.
ROI мониторинга
Если мониторинг сократил среднее время обнаружения инцидента с 30 минут до 1 минуты — это 29 минут сэкономленного простоя на каждый инцидент. При 5 инцидентах в год экономия составит ~36 000 ₽ — мониторинг окупается многократно.
Практические рекомендации по настройке
Минимальный набор проверок
Для любого коммерческого сайта:
- HTTP-проверка главной страницы — интервал 1 мин, проверка статус-кода и ключевого слова
- HTTP-проверка API/бэкенда — интервал 1 мин, health-endpoint
- SSL-мониторинг — ежедневная проверка срока действия
- DNS-проверка — интервал 5 мин
Проверки из нескольких локаций
Одна точка мониторинга может давать ложные срабатывания из-за локальных сетевых проблем. Проверки из 3+ геолокаций повышают достоверность: если сайт недоступен из одной точки — возможно, проблема на стороне провайдера; если из всех — инцидент подтверждён.
Пороги алертов
Не ставьте алерт на первую же неудачную проверку. Настройте подтверждение: например, алерт срабатывает, если 2 последовательные проверки провалены или response time превышает 5 секунд в течение 5 минут. Это отсекает кратковременные сетевые сбои.
Health-endpoint
Создайте выделенный эндпоинт для мониторинга, который проверяет реальное состояние приложения:
app.get('/health', async (req, res) => {
const checks = { database: false, cache: false };
try { await db.query('SELECT 1'); checks.database = true; } catch (e) {}
try { await redis.ping(); checks.cache = true; } catch (e) {}
const healthy = Object.values(checks).every(Boolean);
res.status(healthy ? 200 : 503).json({
status: healthy ? 'ok' : 'degraded',
checks,
timestamp: new Date().toISOString()
});
});
Такой эндпоинт даёт мониторингу информацию о состоянии всех зависимостей, а не просто факт «веб-сервер отвечает».
Чеклист: что настроить прямо сейчас
Если у вас пока нет мониторинга, начните с этого:
- Настроить HTTP-проверку главной страницы (интервал 1 мин)
- Настроить проверку ключевого API-эндпоинта
- Создать health-endpoint в приложении
- Подключить алерты в Telegram или Slack
- Настроить мониторинг SSL-сертификата
- Написать runbook на основные сценарии сбоев
- Определить целевой SLA и зафиксировать его
- Назначить ответственных за реагирование
Uptime Monitor на reChecker позволяет закрыть первые пять пунктов за несколько минут — без сложной настройки инфраструктуры.
Заключение
Мониторинг доступности — не роскошь и не паранойя. Это базовая гигиена для любого сайта, который приносит деньги или представляет бизнес. Стоимость инструментов мониторинга несопоставима с ценой даже одного незамеченного часа простоя.
Главные принципы:
- Мониторьте из нескольких локаций — одна точка ненадёжна
- Проверяйте не только статус-код — содержимое страницы, SSL, DNS, производительность
- Настройте быстрые алерты — секунды решают всё
- Имейте runbook — в момент инцидента не время думать, что делать
- Считайте стоимость простоя — это аргумент для бюджета на инфраструктуру
- Проводите постмортемы — каждый инцидент должен сделать систему надёжнее
Сайт, за которым не следят, рано или поздно упадёт незаметно. Вопрос только в том, узнаете вы об этом первым — или последним.