Три часа ночи. Телефон вибрирует. Slack заполнен сообщениями от поддержки. Сайт лежит, и вы понятия не имеете почему. Знакомая ситуация? Если нет — значит, вам либо очень повезло, либо вы ещё просто не сталкивались. Downtime случается со всеми: от стартапа на одном VPS до AWS, у которого рушились целые регионы.
Рано или поздно ваш сайт ляжет. Разница между 5-минутным инцидентом и 5-часовым — в подготовке: мониторинг, runbook'и, автоматизация. Ниже — 10 самых частых причин downtime и конкретные шаги, чтобы каждую из них предотвратить или минимизировать.
Сколько стоит downtime
Перед тем как углубляться в технические причины — несколько цифр, чтобы понять масштаб проблемы. По данным Gartner, средняя стоимость минуты IT-downtime — $5,600. Для e-commerce компании с оборотом $50K в день час простоя — это ~$2,000 прямых потерь. Но прямые потери — только верхушка айсберга.
Потеря выручки. Пользователи не могут купить, подписаться, оплатить. Каждая минута — это конкретные деньги, которые ушли к конкурентам.
SEO-урон. Google понижает сайты, которые регулярно недоступны. Несколько часов downtime могут обрушить позиции, которые вы выстраивали месяцами.
Потеря доверия. 88% пользователей не вернутся на сайт после плохого опыта. Один серьёзный инцидент меняет восприятие бренда.
Стоимость восстановления. Время инженеров на диагностику, откат, hotfix, пост-мортем. Это часы дорогого рабочего времени, которые могли бы уйти на развитие продукта.
Причина #1: Перегрузка сервера
Самая банальная и самая частая причина. Сервер получает больше трафика, чем может обработать — CPU упирается в 100%, память заканчивается, запросы начинают складываться в очередь и таймаутиться. Особенно характерно для маркетинговых кампаний, когда лендинг внезапно получает в 10 раз больше трафика.
Как предотвратить: настройте автоскейлинг, если инфраструктура позволяет. Для VPS — выберите план с запасом по ресурсам. Используйте CDN для статики, чтобы разгрузить origin-сервер. И главное — мониторьте response time. Рост latency — первый признак того, что сервер начинает захлёбываться, задолго до полного отказа.
Причина #2: Ошибка при деплое
"Работает на моей машине" — фраза, после которой продакшн падает. Неудачный деплой — вторая по частоте причина downtime. Сломанная миграция базы данных, баг в новом коде, пропущенная переменная окружения, несовместимость версий зависимостей — всё это приводит к 500-м ошибкам или полной недоступности.
Что делать: деплойте через CI/CD с автоматическими тестами. Используйте canary deployments или blue-green: обкатайте новую версию на 5% трафика, прежде чем давать 100%. Всегда имейте быстрый rollback — возможность откатиться на предыдущую версию за 60 секунд. И обязательно настройте мониторинг, который проверяет сайт сразу после деплоя.
Причина #3: Сбой хостинг-провайдера
Даже крупные провайдеры падают. AWS us-east-1, Google Cloud, Hetzner — у всех случаются аварии. Когда падает провайдер, вы бессильны: остаётся только ждать восстановления и коммуницировать с пользователями.
Минимизация риска: для критичных приложений — multi-cloud или multi-region deployment. Для остальных — хотя бы regular backups, которые можно развернуть на другом хостинге за час. Используйте мониторинг из нескольких регионов, чтобы отличить глобальный сбой провайдера от локальной сетевой проблемы.
Причина #4: DNS-проблемы
DNS — самый недооценённый single point of failure. Если DNS не резолвит ваш домен — сайт недоступен, даже если серверы работают идеально. Типичные сценарии: истёк домен (забыли продлить), DNS-провайдер лежит, кто-то случайно удалил A-запись, TTL слишком большой для быстрого переключения.
Защита: используйте надёжный DNS-провайдер с SLA (Cloudflare, AWS Route53). Включите auto-renewal для доменов. Настройте DNS-мониторинг, чтобы ловить изменения записей и резолвинг-ошибки до того, как их заметят пользователи. Установите разумный TTL (300-600 секунд) — достаточно короткий для быстрого failover, но не настолько короткий, чтобы генерировать лишний трафик.
Причина #5: Истёкший SSL-сертификат
В 2026 году без HTTPS не работает ничего. Истёкший SSL-сертификат превращает ваш сайт в страшную страницу "Your connection is not private", которую 99% пользователей не пройдут. Хуже того: мобильные приложения, API-интеграции и вебхуки просто перестают работать — они не показывают предупреждение, а молча отказывают.
Решение: используйте Let's Encrypt с автоматическим обновлением. Но не полагайтесь только на автоматику — она ломается (проблемы с DNS-верификацией, изменённый firewall, обновлённый certbot). Настройте SSL-мониторинг с уведомлением за 30 дней до истечения. Так у вас будет месяц на починку автоматики.
Причина #6: DDoS-атака
Distributed Denial of Service — когда тысячи ботов одновременно заваливают ваш сервер запросами. Результат — легитимные пользователи не могут пробиться. DDoS-атаки стали дешёвыми и доступными: "стрессеры" продаются за $10 в месяц, и атаковать могут кого угодно.
Что помогает: CDN с DDoS-защитой (Cloudflare, AWS Shield). Rate limiting на уровне nginx или API gateway. Geo-blocking, если ваша аудитория в конкретных регионах. И, опять же, мониторинг — резкий скачок response time и рост 5xx ошибок на нескольких endpoints одновременно — характерный паттерн DDoS, который мониторинг поймает за минуту.
Причина #7: Сбой базы данных
База данных — сердце большинства веб-приложений. Если она недоступна, API возвращает 500, страницы не рендерятся, пользователи видят ошибки. Частые причины: переполнение диска, deadlock, слишком долгая миграция с блокировкой таблицы, поломка репликации.
Практика: мониторьте место на диске (алерт при 80% заполнения). Используйте connection pooling, чтобы не исчерпывать максимум подключений. Тестируйте миграции на staging с реальным объёмом данных. Настройте реплику для read-запросов — если primary падает, приложение хотя бы может читать данные.
Причина #8: Зависимость от третьего сервиса
Ваше приложение загружает шрифты с Google Fonts, аналитику с Mixpanel, оплату через Stripe, авторизацию через Auth0. Если любой из этих сервисов тормозит — ваш сайт тормозит. Если он лежит — ваш сайт может лечь вместе с ним, если зависимость блокирующая.
Защита: загружайте третьи сервисы асинхронно, чтобы их медленность не блокировала рендеринг страницы. Реализуйте circuit breaker pattern — если зависимость не отвечает 3 раза подряд, переключайтесь на fallback (кэш, дефолтные значения, graceful degradation). Мониторьте не только свой сайт, но и ключевые third-party endpoints.
Причина #9: Неправильная конфигурация
Одна опечатка в конфиге nginx — и весь трафик уходит в 404. Неправильный environment variable — и приложение подключается к dev-базе вместо production. Удалённое правило firewall — и порт 443 заблокирован. Configuration drift — когда prod постепенно расходится со staging — один из самых коварных источников downtime.
Контрмеры: инфраструктура как код (Terraform, Ansible). Все конфиги в git с code review. Никаких ручных правок на продакшн-серверах. Валидация конфигов перед применением (nginx -t, docker compose config). И мониторинг, который проверяет не только "сайт отвечает", но и конкретные pages/endpoints после каждого изменения конфига.
Причина #10: Нехватка ресурсов (disk, memory, connections)
Медленная утечка памяти, растущие лог-файлы, не очищенный /tmp, таблица базы данных, которая разрослась до 50ГБ — всё это тикающие бомбы. Работает месяцами, а потом в самый неподходящий момент диск заполняется на 100%, и всё ложится.
Превентивные меры: алерты на диск, память и CPU задолго до исчерпания. Logrotate для логов. Scheduled cleanup jobs для временных файлов и старых данных. Периодический HTTP-мониторинг с проверкой response time — рост latency часто сигнализирует о том, что ресурсы подходят к лимиту.
Как быстро обнаружить downtime
Единственный способ узнать о downtime быстрее пользователей — внешний мониторинг. Не внутренний (он упадёт вместе с сервером), а внешний, который проверяет ваш сайт из нескольких независимых точек.
Вот что минимально нужно настроить:
HTTP-мониторинг основных страниц. Главная, логин, ключевой пользовательский путь. Интервал — 1 минута, проверка из 3+ регионов. AtomPing поддерживает до 50 мониторов на бесплатном плане.
DNS-мониторинг. Проверка, что ваш домен резолвится в правильный IP. DNS-мониторинг поймает проблемы с DNS раньше, чем они станут полным отказом.
SSL-мониторинг. Уведомление за 30 дней до истечения сертификата. TLS-проверки предотвращают один из самых глупых и легко предотвратимых типов downtime.
Публичная status page. Когда downtime всё-таки случается — прозрачная status page снижает нагрузку на поддержку и сохраняет доверие пользователей. "Мы знаем о проблеме и работаем над ней" — лучше молчания.
Чек-лист: минимальная защита от downtime
Независимо от масштаба вашего проекта, эти базовые меры значительно снижают риск и время восстановления:
1. Внешний мониторинг с алертами в Slack/Telegram/email — узнаёте о проблемах за 1-2 минуты.
2. Регулярные бэкапы, проверенные на восстановление — не просто "бэкапим", а "проверяли, что можно восстановить".
3. CI/CD пайплайн с автоматическими тестами — баги ловятся до продакшна.
4. Быстрый rollback (откат за 60 секунд) — если деплой сломал, откатываем без паники.
5. SSL auto-renewal + мониторинг истечения — исключает самый глупый тип downtime.
6. DNS у надёжного провайдера + DNS-мониторинг — защита от невидимого single point of failure.
7. Алерты на ресурсы (disk > 80%, memory > 85%) — предупреждение до того, как лимит достигнут.
8. Документированный incident response — когда всё горит, план действий спасает от хаоса.
Downtime неизбежен — но catastrophic downtime предотвратим. Разница между компанией, которая теряет 10 минут, и компанией, которая теряет 10 часов — не в везении, а в подготовке. Мониторинг, бэкапы, автоматизация и чёткий план реагирования — вот четыре столпа, на которых строится устойчивая инфраструктура.
FAQ
What is website downtime?
Website downtime is any period when your site or application is inaccessible to users. This includes full outages (site doesn't load at all), partial outages (some pages or features broken), and performance degradation so severe that the site is effectively unusable. Even a 30-second outage can cost revenue if it hits during peak traffic.
What is the most common cause of website downtime?
Server and hosting failures account for roughly 40% of all downtime events. This includes overloaded servers, disk failures, memory exhaustion, and hosting provider outages. The second most common cause is human error during deployments — pushing broken code or misconfiguring infrastructure accounts for about 25% of incidents.
How much does website downtime cost?
It varies wildly by business size. For a small e-commerce site doing $10K/day, one hour of downtime costs roughly $400. For Amazon, a one-minute outage reportedly costs $220,000+. Beyond direct revenue loss, factor in SEO impact (Google demotes unreliable sites), customer trust erosion, and engineering time to diagnose and fix.
How can I prevent website downtime?
No single measure eliminates downtime entirely, but you can minimize it with: reliable hosting with SLA guarantees, redundant infrastructure (multiple servers, load balancing), proactive monitoring with instant alerts, automated failover for critical services, staging environment testing before production deploys, and regular infrastructure updates (OS patches, SSL renewals).
How quickly should I detect downtime?
Ideally within 1-2 minutes. The gap between when downtime starts and when you learn about it is the most expensive part — you're losing users without even knowing. Monitoring tools like AtomPing check your site every 30-60 seconds from multiple regions, so you typically get alerted within 1-3 minutes of an outage starting.
Does downtime affect SEO rankings?
Yes. Google's crawler visits your site regularly, and if it encounters errors or timeouts, it notes the reliability issue. Short outages (a few minutes) rarely impact rankings, but repeated or prolonged downtime signals to Google that your site is unreliable. Extended outages of several hours can cause pages to temporarily drop from search results.