Что делать, если сайт упал ночью, а веб-мастер недоступен

Ночью владельцу безопасны три действия: проверить, лежит ли сайт у всех, пополнить баланс хостинга или домена, зафиксировать симптомы для подрядчика. Всё остальное, включая правку файлов и восстановление из копии наугад, до утра лучше не трогать.

Сценарий знакомый: половина первого ночи, владелец открывает сайт показать другу или проверить заявку, а там белый экран, 502 или жирная заглушка хостера. Веб-мастер не отвечает, мессенджер молчит, утром сайт должен работать. Эта статья про то, что владельцу делать в эти полтора часа, чтобы к утру либо сайт уже работал, либо у подрядчика на столе лежал нормальный отчёт об инциденте, а не паническое «почини срочно».

Я разберу алгоритм, которым сам пользуюсь, когда меня будят ночью: что проверить за 5 минут, что трогать руками, а что не трогать ни в коем случае. И дам шаблон, как зафиксировать инцидент, чтобы утром мы быстро поняли, кто виноват и что делать.

Серверная стойка ночью с красным индикатором тревоги

У всех или только у вас

Первое, что путает владельца, это уверенность, что раз у него сайт не открывается, значит он лежит. На самом деле в половине ночных «падений» сайт работает, просто его не видит конкретный канал: провайдер, корпоративный VPN, кэш браузера, мобильный 4G через жадного оператора.

Поэтому до любых действий надо ответить на простой вопрос: сайт недоступен у всех или только у меня.

Быстрая проверка из трёх шагов

Открыть сайт в режиме инкогнито с другим устройством. Лучше всего с мобильного интернета, отключив Wi-Fi, потому что Wi-Fi роутер мог закэшировать DNS.
Проверить через сторонний сервис: downforeveryoneorjustme.com, isitdownrightnow.com, 2ip.ru. Они стучатся к сайту со своих машин, и если у них зелёный значок, проблема в вашем канале.
Запросить страницу с командной строки, не из браузера:

curl -I https://example.ru/

Если в ответ прилетит HTTP/2 200, сайт работает, но что-то перехватывает запрос конкретно у вас. Если HTTP/2 502 или Could not resolve host, проблема настоящая, и пора лезть глубже.

В моей практике каждый третий ночной звонок от владельца про «сайт упал» заканчивается на этом шаге: оказывается, что провайдер делает плановые работы, корпоративный фаервол блокирует IP хостера или просто роутер дома отвалился.

Что делать, если только у вас

Если три проверки выше показывают, что у внешних сервисов сайт открывается, можно лечь спать. Никаких ночных действий с сайтом делать не надо: вы только сделаете хуже, а проблема сама пройдёт через полчаса, когда DNS-кэш у провайдера обновится. Утром, на свежую голову, можно почистить кэш браузера, поменять DNS на 1.1.1.1 или 77.88.8.8 (Яндекс) и забыть.

Куда смотреть, если сайт реально лежит

Допустим, проверка подтвердила: сайт не открывается ни у вас, ни у downforeveryoneorjustme. Дальше задача сузить, где именно проблема. Сайт это слоёный пирог, и каждый слой может отвалиться отдельно.

Слой 1. Домен и регистратор

Домен может банально протухнуть. Если оплачен на год, и автопродление не сработало (карта закончилась, баланс пуст), сайт перестаёт открываться в течение суток. Хуже того, если домен в .ru или .рф, после окончания срока начинается период preferential продления, во время которого сайт уже не работает, но домен ещё ваш.

Проверить просто: whois example.ru. В выводе ищем paid-till: или registry-expiration-date:. Если дата уже прошла, бегом в личный кабинет регистратора и продлевайте, обычно деньги списываются за 5 минут, и через пару часов сайт оживает.

Если домен оплачен, смотрим вторую вещь: NS-серверы. Иногда хостинг меняет имена NS-серверов, не предупреждая клиентов, или сам владелец случайно их редактирует и не замечает. В выводе whois смотрим nserver: и сверяем с тем, что должно быть. Поменяли по ошибке — вернули обратно.

Слой 2. DNS

Если домен жив и NS правильные, проверяем, что DNS-записи на месте.

dig example.ru A +short
dig www.example.ru A +short
dig example.ru NS

Должны прилететь IP-адреса хостинга. Если в ответ пусто или прилетает что-то странное, кто-то поменял A-запись (или она пропала после планового обслуживания DNS-провайдера). Идём в панель DNS, ставим правильный IP. TTL у большинства хостеров 3600 секунд, то есть от правки до видимости пройдёт до часа.

Отдельная история, когда DNS-провайдер сам лежит. Такое было в 2024 году с одним крупным российским DNS-сервисом, и тогда стояли тысячи сайтов одновременно. Лечится только переключением NS на резервного провайдера, что ночью без подготовки сделать нельзя. Просто ждём.

Слой 3. Хостинг

Это самый частый случай, причём в обе стороны: хостинг падает целиком, или у вас закончился тариф, лимит CPU, диск.

Первое, что делаем: открываем личный кабинет хостинга. Если кабинет тоже не открывается, значит у хостера авария целиком, и бороться бесполезно. Идём в их Telegram-канал или статус-страницу, там обычно есть формулировка вроде «ведутся технические работы на vh316, ETA 02:30». Просто ждём.

Если кабинет открылся, смотрим:

Баланс. Минусовой баланс на shared-хостинге обычно отключает сайт через 2-3 дня после нуля, но может и сразу.
Уведомления. Хостеры рассылают мейлы о превышении лимитов, аварийных нагрузках, заражении сайта.
Состояние сервера. На vh316 у Timeweb, на ru-3 у Beget, на shared-23 у reg.ru есть индикатор статуса. Зелёный — сервер жив.
Логи в панели. Большинство панелей (cPanel, ISPmanager, кастомные) показывают последние строки error_log и access_log. Там можно увидеть PHP Fatal error, Out of memory, Disk quota exceeded.
Лимиты по диску и БД. Когда диск переполняется, MySQL не может записать сессии, и сайт падает целиком.

Превышение CPU и одновременных подключений на shared-тарифе у российских хостеров часто временно блокирует сайт на 30-60 минут. Особенность тарифа, не баг. В таких случаях достаточно подождать или написать в поддержку, они часто разблокируют.

Слой 4. CMS и БД

Если хостинг живой, домен в порядке, DNS правильный, а сайт всё равно показывает ошибку, проблема в самом сайте. Тут ситуация хуже всего, потому что владельцу руками лезть в код опасно. Но кое-что проверить можно безопасно.

# Через SSH или встроенный терминал в панели хостинга
tail -50 /home/user/example.ru/logs/error.log

Что искать в логах:

Allowed memory size of ... bytes exhausted — превышен лимит памяти PHP.
Connection refused или Can't connect to MySQL server — база данных недоступна.
Maximum execution time of 30 seconds exceeded — какой-то запрос завис.
PHP Parse error — в файл попал битый код, обычно после правки темы или плагина.

Если видите Connection refused к MySQL, а другие сайты на хостинге работают, значит конкретно ваша база лежит. Это часто чинится через панель: «База данных» -> «Перезапустить» или «Восстановить из бэкапа». Но если вы не уверены — лучше не трогать, утром восстановим из снапшота.

Что НЕ делать в панике ночью

Это самая важная секция, потому что 9 из 10 случаев «вызовите специалиста срочно, мы тут что-то поправили и стало хуже» приходят именно из ночных попыток самостоятельной починки.

Сонный человек у телефона с пропущенным звонком

Не сносите .htaccess

Самая частая ошибка: владелец читает форум, где советуют «переименовать .htaccess для проверки». Переименовывает, сайт не оживает, владелец уже не помнит, как файл назывался, и нового не пишет. Утром нет редиректов, нет правил кэша, нет защиты, всё надо восстанавливать.

Если очень хочется проверить — сделайте копию: cp .htaccess .htaccess.backup и потом всегда сможете вернуть.

Не переустанавливайте ядро CMS

В WordPress есть кнопка «Переустановить» в админке. На Битрикс есть мастер обновления. Не нажимайте их ночью. Эти процедуры могут затереть кастомные правки в файлах ядра, переписать конфиги, обновить версию до несовместимой с вашими плагинами. Утром восстановить эти изменения будет дороже, чем починить исходную проблему.

Не лезьте в БД через phpMyAdmin

Особенно соблазнительно «просто посмотреть, что там в таблице options». Просто посмотреть редко получается. Случайный клик в «Удалить», в «Очистить таблицу», в «Изменить структуру» и сайт уже не починить без выгрузки бэкапа.

Не меняйте пароли админки

Звучит контринтуитивно: «ну если сайт лежит, может быть его взломали, надо сменить пароли». Если сайт реально взломан — смена пароля ночью без разбора инцидента ничего не даст: атакующий уже создал второй аккаунт, оставил веб-шелл, прописался в задачах cron. Смена пароля только насторожит его и заставит активировать запасные точки входа.

Если есть подозрение на взлом, правильный шаг — закрыть сайт целиком (через .htaccess Deny from all или через кнопку «Заглушка» в панели), и ждать утра. Подрядчик с холодной головой разберётся.

Не пишите в саппорт хостинга гневные сообщения

Поддержка хостинга работает по тикетам. Если вы напишете «СРОЧНО ВЕРНИТЕ САЙТ», вам ответят медленнее, чем если вы напишете «сайт example.ru не открывается с 01:15 МСК, в логах ошибка Connection refused к MySQL, нужна диагностика, за вами доплата за срочность». Конкретика разблокирует приоритет.

Какие три действия ночью обычно безопасны

Вот короткий список того, что владелец может сделать сам без риска ухудшить ситуацию.

Действие	Когда уместно	Риск
Включить заглушку через панель	Если сайт показывает ошибку или непонятный контент	Минимальный, заглушку легко снять
Продлить домен в личном кабинете регистратора	Если whois показывает истёкший срок	Нулевой, поможет в течение часа
Перезапустить пул PHP в панели	Если логи показывают «PHP-FPM not responding»	Низкий, при условии что в панели есть кнопка

Всё остальное — ждать утра. Можно поставить будильник на час и ещё раз проверить, иногда хостер сам поднимает сервер за 30-40 минут после аварии.

Как зафиксировать инцидент для подрядчика

Это та часть, которую владельцы делают редко, а зря. Если вы ночью соберёте нормальный отчёт, утренняя починка займёт 30 минут вместо 3 часов. Если не соберёте — подрядчик потратит первые два часа на восстановление картины событий по обрывкам.

Шаблон отчёта

Скопируйте в Telegram-чат с подрядчиком следующее:

ИНЦИДЕНТ
Время обнаружения: ЧЧ:ММ МСК, ДД.ММ.ГГГГ
Симптом: что показывает браузер дословно (например "502 Bad Gateway", "белый экран", "ошибка установки соединения с БД").

Доступность:
- В моём браузере: нет
- В инкогнито с мобильного 4G: нет
- downforeveryoneorjustme: лежит для всех
- curl -I: HTTP/1.1 502 Bad Gateway

Проверки:
- whois: домен оплачен до ДД.ММ.ГГГГ
- dig A: вернул правильный IP хостинга
- Личный кабинет хостинга: открывается, баланс положительный, статус сервера зелёный
- В логах: (если смогли посмотреть) последние 10 строк error_log

Что я делал ночью: ничего / включил заглушку / продлил домен.

Этот формат экономит подрядчику минимум час работы. Я лично, получив такой отчёт, могу за пять минут понять, на каком слое искать. Получив «у нас всё пропало!!!» — трачу полчаса просто на сбор тех же данных.

Что не нужно делать ночью при отчёте

Не звоните подрядчику ночью, если он не на дежурстве. У большинства фрилансеров и студий нет круглосуточной поддержки в базовом тарифе. Если у вас критичный сайт (магазин с продажами 24/7, медицинская услуга), это надо обсуждать на старте отношений и платить отдельно. Если не обсудили и не платили — подрядчик имеет полное право спать.

Адекватный канал ночью: Telegram сообщение с пометкой «не срочно, разбираемся утром». Если правда срочно — открытым текстом «критично, простой стоит N рублей в час, готов оплатить ночные часы по тарифу М, прошу подключиться».

Когда звать подрядчика немедленно

Есть три ситуации, в которых ночное вмешательство специалиста реально оправдано, и за это не жалко доплатить.

Магазин с активными продажами в эту ночь. Если у вас идёт распродажа, рекламная кампания, и каждый час простоя стоит десятки тысяч, ночной разбор окупается.
Очевидный взлом. Сайт открывается, но на нём чужой контент, реклама казино, редирект на странный домен. Каждый час откладывания означает, что Яндекс может отметить сайт в Безопасном поиске, и санкции снимать потом две недели.
Утечка данных. Если в логах видно, что кто-то скачивал базу данных, или поменялись пароли админов без вашего ведома, ночь — это последний шанс закрыть точку входа до того, как утром придут запросы от РКН.

Во всех остальных случаях разница между «починили в час ночи» и «починили в десять утра» для бизнеса ничтожная, а вот качество диагностики и риск сделать хуже спросонья — очень даже большие.

Как подготовиться, чтобы следующего раза не было

Один раз поймав ночное падение, имеет смысл сделать несколько превентивных вещей, чтобы при повторе не паниковать.

Базовый минимум

Внешний мониторинг. UptimeRobot, Site24x7, Я.Метрика «Мониторинг сайта» — всё бесплатно или дёшево, шлёт уведомление в Telegram, когда сайт упал. Узнаете не из звонка клиента, а от бота.
Резервные DNS-записи у второго провайдера. Если основной DNS лежит, переключаетесь за 5 минут.
Документ «Реквизиты доступа» в безопасном хранилище: домен, хостинг, БД, админ CMS, FTP, аналитика. Чтобы ночью не искать, кто и как заходит куда. Без этого в 3 часа ночи время на поиск пароля растягивается до часа.
Снапшоты хостинга включены. У большинства провайдеров автоматические бэкапы есть в тарифе или стоят 100 рублей в месяц. Это ваша страховка от того, что ночью кто-то нажмёт не туда.
Контакт подрядчика с понятной зоной ответственности. На моих условиях абонентки SLA «ответ в нерабочее время в течение 4 часов» входит в средний тариф, «ответ за 30 минут 24/7» — в дежурный. Подробности в тарифах.

Что обсудить с подрядчиком заранее

Какое максимальное время простоя считается допустимым.
Что делает владелец, что делает подрядчик в инциденте.
Как и куда сообщать ночью.
Сколько стоит ночное реагирование.

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

Чек-лист на холодильник

Распечатать и повесить рядом с монитором, не помешает.

[ ] Проверить, лежит ли сайт у других через downforeveryoneorjustme.com.
[ ] Сделать curl -I https://мойсайт.ru/ и посмотреть код ответа.
[ ] Открыть личный кабинет хостинга и проверить баланс, статус сервера, уведомления.
[ ] Проверить whois мойсайт.ru на срок оплаты.
[ ] Сделать dig мойсайт.ru A +short и сверить IP с хостингом.
[ ] НЕ переименовывать .htaccess, НЕ переустанавливать ядро, НЕ лезть в БД, НЕ менять пароли.
[ ] Если ничего не понятно, включить заглушку и написать подрядчику отчёт по шаблону выше.
[ ] Идти спать. Утром разобрать инцидент с подрядчиком.

Итог

Ночное падение сайта это не катастрофа, а штатный сценарий. Главное правило: не делать панических действий руками, потому что 90% попыток самопочинки делают ситуацию хуже. Лучшее, что владелец может сделать в час ночи — это собрать диагностику по шаблону выше, включить заглушку, лечь спать.

Если у вас сейчас лежит сайт и это магазин в момент продаж — напишите через форму на сайте, отвечу как смогу, обычно реакция в нерабочее время до 4 часов. Если хотите подключить нормальную поддержку с мониторингом и бэкапами заранее — смотрите тарифы и пишите. Лучше готовиться к инциденту до него, чем разбираться в три ночи.

Другие статьи на эту тему собраны в категории поддержка.

Частые вопросы