Self-hosted статус-страница вместо подписки: стоит ли она возни

MAATRIX

Статус-страница — та самая публичная витрина с зелёными и красными кружками, на которую клиенты идут в первую очередь, когда у вас что-то легло. У SaaS-продукта она напрямую работает на доверие: инцидент без честного статуса выглядит как замалчивание, инцидент с прозрачным статусом — как контроль над ситуацией. Рано или поздно у любой команды возникает вопрос: платить за готовый сервис или поднять то же самое на своём сервере. Ответ не такой однозначный, как кажется на старте, и в конце августа 2026 года экономика этого решения выглядит скромнее, чем рисуют статьи в духе «откажитесь от подписок».

Сколько обычно стоит подписка на статус-страницу

Статус-страница как отдельный сервис — один из самых дешёвых пунктов в SaaS-стеке большинства команд. По сравнению с CI/CD, почтовой рассылкой, CRM или мониторингом инфраструктуры это скорее строчка на несколько долларов в месяц на нижних тарифах, где-то на уровне «чуть дороже одного платного домена». Даже на тарифах с кастомным доменом, несколькими командами, SSO и историей инцидентов за год цена редко приближается к тому, что компании платят за один seat в таск-трекере или CRM.

Здесь важна методика, а не конкретная цифра (называть точные тарифы конкретных сервисов смысла нет — они меняются, и на момент чтения статьи будут другими): считайте не абсолютную сумму, а долю в общем SaaS-бюджете. Если у вас 15-20 подписок на разные сервисы, статус-страница почти всегда окажется в нижней трети списка по стоимости. Это первое, что стоит проверить перед тем, как затевать миграцию — откройте счёт за статус-страницу за последний квартал и сравните с счётом за, скажем, мониторинг или почтовую рассылку.

Типичная структура тарифов у таких сервисов:

• бесплатный или почти бесплатный план с ограничением по числу подписчиков на уведомления и без кастомного домена;
• средний план с кастомным доменом, брендингом и несколькими компонентами системы;
• план для команд с SSO, несколькими статус-страницами (публичная + внутренняя) и расширенной историей инцидентов.

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

Из чего складывается стоимость self-hosted решения

Self-hosted статус-страница — это не бесплатно, просто затраты выглядят иначе: не ежемесячный счёт, а разовая и растянутая во времени работа.

Сервер. Для статус-страницы не нужны большие мощности — она обслуживает редиректы, лёгкий бэкенд и статические ассеты, плюс воркер, который периодически пингует ваши сервисы. Младший VPS с 1-2 vCPU и 1-2 ГБ RAM с запасом закрывает эту задачу, даже если на нём же крутится и мониторинг вроде Uptime Kuma или другого self-hosted инструмента. Если статус-страница — единственное, что вы переносите на свою инфраструктуру, стоимость аренды такого сервера в месяц сопоставима с недорогим тарифом на подписку — экономии почти нет, только смена модели затрат.

Домен и SSL. Обычно у вас уже есть домен компании, поддомен вроде status.example.com не требует отдельной покупки. SSL закрывается Let's Encrypt бесплатно и автоматически.

Настройка. Разворачивание типового self-hosted решения на Docker Compose занимает от часа до дня, в зависимости от того, сколько компонентов вы хотите показывать (отдельные API, база данных, CDN, платёжный шлюз) и насколько глубоко интегрируете уведомления (email, Telegram, Slack, вебхуки). Если у вас уже есть опыт с Docker и обратным прокси — ближе к часу-двум. Если поднимаете первый self-hosted сервис в жизни компании — закладывайте день с учётом отладки reverse proxy, сертификатов и DNS.

Пример минимального docker-compose.yml для связки статус-страницы с базой данных (условная конфигурация, у конкретного инструмента детали будут отличаться):

version: "3.8"
services:
  statuspage:
    image: your-status-page-image:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3000"
    environment:
      - DATABASE_URL=postgres://status:status@db:5432/status
      - APP_URL=https://status.example.com
    depends_on:
      - db
  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      - POSTGRES_USER=status
      - POSTGRES_PASSWORD=status
      - POSTGRES_DB=status
    volumes:
      - status_db:/var/lib/postgresql/data
volumes:
  status_db:

Сверху — Nginx или Caddy как reverse proxy с сертификатом и, если статус-страница публичная, желательно вынести её отдельно от боевых сервисов, чтобы падение основного приложения не утаскивало за собой и то место, где клиенты узнают о падении. Подробный разбор установки такого сервиса на VPS — в отдельной статье про установку и настройку status-страницы на VPS, там же частые ошибки на этапе первого запуска.

Время на поддержку — то, что обычно не считают

Вот где расчёт «подписка дороже» чаще всего ломается. Разовая настройка — не единственная статья расходов. После запуска на self-hosted статус-странице появляются задачи, которых не было при подписке:

• обновления образа/пакета и зависимостей — реже, чем у боевого продукта, но игнорировать нельзя, особенно если в компоненте была уязвимость;
• бэкапы базы с историей инцидентов — если она пропадёт, вы теряете не только текущий статус, но и всю историю аптайма, на которую иногда ссылаются в SLA;
• мониторинг самого сервера со статус-страницей — да, страница, которая должна сообщать о падении сервисов, сама может упасть, и тогда нужен второй, независимый канал контроля;
• разбор инцидентов с самим инструментом — reverse proxy отвалился, сертификат не обновился, воркер перестал слать пинги — такие мелочи случаются нечасто, но случаются;
• онбординг новых людей в команде поддержки — им нужно объяснить не только бизнес-процесс, но и то, как устроен именно ваш self-hosted инструмент.

Это условно час-два в месяц у зрелой команды с отлаженным процессом, и заметно больше в первые месяцы, пока процесс не устоялся. Если оценивать это время по стоимости часа специалиста, который мог бы заниматься продуктом, а не администрированием ещё одного сервиса, картина быстро перестаёт выглядеть как явная экономия. Тот же принцип разбирался на примере мониторинга в статье «Мониторинг: сервис или своё» — логика почти один в один переносится на статус-страницы: подписка продаёт не только код, но и то, что вам не нужно разбираться, почему воркер перестал слать пинги в три часа ночи.

Так стоит ли она возни: честный ответ

Если сравнивать в лоб — стоимость младшего VPS плюс время на настройку и разовую поддержку против недорогой подписки на статус-страницу, — для многих команд экономия окажется небольшой, а иногда и отрицательной, если честно посчитать время специалиста по рыночной ставке. Статус-страница почти никогда не самая дорогая подписка в стеке инструментов компании, и именно поэтому она плохой кандидат на «первую жертву» при оптимизации расходов на SaaS.

Это не значит, что self-hosted вариант плох сам по себе — технически он работает не хуже, а иногда даёт больше контроля (свои уведомления, свой домен без ограничений тарифа, данные не уходят к третьей стороне). Вопрос именно в трудозатратах на фоне скромной экономии. Если у вас нет свободных рук в команде, которые и так администрируют инфраструктуру, ради одной статус-страницы редко имеет смысл заводить отдельный self-hosted сервис — слишком велико соотношение «усилия / выгода» для единственного изолированного кейса.

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

Когда self-hosted всё же оправдан

Расчёт меняется, если статус-страница — не единственный сервис, который вы переносите на свою инфраструктуру, а один из многих. Если у команды уже есть свой сервер под мониторинг (Uptime Kuma, Zabbix, Prometheus с Grafana), свой Sentry для ошибок, свой менеджер паролей, своя почтовая рассылка — предельные затраты на добавление ещё одного контейнера с статус-страницей минимальны. Сервер уже арендован и оплачен под другие задачи, reverse proxy и сертификаты уже настроены, процесс бэкапов уже отлажен, человек, который умеет это администрировать, уже есть в команде.

В этом случае логика меняется на противоположную: не «стоит ли ради статус-страницы заводить сервер», а «раз сервер уже есть под пять других self-hosted сервисов, зачем платить за шестой отдельно». Именно так обычно и выглядит реальная миграция в компаниях, которые последовательно уходят от подписок — не одним резким решением, а постепенным накоплением self-hosted инструментов на одной и той же инфраструктуре, пока предельная стоимость каждого нового не станет копеечной.

Есть и второй сценарий, где self-hosted оправдан независимо от экономии — регуляторные или контрактные требования не хранить данные о доступности у стороннего облачного провайдера, либо потребность в статус-странице, которая физически недоступна вместе с основным облаком (если весь стек лежит в одном датацентре одного облачного провайдера, а статус-страница — там же, при отказе всего облака клиенты не увидят даже сообщение о том, что что-то не так).

Как развернуть self-hosted статус-страницу, если решение принято

Если по совокупности факторов (уже есть своя инфраструктура, есть кому поддерживать, важен полный контроль над данными) вы решили идти по self-hosted пути, порядок действий обычно такой:

1. Выделите под статус-страницу отдельный сервер или как минимум отдельный поддомен и IP, не совмещённый с боевым продуктом — так падение основного сервиса не заберёт с собой и место, где об этом узнают клиенты.
2. Разверните выбранный инструмент через Docker Compose — большинство open source решений для статус-страниц поставляются именно так, что упрощает и установку, и последующие обновления.
3. Настройте воркер проверок (пинг эндпоинтов, TCP-порты, HTTP-статусы) с интервалом, который не создаёт лишнюю нагрузку на сами проверяемые сервисы — обычно 30-60 секунд достаточно.
4. Подключите каналы уведомлений — email, Telegram-бот, вебхук в корпоративный чат — до того, как страница пойдёт в продакшн, а не после первого пропущенного инцидента.
5. Настройте отдельный, независимый мониторинг самой статус-страницы — простейший вариант: внешний пинг-чекер, который следит за доступностью status.example.com и не зависит от вашей инфраструктуры.
6. Заведите регламент бэкапов базы данных — минимум ежедневный дамп с хранением за пределами того же сервера.

Частые технические грабли на этом пути — неправильно настроенный reverse proxy, забытое продление сертификата, воркер проверок, упавший вместе с сетью сервера, — разобраны отдельно в статье про частые ошибки при эксплуатации status-страницы на сервере. Прежде чем запускать self-hosted вариант в продакшн, стоит пройтись по этому списку — большинство проблем там типовые и решаются заранее, а не постфактум во время реального инцидента.

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