На прошлой неделе одна Fortune 500-компания за шесть часов потеряла, по оценкам, около $14 миллионов — потому что один SSL-сертификат тихо истёк, и никто этого не заметил, пока клиенты не начали жаловаться в Twitter. Письмо о продлении было отправлено. Оно ушло на общий ящик, которым раньше владел уволившийся в марте DevOps-лид. Сертификат истёк в субботу в 02:14 UTC. Дежурный инженер платформенной команды не получил вызова, потому что технически ничего не «упало» — сайт продолжал отдавать трафик, просто с огромным красным предупреждением браузера, отпугнувшим всех платящих клиентов.

Это не редкий случай. Это самая частая предотвратимая авария, которую мы встречаем, и она не имеет отношения ни к облачной архитектуре, ни к контейнерной оркестрации. Она происходит потому, что большинство команд воспринимают мониторинг доменов, SSL и uptime как три отдельные задачи для трёх разных инструментов — а чаще всего ими не занимаются вообще. Этот гайд проводит по полному трёхслойному стеку: что мониторить на каждом уровне и как всё это связать так, чтобы вас больше никогда не застали врасплох.

Трёхслойный стек мониторинга

У каждого публичного веб-проекта есть три независимых режима отказа, каждый из которых вызывает симптом «сайт не работает», но требует совершенно разного устранения:

Истечение домена — регистрация заканчивается, регистратор забирает домен обратно, и DNS перестаёт резолвиться. Время восстановления: часы или дни. Стоимость: катастрофа.
Истечение SSL-сертификата — DNS работает, сервер живой, но сертификат прошёл notAfter. Браузеры блокируют соединение. Время восстановления: минуты при автоматизации, часы при ручной правке.
Падение uptime / HTTP-ошибка — DNS резолвится, сертификат валиден, но сервер возвращает 5xx, отваливается по таймауту или хостинг-провайдер перевёл его на parking-страницу. Время восстановления зависит от первопричины.

Все три слоя нужны, потому что каждый ловит сбой, который пропускают остальные. Uptime-мониторинг скажет, что сайт сломан — но только когда сертификат уже истёк и клиенты уже ушли. Мониторинг домена ловит истечение регистрации за недели до фактического падения. SSL-мониторинг видит проблему сертификата за 30 дней до появления предупреждения в браузере. Сложите все три — получите эшелонированную оборону; пропустите хотя бы один — оставите дыру, в которую можно загнать грузовик.

Слой 1: Мониторинг истечения домена#

Истечение домена — самая предотвратимая и самая позорная авария в интернете. Microsoft её допускала. Google допускал (дважды). Foursquare. Sorenson Media. Каждый раз — многочасовой простой из-за истёкшей кредитки или письма о продлении, ушедшего не туда.

Почему писем от регистратора недостаточно

Регистраторы шлют напоминания о продлении. Они уходят на тот email, который был указан при первой регистрации — часто это личный Gmail контрактника, ушедшего три года назад. Даже если адрес правильный, такие письма регулярно попадают в спам, а если не попадают — выглядят точно как фишинговые «уведомления о продлении», и их удаляют.

Автопродление должно решать эту проблему, но оно тихо ломается тремя способами:

Кредитная карта на счету истекает.
Карту блокируют по подозрению в мошенничестве (годовые продления выглядят необычно для банков-эмитентов).
Тумблер автопродления переключается во время миграции аккаунта или редизайна панели.

Внешний мониторинг — единственная надёжная страховка.

Как мониторить истечение домена

Протокол — RDAP (современная замена WHOIS) с откатом на WHOIS для TLD, ещё не поддерживающих RDAP. Ежедневной проверки достаточно — даты истечения не двигаются поминутно, и регистраторы добавляют свой grace-период поверх любых ваших записей.

# Быстрая ручная проверка через командную строку
curl -s "https://rdap.org/domain/example.com" | jq '.events[] | select(.eventAction=="expiration")'

Запихните это в cron — и базовый монитор готов. Но вам также нужны пороги оповещений, retry-логика для временных WHOIS-сбоев и способ отличать «истёк» от «продлён, но дата ещё не распространилась». Поэтому хостовый инструмент обычно быстрее, чем самописный.

Каденция оповещений 30/14/7/2 дня#

Шлите алерты в четыре момента: за 30 дней (планирование), за 14 дней (действие), за 7 дней (эскалация) и за 2 дня (паника). Чаще — будет усталость. Реже — нет буфера, если первое предупреждение пропущено.

Что на самом деле значит «истёк»

Домены не отваливаются мгновенно. У большинства TLD многоступенчатый таймлайн:

Дни 0–30 после истечения: grace-период. Домен заморожен (DNS не работает), но регистрант может продлить по обычной цене.
Дни 30–60: redemption-период. Продление ещё возможно, но за дополнительные $80–$200.
Дни 60–90: pending delete. Домен заблокирован и не подлежит продлению.
День 90+: drop. Домен может зарегистрировать кто угодно.

Если ваш домен попал в redemption — вы, скорее всего, заплатите, но восстановите его. Если попал в pending delete — вы соревнуетесь с профессиональными drop-catchers. Не доводите до этого.

У Nova Uptime есть бесплатный чекер истечения домена для разовых проверок, а в дашборде RDAP запускается ежедневно по каждому отслеживаемому домену с уже встроенной каденцией 30/14/7/2 дня.

Слой 2: Мониторинг SSL-сертификатов#

Истечение SSL-сертификата — с большим отрывом самая частая причина «сайт не работает». Microsoft Teams в феврале 2020 года уходили в офлайн из-за истёкшего сертификата авторизации. Microsoft Azure в 2021 году потеряли несколько часов по той же причине. Spotify допускал это. LinkedIn допускал. Google Voice допускал. Общая нить: 90-дневный цикл Let's Encrypt приучил всю индустрию ждать автоматизации, а когда автоматизация ломается — она ломается тихо.

Что на самом деле мониторить в сертификате

У сертификата больше режимов отказа, чем просто notAfter. Полный мониторинг проверяет:

notBefore и notAfter — окно валидности. Алерты за 30, 14, 7 и 2 дня до notAfter.
Целостность цепочки issuer — ваш сервер должен отдавать полную промежуточную цепочку. Типичная ошибка деплоя — отдавать только leaf-сертификат; в Chrome (он кэширует промежуточные) это работает, но ломается в Firefox, мобильных браузерах и большинстве API-клиентов.
Совпадение Subject и SAN — Subject Alternative Names сертификата должны включать запрошенный hostname. Wildcard-сертификаты — нормально, но убедитесь, что wildcard действительно покрывает нужный поддомен.
Cipher suite и версия TLS — TLS 1.0 и 1.1 устарели. TLS 1.2 — минимум; TLS 1.3 — желателен. Слабые шифры (RC4, 3DES) должны заваливать проверку.
Наличие OCSP-stapling — если вы настроили OCSP stapling и он перестал работать, в браузере появится предупреждение, даже при валидном сертификате.

Типовые SSL-сбои#

В порядке убывания частоты на проде:

Сертификат истёк. Хук автопродления не отработал. Cron упал. Продление прошло, но веб-сервер не перезагрузил новый сертификат.
Промежуточный сертификат отсутствует или неправильный. Certbot собирает цепочку, но deploy-скрипт её перезаписывает; или reverse-proxy сконфигурирован с ssl_certificate вместо ssl_certificate fullchain.pem.
Несовпадение hostname. Сертификат выдан на example.com, а пользователь стучится в www.example.com, и www нет в SAN.
Отдан не тот сертификат (SNI-баг). На сервере несколько сайтов, и отдаётся сертификат default-vhost вместо нужного.
Дрейф часов. Часы на сервере отстают/идут вперёд на несколько минут — валидные сертификаты выглядят как истёкшие или ещё не вступившие в силу.

Реальные сертификатные катастрофы

Сюжет повторяется каждый год:

Microsoft Teams, фев. 2020 — истёкший внутренний сертификат уронил Teams на часы в пик рабочего дня.
Microsoft Azure, март 2021 — истечение TLS-сертификата вызвало 14-часовой простой, затронувший аутентификацию по нескольким продуктам Microsoft.
Spotify, в разные годы — истёкшие сертификаты приводили к как минимум трём публичным простоям.
GitHub status page — в какой-то момент сама status-страница отдавала истёкший сертификат, и это та ирония, от которой инженеры нервно смеются.

Ни одной из этих компаний не хватало инженеров, чтобы предотвратить истечение. Им не хватало эшелонированного мониторинга. Бесплатный SSL-чекер Nova Uptime делает разовую проверку; дашборд гоняет ту же проверку по расписанию и шлёт алерты за 30/14/7/2 дня.

Слой 3: Uptime / HTTP-мониторинг#

Uptime-мониторинг — слой, ловящий всё, что не предусматривают первые два: падения серверов, неудачные деплои, утечки памяти, исчерпание connection-pool базы, DDoS, проблемы хостера, ошибки DNS, отравление кэша CDN и ещё пятьдесят сценариев, которых не видно ни в сертификате, ни в записи регистратора.

Что проверять

Полезный HTTP-монитор проверяет больше, чем «вернул ли запрос 200?». А именно:

Код статуса — 2xx — здоровье, 3xx может быть редиректом на parking-страницу (подозрительно), 4xx и 5xx — отказ.
Время ответа — рост p95 — главный опережающий индикатор проблемы с базой или CPU.
Содержимое тела — лучше проверять известную строку (heartbeat-эндпоинт, отдающий {"status":"ok"}), чтобы ловить случай, когда сервер отдаёт 200, а приложение упало и отдаёт страницу ошибки.
Успешный TLS-handshake — складывает часть слоя 2 в ту же проверку.
Время резолва DNS — медленный DNS-lookup часто первый признак проблем CDN или upstream.

Зачем нужен мульти-регион

Однорегиональный монитор — машина ложной уверенности. Ваш монитор живёт в us-east-1. Ваше приложение — там же. У AWS региональный инцидент. Падают оба. Монитор сообщает «сайт работает», потому что монитор мёртв. Мульти-регион (или хотя бы кросс-регион — мониторить в us-west, если приложение в us-east) убирает этот класс ложноотрицательных результатов.

Скриншоты при сбое

Когда проверка падает, делайте скриншот страницы. Это золото при разборах: фиксирует ровно то, что видел пользователь в момент сбоя — не то, что говорят логи, не то, что думает синтетический монитор, а то, что было на экране. 502? Maintenance-страница? Белый экран? Cloudflare-капча? Вы узнаете за две секунды вместо двух часов.

Многоканальные оповещения

Email необходим, но недостаточен. Письма буферизуются, объединяются и игнорируются. Критичные алерты должны обходить email и доходить до человека напрямую. Nova Uptime поддерживает email, WhatsApp (через Baileys, без оплаты за каждое сообщение) и исходящие webhook'и (с HMAC-подписью) для интеграции с PagerDuty, Opsgenie, Slack или любым вашим инцидент-инструментом.

Полная настройка стека на Nova Uptime#

Практическая настройка end-to-end, примерно в том порядке, в каком её делают.

1. Добавьте домен#

Вставьте URL в дашборд. Nova Uptime сразу запустит HTTP-проверку, SSL-handshake, RDAP/WHOIS-lookup для истечения домена и подгрузит favicon. Все четыре результата вы увидите в течение 60 секунд.

2. Настройте интервал проверок#

Free-план: интервал 15 минут. Pro-план: до 59 секунд. Agency-план: тот же 59-секундный минимум плюс более высокие лимиты по доменам. Для большинства маркетинговых сайтов 5 минут — норма. Для платёжных API нужен 59-секундный интервал.

3. Подключите WhatsApp#

В Settings → WhatsApp один раз отсканируйте QR-код. С этого момента любой алерт можно отправлять на ваш WhatsApp без оплаты за сообщения (Free = 1 номер, Pro = 3, Agency = 5). WhatsApp доставляет быстрее и труднее игнорировать, чем email.

4. Добавьте CC-emails для команды#

В настройках каждого домена можно добавить до 5 CC-адресов. Это команда, которой шлются алерты по конкретному домену — главная страница может алертить маркетинг-лида, API — дежурного инженера.

5. Протестируйте алерты намеренной поломкой#

Лучшее, что можно сделать после настройки мониторинга, — один раз сознательно его сломать. Перенацельте отслеживаемый URL на несуществующий hostname или временно отзовите сертификат и убедитесь, что алерт срабатывает. Если не срабатывает — вы только что поймали баг конфигурации в самый дешёвый момент.

6. Когда апгрейдить#

Free-тариф покрывает 5 доменов и хватает для личных проектов и маленьких команд. Апгрейдиться стоит по двум причинам: (а) вы выросли из 5 доменов или (б) нужны интервалы меньше 15 минут. Подробности — на странице тарифов.

Стратегия алертов: как не перегореть

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

Три правила:

Раздвигайте по уровням. Предупреждения за 30 дней до истечения домена — информационные, только email. Предупреждения SSL за 7 дней — уже warnings: email + Slack-канал. Сайт лежит 2+ минуты — критика: WhatsApp, звонок, дежурного на пейджер. Не шлите всё во все каналы.

Ставьте паузу на плановых работах. Если идёт деплой, миграция базы или ротация сертификата — поставьте монитор на паузу на время работ. У Nova Uptime есть пауза на конкретный домен и глобальный тумблер «приостановить все уведомления» в Settings. (Мониторинг продолжается — паузятся только уведомления, чтобы потом можно было посмотреть логи.)

Лимитируйте «всё ещё лежит». Когда домен уже зарепортили лежащим, не нужно дёргать каждую минуту. Nova Uptime шлёт первый алерт, затем раз в час напоминания (по email и WhatsApp), пока домен не восстановится. Алерт о восстановлении срабатывает мгновенно.

Маршрутизируйте по канал. Email хорош для дайджестов, недельных отчётов и информационных алертов. WhatsApp — для критичных, требующих человека в ближайшие 5 минут. Webhook'и — для автоматизации (автосоздание инцидента в PagerDuty, постинг в Slack, запуск runbook'ов).

Боковая колонка: реальные катастрофы

Несколько случаев, которые стоит знать:

LinkedIn, октябрь 2022 — многочасовое истечение SSL на поддомене, влиявшее на доставку сообщений. Основной сайт продолжал работать, проблему скрывало это до тех пор, пока её не зарепортили клиенты.
Cloudflare, 2021 — неправильная конфигурация цепочки промежуточного сертификата вызвала массовые проблемы у сайтов, использовавших edge-сертификаты Cloudflare. Leaf был валиден; цепочка — нет.
GitHub Status, разные инциденты — сама status-страница в разные моменты отдавала истёкшие сертификаты или имела проблемы регистрации. Урок: мета-мониторинг (то, что говорит, когда сломан мониторинг) сам нуждается в мониторинге.

Чек-лист настройки

Пройдите по списку и получите эшелонированную оборону:

Заключение

Мониторинг домена, SSL-алерты и uptime — не три отдельных инструмента. Это три слоя одной стратегии defence-in-depth, и любой стек, который покрывает только один или два, рано или поздно подведёт вас в худший момент. Nova Uptime даёт все три в одном дашборде с email- и WhatsApp-алертами уже на бесплатном тарифе. Зарегистрируйтесь бесплатно и подключите до пяти доменов меньше чем за пять минут.

Связанные материалы

Uptime-мониторинг для SaaS-приложений — multi-tenant-плейбук для SaaS-команд
Гайд по политике DMARC — email-сторона мониторинга домена
Бесплатный SSL-чекер — разовый анализ сертификата
Бесплатный чекер истечения домена — RDAP/WHOIS-lookup со статусом grace-периода
Бесплатный чекер email-здоровья — убедитесь, что ваши письма-алерты действительно доходят

Мониторинг домена с SSL-алертами: полный гайд по настройке на 2026 год