Что менять на странице статуса после первого реального сбоя?
Первый раз, когда StillOnline будит в 2 ночи, адреналин дотащит. Через неделю вы забудете, какой компонент упал, сработал ли Telegram раньше email и что обещали в треде инцидента. Для соло-фаундера это нормально — и лечится без найма SRE-команды.
Лёгкая ретроспектива после инцидента для indie SaaS — не 20-страничный blameless postmortem. Три привычки: компоненты, совпадающие с тем, как клиенты видят сбой, алерты владельца, которые вы реально читаете, и runbook, которому доверите себя через месяц. StillOnline даёт хронологию и внешние проверки; честность — ваша.
Краткий ответ
В течение 48 часов после первого prod-простоя обновите: (1) компоненты страницы статуса, чтобы подписи совпадали с клиентскими поверхностями, (2) алерты владельца — убедитесь, что бот StillOnline в Telegram или выбранный канал сработал на DOWN и восстановление, (3) runbook на одну страницу с health URL, откатом деплоя и заготовками текста инцидента. StillOnline помечает проверку DOWN после двух неудачных проверок подряд — ~10 минут при интервале 5 мин на Free (тарифы). На тон без обвинений — культура postmortem от Google SRE; на cadence для клиентов — handbook Atlassian по инцидентам.
Ретроспектива за 48 часов (версия для соло)
Заблокируйте 30–45 минут. Комитет не нужен.
| Шаг | Результат |
|---|---|
| 1 — Таймлайн | 5 пунктов: время алерта, симптом у клиента, root cause, фикс, время resolve (UTC) |
| 2 — Компоненты | Что сломалось vs за что ругали клиенты |
| 3 — Алерты | Канал владельца опередил первое DM в поддержку? |
| 4 — Коммуникации | Обновления статуса совпали с состоянием проверки? |
| 5 — Одно изменение | Одна структурная правка на следующий раз |
Документ — рядом с шаблоном инцидента, не в чате, который уедет вверх.
Привычка 1 — поправить компоненты страницы статуса
Компоненты — подписи, которые клиент сканирует под стрессом. После первого сбоя несовпадение имён даёт «API зелёный, а логин не работает».
| До первого инцидента | После |
|---|---|
| Один общий «API» | Web app, API, Webhooks, если падают по-разному |
| Маркетинг в одной строке с API | Отдельные проверки на Pro, когда URL расходятся |
| Вендор без имени | Строка Stripe / Auth0 со ссылкой на их статус — сторонние статусы |
Принципы дизайна: компоненты страницы статуса. StillOnline отражает UP/DOWN по зарегистрированным URL — компоненты должны мапиться 1:1 на проверки или на честные ручные инциденты при падении зависимости.
Free = один URL; подсистемы сведите в JSON /health или Pro (9 $/мес) до 10 URL, когда поверхности расходятся — какой тариф.
Привычка 2 — настроить алерты владельца (не больше шума)
Первые сбои быстрее дашбордов показывают ложные срабатывания и усталость от алертов.
| Проверка | Действие |
|---|---|
| Telegram через бота StillOnline | Повторите Connect Telegram в настройках, если сообщения запаздывали |
| Только email на Free | Рассмотрите Telegram для push на телефон — на Free всё равно один канал |
| Алерт раньше, чем вы заметили пользователей | Хорошо — интервал оставьте; поправьте health URL, если проверка врала |
| Жаловались раньше алерта | Направьте проверку на авторитетный /health; ложные срабатывания |
На Free StillOnline интервал 300 с; debounce — две неудачи до DOWN. Pro — 60–300 с на проверку, когда нужен быстрее сигнал без дублирования вендоров.
Привычка 3 — runbook, который вы откроете
Runbook — не бюрократия, а файл, когда мозг offline.
Минимум разделов:
- Health URL + однострочный
curl(быстрый старт) - Ссылка на проект StillOnline + публичный
/s/...для макросов поддержки - Откат — команда или «redeploy previous» на платформе
- Фазы инцидента для копипасты — шаблон поста
- Cadence обновлений — например каждые 30 мин до стабилизации — правило пяти минут
Ссылку на runbook — на домашний экран телефона или закреп в Telegram, не на странице 47 в Notion.
Привычки коммуникаций (урок первого сбоя)
| Урок | В следующий раз |
|---|---|
| Пост запоздал | Заготовка Investigating в шаблоне |
| Обновления размыты | Имя компонента и время следующего апдейта UTC |
| Поддержка повторяла «лежит?» | URL статуса в шапке макроса |
| В Resolved не было длительности | Resolved с минутами простоя и одной строкой причины |
Подписчики публичной страницы StillOnline получают email при публикации обновлений инцидента — отдельно от алертов владельца Slack/Telegram/email (подписчики vs владелец).
Чего не делать после первого сбоя
- Покупать enterprise incident tooling до второго повтора той же дыры.
- Добавлять пять мониторов, не починив health URL, который врал «зелёный».
- Обещать «24/7» на странице статуса, пока алерты владельца ненадёжны.
- Пропускать ретроспективу — «разовая история»; второй сбой обычно рифмуется с первым.
Чеклист StillOnline (скопируйте после инцидента)
- Проверка бьёт в
GET /health→ 200 после фикса — внешнийcurl. - Обновите компоненты под то, что сломалось.
- Протестируйте алерт владельца на staging-сбое — не в prod на пике.
- Короткий Resolved, если клиенты смотрели тред.
- Запланируйте разбор Pro, если нужен второй URL или приватная staging-страница.
Связанные материалы
- Шаблон поста об инциденте для indie SaaS
- Компоненты страницы статуса: дизайн для клиентов
- Cadence обновлений инцидента: правило пяти минут
- Ложные срабатывания uptime-алертов: настройка
FAQ
Генерирует ли StillOnline post-mortem после сбоя автоматически?
Нет. StillOnline хранит историю проверок, состояние и ваши посты об инцидентах. Для клиентского текста — этот список привычек плюс шаблон инцидента; внутренний таймлайн — в runbook.
Как скоро обновить компоненты StillOnline после первого downtime?
В течение 48 часов, пока свежо в памяти. Компоненты должны отражать проверки или честные ручные инциденты — дизайн компонентов. Расхождение подписей бьёт по доверию быстрее второго сбоя.
Telegram-алерт StillOnline пришёл поздно — что менять?
Проверьте Connect Telegram и официального бота StillOnline в настройках. Если алерт отставал от жалоб пользователей — направьте проверку на стабильный /health и учтите debounce (две проверки по 5 мин на Free) — настройка ложных срабатываний.
Добавлять ли больше URL-проверок в StillOnline после одного инцидента?
Если web и API падали независимо, Pro (9 $/мес) — до 10 URL. Если один /health врал — сначала почините handler — дизайн health endpoint — потом умножайте мониторы.
Как часто публиковать обновления инцидента в StillOnline при следующем сбое?
Держите фиксированный cadence — многие indie-команды раз в 30 минут или чаще при смене состояния — cadence обновлений. Алерты владельца говорят вам, что сломалось; посты инцидента — клиентам, что вы знаете.