Как сделать страницу статуса без кода: что на ней нужно

Страница статуса собирается из описания: перечислите компоненты продукта, состояния, в которых они бывают, и формат записи об инциденте. Билдер соберёт страницу примерно за минуту и опубликует её на адрес вида <slug>.zugo.run, то есть отдельно от вашего продукта. Сборка стоит 6 кредитов.

Страница статуса это инструмент коммуникации, переодетый в мониторинг. Её ценность почти целиком в словах, которые вы пишете во время сбоя, а не в зелёных кружках. Кружки успокаивают, объясняет текст.

Что на самом деле нужно на странице статуса?

Человек открывает её в одном состоянии: что-то сломалось, и он хочет понять, у него или у вас. Четыре элемента отвечают на это, всё остальное откладывает ответ.

Одно общее состояние сверху, словами. «Все системы работают» или «Частичный сбой» крупно и выше всего остального. Большая часть посетителей читает только эту строку и закрывает вкладку.

Список компонентов, понятных снаружи. API, веб-приложение, дашборд, вебхуки, отправка писем. Не ваши внутренние имена сервисов: пользователь не знает, что «шлюз-2» это то, через что проходит его загрузка файлов.

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

История. Прошедшие инциденты с итогом. Эту часть читают не пользователи в момент сбоя, а покупатели и специалисты по безопасности на этапе выбора. Пустая история выглядит как страница, которую никто не ведёт.

Почему страница статуса должна жить отдельно от продукта?

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

Публикация на отдельном адресе вида <slug>.zugo.run решает половину задачи: страница не зависит от вашего сервера и вашего деплоя. Если вы подключаете свой домен, разумно использовать поддомен вида status.вашдомен, и как это делается, описано в статье про собственный домен.

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

Второе следствие: страница статуса должна быть лёгкой. Её открывают в момент проблем, иногда с плохого мобильного интернета, иногда с той самой сети, которая и есть причина. Каждый лишний мегабайт делает её хуже в её единственной работе.

Как описать страницу статуса в промте?

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

Собери страницу статуса для [название продукта].
Сверху: одно общее состояние крупно и время последнего обновления.
Ниже: список компонентов [API, Веб-приложение, Дашборд, Вебхуки,
Почта], у каждого метка состояния: Работает, Замедление,
Частичный сбой, Крупный сбой, Обслуживание. Цветовая кодировка,
но состояние обязательно подписано словом, не только цветом.
Ниже: «Активные инциденты», у каждого заголовок, затронутые
компоненты, серьёзность и список обновлений с датой и временем
в обратном порядке.
Ниже: «История инцидентов», сгруппирована по месяцам, свёрнута.
Шапка: ссылка на [адрес продукта].
Оформление: простое и быстрое, высокий контраст, без анимации,
читается на телефоне с плохой связью.

Строка про подпись словом рядом с цветом это не формальность. Часть посетителей не различает красный и зелёный, и страница, где состояние закодировано только цветом, для них не работает вообще. Как формулировать такие требования, разобрано в гайде как писать промт для ИИ-билдера.

Как публиковать инцидент, когда всё горит?

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

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

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

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

Стоит ли писать процент аптайма?

Только если вы его считаете, а не оцениваете. Написанные руками «99,98%» это обязательство, которое вам предъявят при первой же серьёзной проверке со стороны корпоративного клиента.

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

Честная альтернатива: показывать историю инцидентов с длительностью каждого. Это те же данные, только проверяемые, и они производят лучшее впечатление на человека, который умеет читать такие страницы.

Сколько кредитов стоит страница статуса?

Zugo списывает кредиты за действия. Сборка стоит 6 кредитов, правка 3, многостраничная платформа 12 за первые три страницы и по 3 за каждую следующую.

Здесь важна арифметика на дистанции: если вы публикуете инциденты правками, каждое обновление внутри инцидента это отдельные 3 кредита. При трёх сбоях в месяц с тремя обновлениями каждый это 27 кредитов, и в этот момент вариант с базой становится дешевле.

Free даёт 5 кредитов, меньше одной сборки. Pro стоит $25 в месяц и даёт 200 кредитов, Business стоит $99 в месяц.

Как писать текст инцидента?

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

Не пишите причину, пока не уверены. Раннее «проблема с провайдером» превращается через час в неловкое «на самом деле это была наша ошибка при выкладке». Формулировка «выясняем причину» ничего не стоит и всегда остаётся верной.

Пишите на языке пользователя, а не инженера. «Не проходит загрузка файлов больше 10 МБ» понятно, «деградация очереди воркеров» непонятно никому снаружи. Внутренние детали годятся для итогового разбора, а не для строки во время сбоя.

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

Когда честнее взять готовый сервис?

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

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

Собственная страница выигрывает в другом: она стоит одну сборку, живёт на вашем домене, выглядит как ваш продукт и не ограничивает число компонентов тарифом. Для внутренних сервисов, для команд без выручки и для продуктов на ранней стадии это разумный выбор.

Ещё один аргумент в пользу своей страницы: код принадлежит вам и выгружается в GitHub, поэтому переезд на что-то другое позже не превращается в переписывание с нуля.

С чего начать?

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

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

Опишите свои компоненты и состояния одним абзацем на zugo.dev и заведите привычку писать в статус раньше, чем в поддержку напишут вам.