Мониторинг доступности сайта: зачем нужен и как настроить

Сайт, который не работает, — это сайт, которого не существует. Для пользователя разница между даунтаймом и закрытым бизнесом равна нулю. Каждая минута недоступности — это потерянные заказы, испорченная репутация и падение позиций в поисковой выдаче. При этом большинство владельцев узнают о проблемах от клиентов, а не от системы мониторинга. Потому что системы мониторинга у них попросту нет.

В этом руководстве разберём, как устроен мониторинг доступности, какие метрики важны, как правильно настроить оповещения и что делать, когда сайт всё-таки упал.

Зачем мониторить доступность

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 минут в месяц.

Типы алертов и каналы оповещения

Мониторинг без уведомлений — просто сбор статистики. Смысл системы в том, чтобы нужный человек узнал о проблеме за секунды.

Email

Базовый канал. Подходит для некритичных уведомлений и отчётов:

• Еженедельные/ежемесячные сводки по аптайму
• Предупреждения об истечении 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, кастомные автоматизации — вплоть до автоматического перезапуска сервиса.

Эскалация

Правильная система оповещений — многоуровневая:

1. 0-2 минуты — уведомление в Telegram/Slack дежурному инженеру
2. 5 минут — повторное уведомление + звонок
3. 15 минут — эскалация на тимлида
4. 30 минут — уведомление CTO / руководства
5. 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 ₽ — мониторинг окупается многократно.

Практические рекомендации по настройке

Минимальный набор проверок

Для любого коммерческого сайта:

1. HTTP-проверка главной страницы — интервал 1 мин, проверка статус-кода и ключевого слова
2. HTTP-проверка API/бэкенда — интервал 1 мин, health-endpoint
3. SSL-мониторинг — ежедневная проверка срока действия
4. 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 позволяет закрыть первые пять пунктов за несколько минут — без сложной настройки инфраструктуры.

Заключение

Мониторинг доступности — не роскошь и не паранойя. Это базовая гигиена для любого сайта, который приносит деньги или представляет бизнес. Стоимость инструментов мониторинга несопоставима с ценой даже одного незамеченного часа простоя.

Главные принципы:

1. Мониторьте из нескольких локаций — одна точка ненадёжна
2. Проверяйте не только статус-код — содержимое страницы, SSL, DNS, производительность
3. Настройте быстрые алерты — секунды решают всё
4. Имейте runbook — в момент инцидента не время думать, что делать
5. Считайте стоимость простоя — это аргумент для бюджета на инфраструктуру
6. Проводите постмортемы — каждый инцидент должен сделать систему надёжнее

Сайт, за которым не следят, рано или поздно упадёт незаметно. Вопрос только в том, узнаете вы об этом первым — или последним.