Что делать, если сайт не работает - вопрос, который всплывает не в спокойной обстановке, а когда в почте уже пять писем от клиентов и в мессенджере пишет менеджер с вопросом “а мы вообще продаем сегодня?”. Первые 30 минут после падения решают, потеряете вы заказы за день или отделаетесь получасовым простоем и постом в соцсетях про технические работы. За практику разработки и поддержки сайтов я разбирал десятки таких случаев - от истекшего домена до зациклившегося n8n-сценария, который положил сервер вместе с сайтом. Дальше - план по минутам, без беготни и звонков в панике.
Первые 5 минут: сайт лёг - как быстро отличить панику от реальной проблемы
Первым делом проверяю, действительно ли сайт недоступен для всех, а не только для меня. Провайдер может банально резать доступ к конкретному IP из-за локальных проблем с DNS-кэшем на моем компьютере или роутере. Смотрю через сторонний сервис проверки доступности (типа down-for-everyone-or-just-me) и параллельно открываю сайт с телефона через мобильный интернет, а не через домашний wifi - так исключается локальная блокировка.
Второй шаг - зафиксировать код ответа сервера. Это займет 20 секунд и сразу сузит круг поиска.
curl -I https://ваш-домен.ruКод ответа обычно сразу говорит, где искать проблему:
| Код ответа | Что значит | Куда смотреть |
|---|---|---|
| 500 | Ошибка на стороне приложения | Логи PHP/CMS, последние изменения кода |
| 502 / 504 | Веб-сервер не получил ответ от бэкенда вовремя | PHP-FPM, база данных, нагрузка на сервер |
| 503 | Сервис временно недоступен | Технические работы у хостинга или перегрузка |
| Нет ответа / timeout | Сервер не отвечает совсем | Хостинг лежит, домен не резолвится или упал firewall |
Время падения записываю сразу - потом эта цифра нужна и для разговора с поддержкой хостинга, и для анализа логов nginx или php-fpm, где события идут по таймстампам.
Сайт недоступен из-за хостинга: что проверить на сервере
Если код ответа 500-504 или сервер вообще не отвечает, иду в панель хостинга или подключаюсь по SSH. Смотрю три вещи по порядку: свободное место на диске, загрузку процессора и статус ключевых сервисов.
df -h
top
systemctl status nginx php-fpm mysqlНа практике диск, забитый под ноль, встречается едва ли не чаще, чем реальные баги в коде. У одного клиента на VPS логи nginx за месяц разрослись до 40 ГБ из-за неверной ротации логов - диск заполнился, MySQL не смог писать временные файлы, и сайт лег с 502, хотя код приложения был в полном порядке. Решилось за 10 минут: почистил старые логи, настроил logrotate, перезапустил сервисы.
Если сервер шаред-хостинг и в панель зайти нельзя, открываю тикет в поддержку с точным временем падения и кодом ошибки - это ускоряет разбор в разы по сравнению с сообщением “сайт не работает, помогите”.
Домен, DNS и SSL: типичная причина, когда сайт не открывается
Если сервер живой и отвечает, а сайт всё равно не открывается у пользователей, проверяю домен и сертификат. По моей статистике это причина примерно каждого третьего обращения “сайт упал”, хотя фактически ни хостинг, ни код тут ни при чем.
Проверяю резолвинг домена:
nslookup ваш-домен.ru
dig ваш-домен.ru +shortЕсли домен резолвится не на тот IP - где-то поменяли A‑запись и забыли обновить, либо истек срок регистрации и регистратор перевел домен на техническую страницу-парковку. Отдельно смотрю дату истечения SSL-сертификата: просроченный сертификат браузер покажет как “соединение не защищено”, и для обычного посетителя это выглядит ровно как “сайт не работает”, хотя технически сервер отвечает нормально.
Был случай: клиент сменил хостинг, перенес сайт, но забыл поправить DNS-запись у регистратора - домен две недели указывал на старый сервер с истекающим SSL, пока не начали приходить жалобы от покупателей о предупреждении браузера при оплате.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Сайт упал на Tilda, WordPress или в интернет-магазине - свои нюансы
На Tilda сама платформа падает редко - у нее приличный SLA. Обычно рвется не хостинг, а кастомная обвязка: скрипт интеграции с Т‑Банк эквайрингом или расчетом доставки через СДЭК. После обновления виджета Tilda скрипт может перестать грузиться или конфликтовать с новой версией JS-движка платформы - по факту форма оплаты не срабатывает, покупатель не может завершить заказ, и для него это выглядит как “сайт не работает”, хотя лендинг открывается нормально.
На WordPress с WooCommerce чаще встречается белый экран смерти после автообновления плагина - включаю WP_DEBUG, смотрю wp-content/debug.log, и обычно там сразу видно, какой плагин выбросил fatal error. Отдельная история - интеграции с оплатой через Т‑Банк эквайринг и расчетом доставки СДЭК: если у провайдера технические работы или поменялся формат ответа API, checkout может зависать или падать с ошибкой, а остальной сайт при этом работает нормально. Разбираться приходится не с хостингом, а с логами конкретного плагина интеграции.
Практика: у клиента на WooCommerce сайт лег после автообновления плагина доставки СДЭК - новая версия плагина конфликтовала с плагином эквайринга, оба пытались перехватить один и тот же хук при оформлении заказа. Откатили плагин доставки до предыдущей версии, зафиксировали версию в composer/package-lock, чтобы автообновление больше не сработало без проверки на тестовом стенде.
Боты и n8n-сценарии, которые незаметно кладут сайт
Если на том же сервере, что и сайт, крутится aiogram-бот или n8n с активными сценариями, стоит проверить и их - это частая причина, о которой владельцы не думают в первую очередь. Сценарий с ретраями на вебхук, который уходит в бесконечный цикл, или бот, который начал спамить запросами к внешнему API без ограничения по частоте, съедает память и процессор - и сервер укладывает вместе с собой сайт, который вообще ни при чем.
Был случай: сценарий в n8n с автоматическими повторами на вебхук от CRM зациклился из-за неправильно настроенного условия выхода и за час создал около 40 тысяч запросов - сервер лег полностью, включая основной сайт на том же VPS. Проверяю через systemctl list-units --type=service и логи n8n/бота, отключаю подозрительный процесс, смотрю графики нагрузки за последний час в панели мониторинга хостинга.
Если не хочется вручную гонять curl каждые несколько минут, у меня в разделе готовых скриптов есть заготовка для автоматической проверки доступности сайта с уведомлением в Telegram - ставится за пару минут и первой сообщает о падении раньше, чем напишут клиенты.
Чек-лист по минутам: 0-30 после падения
| Время | Что делаю |
|---|---|
| 0-5 мин | Проверяю доступность со стороннего сервиса и с мобильного интернета, смотрю код ответа через curl ‑I, фиксирую время |
| 5-15 мин | Захожу в панель хостинга/SSH: место на диске, нагрузка CPU, статус nginx/php-fpm/mysql; проверяю домен и SSL через nslookup |
| 15-25 мин | Смотрю логи приложения (WP debug.log, логи Tilda-скриптов, логи n8n/бота), ищу последнее изменение перед падением |
| 25-30 мин | Если причина не найдена своими силами - открываю тикет хостингу с точным временем и кодом ошибки, параллельно публикую короткое сообщение клиентам о технических работах |
Параллельно с этим чек-листом полезно держать под рукой контакты того, кто разбирался с проектом - на подобные ситуации у меня есть отдельная услуга техподдержки на почасовой основе, но за первые 30 минут в 80% случаев причину получается найти и без сторонней помощи именно по этому плану.
Как избежать повторного простоя
После разбора причины ставлю мониторинг доступности с уведомлением в Telegram - по моей практике это сокращает время реакции с часов (когда узнают от клиентов) до пары минут. Второе - тестовый стенд (staging), на котором обновления плагинов и виджетов проверяются перед выкатом на прод, а не сразу на боевом сайте. Третье - фиксация версий критичных плагинов (эквайринг, доставка) без автообновления, чтобы новая версия не прилетела в разгар рабочего дня без проверки. Если интеграций и сценариев в проекте много - Tilda-скрипты, боты, n8n-автоматизации - держать это всё под регулярным присмотром дешевле, чем разбирать последствия каждого внепланового падения.
Чтобы сайт работал без сбоев
Техподдержка
от 15 000 ₽/мес
Подробнее →Частые вопросы
Сколько ждать, прежде чем паниковать и звонить в поддержку хостинга?
Если код ответа 502 или 504 держится дольше 2-3 минут - это уже не разовый сбой, а повод действовать. Кратковременные скачки на 10-20 секунд при пиковой нагрузке случаются и без серьезной причины, но если ошибка стабильно повторяется при повторных запросах - сразу идите проверять сервер и логи, не ждите.
Как понять, что сайт лег у всех, а не только у меня?
Проще всего проверить через сторонний сервис проверки доступности или открыть сайт с телефона на мобильном интернете, не через домашний wifi. Если у вас открывается, а у знакомых или через мобильную сеть - нет, дело точно в сервере или домене, а не в вашем оборудовании.
Нужно ли сообщать клиентам о падении сайта, если ещё не понятна причина?
Да, короткое сообщение в соцсетях или на статусной странице снимает часть напряжения и звонков в поддержку. Не обязательно объяснять техническую суть - достаточно написать, что ведутся технические работы и сайт скоро заработает, это спокойнее, чем полное молчание.
Можно ли восстановить сайт из бэкапа самостоятельно, без разработчика?
Если у вас настроены регулярные бэкапы и есть доступ к панели хостинга - да, откат к последней рабочей версии через штатный интерфейс хостинга обычно занимает 10-15 минут. Сложнее, если бэкап делали давно, база данных с тех пор изменилась (новые заказы, товары), и откат отменит эти изменения - тогда лучше сначала выгрузить свежие данные заказов отдельно, а уже потом накатывать бэкап.