Как сделать страницу статуса для SaaS

ProductDenis Povarov12 октября 2026 г.

Страница статуса для SaaS — это несколько решений: что на ней показывать, когда монитор доступности должен объявлять сбой, как писать обновления по инцидентам и где держать саму страницу. Я разберу их на примере страницы статуса и мониторов доступности, которые только что добавил в Kookee, а скриншоты сделаны в Lumen — выдуманном продукте для аналитики из моего демо-проекта. Мониторы пришлось проверить в деле раньше, чем я планировал: пока делал скриншоты, я по ошибке выключил портал демо-проекта, и два его монитора заметили это через 68 и 78 секунд.

Что показывать на странице статуса

Полезная страница статуса состоит из четырёх частей:

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

Над ними — одна строка о состоянии всей страницы, чтобы посетитель, которому нужно только понять, не на его ли стороне проблема, мог на ней и остановиться. На странице Kookee это «Все системы работают», «Незначительные перебои в работе», «Серьёзный сбой» или «Идёт обслуживание», и строка вычисляется по компонентам и открытым инцидентам.

Страница статуса Lumen: незначительные перебои в работе, активный инцидент «Scheduled email reports are delayed» и обслуживание «Database upgrade» 18 октября

Называйте компоненты так, как их называют клиенты

Компонент — это то, что клиент может сверить с тем, что видит сам. У Lumen это Dashboards, Data ingestion, Public API, Email reports и Help center. Обработчиков очередей и базы данных в списке нет: никто за пределами команды не знает, что они делают. На скриншоте выше выдуманный инцидент Lumen затрагивает компонент Email reports, а ниже на странице у этого компонента статус Degraded performance («Снижена производительность»). Клиент, которому не пришёл отчёт по расписанию, сопоставит это с тем, что видит сам.

Раздел компонентов на странице статуса: пять компонентов со статусами и 90 дневными полосками доступности, ниже — один прошедший инцидент

На бесплатном тарифе Kookee можно завести 10 компонентов, на Pro — 50. У каждого компонента по полоске на день, окрашенной по худшему статусу за этот день: 90 полосок на широком экране, 30 последних на телефоне и ни одной, если выключить Показывать доступность.

Решите, когда сайт действительно недоступен

Монитор доступности запрашивает URL по расписанию и должен решить, когда ошибка — это уже сбой. В Kookee правило такое: три неудачные проверки подряд. После неудачной проверки монитор проверяет снова через 20 секунд, так что три неудачи укладываются примерно в 40 секунд при любом интервале, а если каждая проверка ждёт до конца тайм-аута, то дольше. Интервал решает только, как скоро случится первая неудача: на Pro и Ultra монитор может проверять каждую минуту, на бесплатном тарифе — не чаще раза в пять минут. Одна неудачная проверка ничего не запускает, а две удачные подряд возвращают монитор в рабочее состояние.

Вот как это выглядело, когда я выключил демо-портал. Портал выключился в 08:02:36 UTC. Мониторы объявили сбой в 08:03:44 и 08:03:54, каждый после трёх ответов 404, и монитор центра помощи открыл черновик инцидента «Help center is down». Портал снова включился в 08:04:18, мониторы вернулись в рабочее состояние в 08:05:24 и 08:05:34, а черновик закрылся сам и так и не попал на публичную страницу. Сбой, который записал каждый монитор, длился примерно столько же, сколько настоящий, и отставал от него примерно на минуту с обеих сторон: такова цена того, что сбой сначала подтверждается.

Страница монитора: доступность за 24 часа, 7, 30 и 90 дней, график времени ответа, последняя проверка и прошедший сбой с его инцидентом

Ещё несколько правил решают, можно ли верить монитору. Монитор, у которого ещё не было ни одной удачной проверки, только оповещает команду: опечатка в URL не должна показывать клиентам сбой, которого не было. Если монитор хоть раз был в рабочем состоянии, то при сбое он ставит своему компоненту «Серьёзный сбой», как бы он ни был настроен, — чтобы страница не писала «Работает», пока проверка не проходит. А если у компонента идёт плановое обслуживание, монитор придерживает сбой до конца окна обслуживания.

Что происходит дальше, вы выбираете для каждого монитора: Только оповещение, Создать черновик инцидента или сразу Опубликовать инцидент. Черновик даёт готовый инцидент, который можно проверить и переписать до публикации. Публиковать сразу имеет смысл для URL, сбой которого всегда задевает клиентов, например для health check вашего API.

Пишите обновления, по которым понятно, что делать

Инцидент — это заголовок и серия обновлений. У каждого обновления есть статус, и для инцидентов в Kookee их четыре: «Выясняем причину», «Причина найдена», «Наблюдаем» и «Решено». Заголовок должен называть то, что замечают клиенты («Дашборды загружались медленно»), а не причину.

Каждое обновление должно отвечать на следующий вопрос клиента. В решённом инциденте Lumen ниже первое обновление говорит, что затронуто, и с цифрой: «Некоторые дашборды загружаются дольше 20 секунд». Обновление «Причина найдена» называет причину, когда она известна: «Утренний релиз изменил запросы для больших графиков воронок». «Наблюдаем» говорит, за чем команда следит, прежде чем считать проблему решённой: «Следим за временем загрузки ближайший час». Инцидент с email-отчётами выше добавляет то, о чём клиенты тоже спрашивают, — не пропало ли что-нибудь: «Задержанные отчёты всё равно будут отправлены, ни один не потерян».

Публичная страница решённого инцидента с четырьмя обновлениями, сначала новые: «Решено», «Наблюдаем», «Причина найдена» и «Выясняем причину»

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

Объявляйте обслуживание до его начала

В Kookee окно обслуживания становится публичным, как только вы его запланировали, — в разделе «Предстоящее обслуживание». С начала и до конца окна обслуживание идёт, а у его компонентов статус «На обслуживании». Потом оно завершается само: запускать и останавливать его вручную никому не нужно. Напишите, что клиенты могут заметить и как долго, как в обновлении базы данных у Lumen: «Во время окна дашборды и API могут до 15 минут отвечать медленно».

Как Kookee считает доступность

Простоем Kookee считает только время в статусе «Серьёзный сбой». Сниженная производительность и частичные сбои окрашивают полоску дня, но на процент не влияют. Процент считается за 90 дней, начиная с момента, когда компонент добавили, поэтому более ранние дни серые, а не зелёные. Он округляется вниз: 99,996% показывается как 99,99%, но никогда как 100,00%.

Держите страницу отдельно от того, о чём она сообщает

Страница статуса, которую отдаёт та же система, что она описывает, падает вместе с ней. Готовая страница Kookee находится по адресу <your-project>.kookee.dev/status, отдельно от ваших серверов. Если она нужна на вашем домене, ту же страницу можно собрать из @kookee/react/status: StatusHeadline и StatusOverview для страницы, StatusIncidentArticle для каждого инцидента. Отдавайте её не из того приложения, о котором она сообщает, а, например, со статического хостинга, и пусть браузер берёт статус из API Kookee:

import { useStatus } from '@kookee/react';
import { StatusHeadline, StatusOverview } from '@kookee/react/status';

const { data: status } = useStatus({ refreshSeconds: 60 });
if (!status) return null;

<StatusHeadline status={status} />
<StatusOverview status={status} incidentHref="/status/incidents/{id}" />

Запросы статуса не входят в месячный лимит запросов к API. В любом из моих четырёх стартовых шаблонов KOOKEE_STATUS=true добавляет /status и страницу для каждого инцидента. Тот же риск есть и у самого Kookee: страница и компоненты берут статус из API Kookee, поэтому, если этот API недоступен, они тоже не загрузятся.

Как настроить это в Kookee

Откройте раздел Страница статуса, перейдите на вкладку Компоненты и нажмите Добавить компонент для каждой части продукта, которую видят клиенты.
Откройте раздел Мониторинг доступности, нажмите Добавить монитор, введите URL, выберите Интервал проверки и Компонент и укажите, что делать При сбое.
Откройте раздел Публичный портал, включите переключатель Включить публичный портал, если портал выключен, и отметьте Страница статуса в блоке Модули портала.
Вернитесь в раздел Страница статуса и нажмите Открыть страницу статуса.

Об инцидентах и обслуживании — в статье Как настроить страницу статуса, а обо всех настройках монитора — в статье Мониторинг сайта проверками доступности.

Чего страница статуса Kookee пока не умеет

Посетители не могут подписаться на обновления по email или RSS. Нет SMS-оповещений и графиков дежурств, мониторы делают только HTTP- и HTTPS-проверки, и закрытых страниц статуса тоже нет. У готовой страницы не может быть своего домена: чтобы разместить её на вашем, используйте React-компоненты.

Частые вопросы

Страница статуса бесплатная? Да. Страница статуса и мониторы доступности есть на всех тарифах. На бесплатном — 10 компонентов и 3 монитора с проверкой не чаще раза в 5 минут, на Pro — 50 компонентов и 20 мониторов с проверкой вплоть до раза в минуту.

Кто узнаёт, что монитор зафиксировал сбой? Владельцы и администраторы проекта — в панели Kookee и по email. Вебхуки могут получать событие monitor.down, а на Pro и Ultra интеграции со Slack, Discord и Telegram могут отправлять его в канал вашей команды.

Может ли ИИ-ассистент публиковать инциденты? Да. Через MCP-сервер Kookee ассистент с правом на запись может читать статус, создавать, обновлять и закрывать инциденты.