Post-mortem для indie SaaS: страница статуса и коммуникации

Страница статуса уже «resolved», а клиенты спрашивают, что сломалось. Post-mortem превращает переписку в Slack в blameless-запись для публичной страницы и письма подписчикам. Разберём, когда хватит короткой заметки, а когда нужен полный отчёт, как собрать UTC-таймлайн из истории StillOnline и пройти чеклист из 30 пунктов без enterprise SRE.

Краткий ответ

Во время инцидента — короткие заметки; в течение 24–48 ч после стабилизации — blameless post-mortem. Временные метки — из алертов и постов StillOnline. Публично: impact, таймлайн, root cause простым языком, SMART-действия. StillOnline ставит DOWN после двух провалов (~10 мин на Free), но отчёт не пишет сам.

Живые апдейты: шаблон incident post · каденс обновлений.

1. Post-mortem или короткая заметка — когда что

Делайте: заметки < 150 слов — impact, статус, время следующего апдейта. Не спекулируйте про root cause до факта.

Первый пост на StillOnline — ~5 мин после признания impact. Обновления каждые 15–30 мин.

2. Таймлайн, impact, root cause, действия

UTC. Источники — алерты владельца и посты StillOnline.

Impact: «EU не могли экспортировать CSV 51 минуту» лучше, чем «degraded performance». Действия: «Добавить проверку StillOnline на /ready при исчерпании пула БД — Алекс — 2026-06-24 — P1».

Копируйте время из StillOnline, не из памяти через неделю.

3. Что выносить на публичную страницу статуса

Посты инцидентов StillOnline — для клиентов. Post-mortem — финальный пост; автогенерации нет. См. привычки после первого инцидента.

4. Письма подписчикам

Алерты владельца StillOnline ≠ email подписчиков страницы статуса.

1. Во время сбоя — текст совпадает со страницей.
2. После resolve — итоговое письмо или финальный пост с post-mortem.
3. Без внутренних обвинений в публичной рассылке.

5. Чеклист из 30 пунктов (blameless)

Ключевое: resolve на странице → review за 48 ч → UTC-таймлайн → время алерта StillOnline DOWN → root cause без персоналий → SMART-действия с owner и датой → публичная версия без секретов → подписчики уведомлены → проверка StillOnline на customer-critical URL.

Полный список — в runbook команды; не закрывайте SEV-1 без одного структурного P1-fix.

Что дальше

После следующего инцидента — post-mortem за 48 ч с метками StillOnline. Финальный пост + подписчики.

Дашборд StillOnline — убедитесь, что health URL = то, от чего зависят клиенты.

FAQ

Через сколько публиковать post-mortem с данными StillOnline?

24–48 ч. Цель — в финальном incident update.

StillOnline сам пишет post-mortem?

Нет. Есть проверки, алерты и ваши посты — экспортируйте время в шаблон.

Incident post и post-mortem в StillOnline — в чём разница?

Короткие апдейты во время сбоя vs blameless-итог после resolve.

Имена инженеров на публичной странице?

«Команда разработки». Blameless — про систему.

Подписчики получат post-mortem?

Да, если опубликовать как новый incident post.

Root cause у вендора?

Прямо, со ссылкой на их status, плюс ваша скорость детекта.

Соло-фаундер — можно упростить?

Минимум: таймлайн, root cause, одно owned-действие.