---
title: Что написать клиенту при падении сайта — шаблоны для первых 10 минут
description: Готовые сообщения клиенту при сбое сайта — первое уведомление, промежуточный статус, восстановление, проблемы оплаты, форм и признаки взлома для веб-студии.
source: https://pingvera.ru/blog/chto-napisat-klientu-pri-padenii-sayta.html
---
# Что написать клиенту при падении сайта: шаблоны для первых 10 минут

Первое сообщение о сбое должно содержать четыре вещи: **подтверждённый факт, влияние на пользователей, действие команды и время следующего обновления**.

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

Базовая формула:

> **Что происходит → на кого влияет → что мы делаем → когда сообщим снова.**

Например:

> С 14:07 сайт example.ru недоступен для посетителей. Мы подтвердили сбой из нескольких сетей и начали восстановление. Причину уточняем. Следующее обновление отправим до 14:30.

## Коротко

- Сообщайте о подтверждённом критическом сбое до того, как найдена полная причина.
- Отделяйте наблюдаемый факт от гипотезы.
- Пишите о пользовательском результате, а не о `CPU`, `502` и контейнерах.
- Всегда называйте время следующего обновления.
- Не обещайте «через пять минут всё заработает», если это не подтверждено.
- Используйте один источник статуса и одного ответственного за сообщение.
- После восстановления проверьте критическую операцию, а не только зелёный мониторинг.

## Что сделать до первого сообщения

Не отправляйте клиенту каждое одиночное срабатывание. Сначала быстро подтвердите событие.

За первые несколько минут ответственный должен:

1. открыть сайт или выполнить критическую операцию;
2. повторить проверку из другой точки или сети;
3. исключить согласованные технические работы;
4. определить предварительную критичность;
5. зафиксировать время начала по мониторингу;
6. назначить человека, который будет вести коммуникацию;
7. создать одну карточку инцидента.

Для критического P1 подтверждение не должно превращаться в получасовое расследование. Достаточно установить, что проблема реальна и влияет на пользователей. Первопричину можно честно обозначить как неизвестную.

Подробнее о порядке действий: [регламент веб-студии на первые 60 минут](https://pingvera.ru/blog/reglament-incidenta-dlya-veb-studii.html).

## Конструктор первого сообщения

Хорошее сообщение не обязано быть длинным. Оно обязано снимать пять вопросов: студия знает, масштаб понятен, работа идёт, догадки отделены от фактов, следующий контакт назначен.

## Универсальный шаблон на первые 10 минут

[Имя], с [время и часовой пояс] наблюдаем [подтверждённый симптом].

Влияние: [что сейчас не может сделать пользователь / какая часть сайта затронута].

Мы [какое действие уже выполняется].
[Причина пока не установлена / предварительно проверяем такую-то зависимость].

Следующее обновление отправим до [точное время].
Ответственный со стороны студии: [имя и контакт].

Фразу о часовом поясе стоит добавить, если клиент, студия или инфраструктура находятся в разных регионах. Внутри российского проекта обычно достаточно один раз закрепить, что все времена указаны по Москве.

## Шаблон 1. Весь сайт недоступен

С 14:07 мск сайт example.ru недоступен для посетителей.
Мы подтвердили сбой из нескольких сетей и начали восстановление.
Причину уточняем, плановых работ в это время не было.
Следующее обновление отправим до 14:30 мск.

Почему шаблон работает: он не делает преждевременных выводов, подтверждает масштаб и задаёт следующий момент связи.

## Шаблон 2. Не оформляется заказ

С 11:42 мск покупатели не могут завершить оформление заказа:
после подтверждения корзины появляется ошибка.

Каталог и карточки товаров доступны. Мы воспроизвели проблему
и проверяем этап создания заказа и связанные интеграции.

Следующее обновление — до 12:05 мск.

Вместо «сайт частично сломан» названа конкретная операция. Клиент сразу понимает бизнес-влияние.

## Шаблон 3. Не работает онлайн-оплата

С 16:18 мск не проходит оплата через [название способа].
Заказ создаётся, но покупатель не может завершить платёж.

Мы временно [включили резервный способ / скрыли проблемный способ,
чтобы не оставлять покупателя на ошибке] и проверяем обмен с платёжным сервисом.

Другие способы оплаты: [работают / также проверяются].
Следующий статус — до 16:40 мск.

Не утверждайте, что виноват банк или платёжный провайдер, пока это не подтверждено их статусом или диагностикой.

## Шаблон 4. Форма показывает успех, но заявки не приходят

Мы обнаружили, что форма [название] принимает данные на сайте,
но тестовая заявка не доходит до [почты / CRM].

Проблема подтверждена с [время]. Посетитель может видеть сообщение
об успешной отправке, поэтому сбой незаметен снаружи.

Проверяем маршрут от формы до получателя. До восстановления предлагаем
[временный канал: телефон, резервную почту, другую форму].

Следующее обновление — до [время].

Такой сбой особенно важно описать человеческим языком. Обычная доступность сайта здесь может оставаться зелёной. Разбор сценария: [почему заявки могут пропадать на работающем сайте](https://pingvera.ru/blog/ne-prihodyat-zayavki-s-sayta.html).

## Шаблон 5. Сайт недоступен только части пользователей

С [время] подтверждаем проблемы с доступом к example.ru
у пользователей из [регион / сеть / сегмент].

Из других проверенных сетей сайт открывается. Мы собираем маршруты
и диагностические данные, параллельно проверяем DNS, CDN и хостинг.

Если к вам поступят обращения, пожалуйста, передайте провайдера,
город и время ошибки — без персональных данных пользователя.

Следующее обновление — до [время].

Просите только данные, которые реально помогут диагностике. Не перекладывайте на клиента обязанность доказать, что сбой существует.

## Шаблон 6. Остановился обмен интернет-магазина с 1С

Последний подтверждённый успешный обмен сайта с 1С завершился в [время].
Новая выгрузка не обработана, поэтому цены и остатки могут быть неактуальны.

Оформление заказов [работает / временно ограничено].
Мы проверяем очередь обмена, журнал ошибок и доступность обеих сторон.

До уточнения просим [не запускать повторный полный обмен / подтверждать
остатки вручную — только если это заранее согласованный безопасный порядок].

Следующее обновление — до [время].

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

## Шаблон 7. Подозрение на взлом или подмену

В [время] мы обнаружили несогласованное изменение на сайте:
[нейтральное описание наблюдаемого факта].

Мы ограничиваем возможное влияние и сохраняем технические данные
для расследования. Масштаб и причина пока устанавливаются.

Просим до отдельного сообщения не выполнять изменения в административной
панели и не пересылать доступы в общий чат.

Следующее защищённое обновление направим [кому и по какому каналу] до [время].

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

## Шаблон 8. Зависимость от внешнего провайдера

С [время] на сайте не работает [функция].
Мы подтвердили, что сбой связан с [сервис], и получили подтверждение
от провайдера: [ссылка на официальный статус или номер обращения].

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

Следующее обновление — до [время].

Даже если первопричина находится у подрядчика клиента, студия остаётся владельцем коммуникации в пределах своей зоны ответственности.

## Шаблон 9. Клиент сообщил о проблеме раньше мониторинга

Спасибо, получили сообщение в [время].
Мы воспроизвели проблему: [краткий подтверждённый симптом].

Сейчас определяем время начала и выясняем, почему автоматическая проверка
не обнаружила событие. Восстановлением занимается [роль / имя].

Следующее обновление — до [время].
После инцидента отдельно сообщим, какую проверку добавим или изменим.

Не защищайте мониторинг и не спорьте с клиентом. Признайте факт, восстановите функцию, а затем закройте пробел в обнаружении.

## Шаблон 10. Сигнал не подтвердился

В [время] мониторинг зафиксировал кратковременное отклонение [что именно].
Повторные проверки из [количество] точек прошли успешно,
пользовательское влияние пока не подтверждено.

Мы продолжаем наблюдение до [время / количество успешных циклов].
Если событие повторится или появится влияние, откроем инцидент уровня [P2/P1]
и сообщим отдельно.

Такое сообщение нужно не для каждого ложного срабатывания, а когда клиент уже получил сигнал, событие затронуло согласованный критический объект или требует прозрачной фиксации.

## Как писать промежуточное обновление

Промежуточный статус не должен быть вариацией «мы всё ещё работаем». Добавьте новый факт или честно сообщите, что изменилось только в плане действий.

Формула:

> **Текущее влияние → что установили → что сделали → что проверяем дальше → следующий контакт.**

Обновление на 14:30 мск.

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

Сейчас проверяем [следующая ветка] и готовим [безопасное действие].
Следующее обновление — до 15:00 мск.

Если новой причины нет, так и напишите. Клиенту полезнее знать, какие версии уже исключены и когда будет следующий контакт, чем получить правдоподобную догадку.

## Как сообщить о временном восстановлении

Используйте слово «восстановлено» только после пользовательской проверки. Если команда внесла изменение, но ещё наблюдает результат, статус лучше назвать «работоспособность восстановлена, продолжаем наблюдение».

В 15:12 мск доступность сайта восстановлена.

Мы проверили главную страницу, вход и контрольное оформление заказа.
Новые проверки проходят успешно из [количество] точек.

До 16:00 мск продолжаем усиленное наблюдение. Инцидент пока не закрываем.
Если состояние останется стабильным, отправим итог и дальнейшие действия.

Как закрыть инцидент
Итоговое оперативное сообщение отвечает на пять вопросов:

1. когда функция восстановлена;
2. что именно проверено;
3. каков подтверждённый масштаб;
4. что будет дальше;
5. когда клиент получит разбор, если он нужен.

Инцидент закрыт в 16:05 мск.

Период подтверждённого влияния: 14:07–15:12 мск.
В этот период сайт был недоступен для посетителей.

Работоспособность восстановлена, контрольные проверки сайта,
формы и оформления заказа проходят успешно. Наблюдение до 16:00
не выявило повторов.

Предварительная причина: [только подтверждённый факт или
«причина уточняется»]. До [дата и время] подготовим короткий разбор
с корректирующими действиями.

Не пишите «проблема полностью исключена», если остаётся риск повтора или первопричина ещё не подтверждена.

## Сообщения для статус-страницы

Статус-страница должна быть короче личного сообщения клиенту и не содержать внутренние подробности.

### Исследуем

Исследуем недоступность сайта

С 14:07 мск часть пользователей не может открыть сайт.
Команда занимается диагностикой. Следующее обновление — до 14:30 мск.

Причина определена
Причина определена, выполняется восстановление

Мы определили источник недоступности и применяем безопасное исправление.
Сайт пока доступен нестабильно. Следующее обновление — до 15:00 мск.

Наблюдаем
Работоспособность восстановлена, продолжаем наблюдение

С 15:12 мск сайт доступен, контрольные операции проходят успешно.
Продолжаем усиленную проверку состояния.

Решено
Инцидент решён

Работа сайта восстановлена в 15:12 мск и подтверждена контрольными
проверками. Период влияния: 14:07–15:12 мск.

Статус-страница должна находиться вне той же инфраструктуры, о которой сообщает. Иначе во время падения она исчезнет вместе с сайтом. Подробнее: [зачем бизнесу статус-страница](https://pingvera.ru/blog/status-stranica-eto-doverie.html).

## Как выбрать канал

Telegram или MAX удобны для скорости, но карточка инцидента должна сохранять хронологию независимо от мессенджера. Важные решения, согласования и итог стоит перенести в Helpdesk, email или отчёт.

## Когда нужно позвонить

Звонок полезен, если:

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

После разговора отправьте письменное резюме:

Подтверждаем договорённость по звонку в 14:18 мск:
временно отключаем [функция], сохраняем [данные / журналы],
следующее обновление отправим до 14:40 мск.

Это не бюрократия, а единая версия решения для команды и клиента.

## Что нельзя писать

### «У нас всё работает»

То, что сайт открывается из офиса студии, не отменяет региональную или функциональную проблему.

Лучше:

> Из двух проверенных сетей сайт открывается. Собираем данные по затронутому региону и проверяем маршрутизацию. Следующий статус — до 12:30.

### «Это точно хостинг»

Не назначайте виновного до подтверждения.

Лучше:

> Ошибка возникает на этапе соединения с сервером. Проверяем инфраструктуру и открыли обращение провайдеру №1234.

### «Скоро всё починим»

Слово «скоро» каждый понимает по-своему.

Лучше:

> Срок восстановления пока не определён. Следующее обновление с результатом проверки резервного сценария — до 15:00.

### «Ничего страшного»

Студия не всегда знает стоимость пропущенных заказов.

Лучше:

> Затронута одна из трёх форм; основной канал заказа работает. Уточняем количество возможных пропущенных обращений.

### «Разработчик уже смотрит»

Это не описывает влияние и не назначает следующий контакт.

Лучше:

> Проблема подтверждена, восстановлением занимается дежурный разработчик. Следующее обновление — до 10:45.

### Технический поток сознания

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

## Кто должен отправлять сообщения

Для P1 назначьте одного владельца коммуникации. Он:

- получает факты от технического специалиста;
- переводит их в пользовательское влияние;
- следит за временем следующего обновления;
- обновляет статус-страницу и карточку;
- фиксирует вопросы и решения клиента;
- не мешает восстановлению параллельными запросами.

В студии из трёх человек роли могут выглядеть так:

- разработчик восстанавливает;
- руководитель студии ведёт инцидент и принимает решения;
- аккаунт-менеджер общается с клиентом и ведёт хронологию.

Если специалист работает один, он заранее использует короткие шаблоны и ставит таймер следующего сообщения. Не нужно писать идеальное письмо посреди аварии.

## Матрица согласования сообщений

Чтобы коммуникация не ждала директора, заранее определите права:

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

## Копируемая карточка коммуникации

# Коммуникация по инциденту [ID]

Сайт: [домен]
Уровень: [P1/P2/P3]
Владелец коммуникации: [имя]
Основной канал: [канал]
Контакт клиента: [имя, роль]

## Подтверждённое влияние

[Что не может сделать пользователь]

## Неизвестно

[Каких фактов пока нет]

## Первое сообщение

Время: [чч:мм]
Текст: [сообщение]
Доставка подтверждена: [да/нет]

## Обновления

| Время | Новый факт | Отправленный текст | Следующий контакт |
|---|---|---|---|
| | | | |

## Решения клиента

- [время] — [кто] согласовал [действие]

## Закрытие

Восстановлено: [время]
Проверено: [операции]
Итог отправлен: [время]
Разбор до: [дата]

Как отрепетировать коммуникацию
Проведите короткое упражнение без реального падения:

1. Руководитель выбирает сценарий: «не проходит оплата».
2. Техническому специалисту дают факты, часть информации оставляют неизвестной.
3. Ответственный за коммуникацию за пять минут пишет первое сообщение.
4. Через десять минут вводится новый факт: проблема только у одного способа оплаты.
5. Команда готовит промежуточный статус и решение о понижении уровня.
6. В конце разбирает каждую фразу: где факт, где гипотеза, где обещание.

Шаблон считается готовым, если сотрудник может заполнить его под давлением за две–три минуты.

## Как помогает Pingvera

Pingvera может дать основу для сообщения:

- точное время первого нарушения и восстановления;
- результат повторных проверок;
- затронутую проверку или бизнес-функцию;
- подтверждение из нескольких точек;
- историю события;
- доставку алерта в Telegram, email, MAX или webhook;
- независимую статус-страницу.

Но сервис не должен автоматически придумывать причину, ущерб или обещание срока восстановления. Эти части заполняет ответственная команда по подтверждённым данным.

> **Подготовьте сообщения до инцидента:** сохраните четыре основных шаблона рядом с регламентом, назначьте резервный контакт клиента и [настройте критические проверки в Pingvera](https://app.pingvera.ru/).

## Часто задаваемые вопросы

### Нужно ли сообщать клиенту, если причина ещё неизвестна?

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

### Как быстро отправлять первое сообщение?

Срок зависит от критичности и договора. Для P1 сообщение отправляют после короткого подтверждения и первичной оценки. Не устанавливайте десять минут как обязательство, если команда не может обеспечить его в согласованное сервисное окно.

### Как часто давать обновления?

Для активного P1 часто используют интервал 20–30 минут, но это пример, а не универсальное правило. Важнее назвать конкретное время и не пропустить его. Для P2 можно сообщать по контрольным точкам.

### Следует ли указывать прогноз восстановления?

Только если есть подтверждённое основание. Если его нет, укажите время следующего обновления. Ошибочный прогноз разрушает доверие сильнее, чем честное «срок пока не определён».

### Что делать, если клиент не отвечает?

Следуйте матрице эскалации: второй канал, резервный представитель, телефон для P1. Фиксируйте попытки связи. Безопасные заранее разрешённые действия выполняйте в пределах договора; решения, требующие согласия, не додумывайте за клиента.

### Нужно ли извиняться?

Можно признать неудобство без преждевременного вывода о вине: «Понимаем, что недоступность мешает приёму заказов». Главное — не заменять факты длинным извинением и не делать юридических признаний до разбора.

### Что писать, если проблему вызвал релиз студии?

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

## Главное

Клиенту не нужен прямой эфир из консоли разработчика. Ему нужны ясность, предсказуемость и следующий момент связи.

Хорошее первое сообщение коротко описывает факт и влияние, показывает действие команды и устанавливает время обновления. Хорошая серия сообщений сохраняет одну версию реальности от обнаружения до закрытия. Именно такая коммуникация позволяет студии удержать доверие даже тогда, когда сам сбой неприятен.

## Источники и дополнительное чтение

- [Atlassian: коммуникация во время инцидента](https://www.atlassian.com/incident-management/incident-communication)
- [Atlassian: как команда реагирует на инцидент](https://www.atlassian.com/incident-management/handbook/incident-response)
- [Atlassian: роли и ответственность](https://www.atlassian.com/incident-management/incident-response/roles-responsibilities)
- [Atlassian Incident Management Handbook](https://www.atlassian.com/incident-management/handbook)
- [Google SRE: Managing Incidents](https://sre.google/sre-book/managing-incidents/)
- [Pingvera: уровни критичности инцидентов](https://pingvera.ru/blog/shkala-kritichnosti-incidentov-dlya-veb-studii.html)
- [Pingvera: зачем бизнесу статус-страница](https://pingvera.ru/blog/status-stranica-eto-doverie.html)

Следующий материал курса: **«SLA технической поддержки сайта: что обещать клиенту и как это измерять»**.