Терминал никуда не делся

Один разработчик недавно написал на Reddit в r/selfhosted о том, как собрал Updo — CLI-инструмент мониторинга сайтов. Причина была проста: он устал открывать веб-дашборды.

Пост попал в больное место. Сотни апвоутов, десятки комментариев — и чёткое сообщение от сообщества разработчиков: мы хотим работать в терминале.

Это не маргинальное мнение. То же самое настроение видно в r/devops, r/commandline, r/selfhosted — у разработчиков, которые деплоят через git push, рулят инфраструктурой через kubectl, дебажат через curl, а потом вынуждены переключать контекст на вкладку браузера, чтобы проверить, жив ли сайт.

С таким workflow что-то не так.

В чём проблема веб-дашбордов

Веб-дашборды для мониторинга проектировались под мир, где «мониторинг» означал команду ops-инженеров, смотрящих в экраны NOC (Network Operations Center). В 2010-м эта модель имела смысл. В 2026-м — нет.

Вот что разработчики переживают на самом деле:

Переключение контекста убивает поток

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

Открываете браузер
Идёте на дашборд мониторинга
Логинитесь (или ждёте обновления сессии)
Ищете нужный домен
Смотрите статус

Пять шагов. Пять прерываний. Пять шансов потерять нить мысли.

Подход terminal-first сводит это к одной команде: novauptime status.

Дашборды не скриптуются

Веб-дашборд нельзя направить в bash-скрипт. Нельзя «грепнуть» его вывод. Нельзя соединить с jq или скормить в Slack-webhook.

CLI-инструменты компонуемы по своей природе. Они работают по Unix-философии маленьких инструментов, которые делают одну вещь хорошо и соединяются через стандартный I/O.

Ещё одна вкладка, ещё один логин

У среднего разработчика открыто 15–30 вкладок браузера. Дашборд мониторинга — это ещё одна вкладка, претендующая на внимание, ещё один набор учёток для управления, ещё один сервис, в который нужно залогиниться, когда вам просто хочется быстро посмотреть статус.

Мобильные дашборды ещё хуже

Адаптивные веб-дашборды на мобильном — универсально болезненный опыт. Мелкий текст, неудобная навигация, медленная загрузка. Терминал на телефоне (через SSH или приложения вроде Termius) быстрее и привычнее.

Что строит сообщество

Обсуждения на Reddit показывают паттерн: разработчики строят свои собственные решения.

Updo — мониторинг в терминале с Prometheus#

Updo — CLI на Go, который мониторит сайты с реальным uptime в процентах, временем отклика и статусом SSL-сертификата. Интегрируется с Prometheus/Grafana, шлёт алерты в Slack/Discord. Поддерживает даже мониторинг из нескольких регионов через AWS Lambda.

Хорошо сделан под свою задачу — но фокусируется на HTTP-проверках. Нет email health-мониторинга, нет учёта инцидентов с кодами, нет управления командой, нет интеграции с биллингом.

Uptime Kuma — король self-hosted (но всё-таки дашборд)#

Uptime Kuma доминирует в нише self-hosted мониторинга с красивым веб-UI. Но в этом и суть — это веб-UI. В каждой ветке про Uptime Kuma кто-нибудь спрашивает: «А есть CLI-альтернатива?»

Gatus — config-as-code мониторинг#

Gatus идёт по DevOps-friendly пути — с YAML-конфигами. Лёгкий (30 МБ RAM), поддерживает алерты по условиям и чувствует себя как дома в Kubernetes-деплое, а не в браузерных закладках. Но просмотр результатов всё равно идёт через дашборд.

Пробел

Все эти инструменты решают части пазла, но ни один не даёт полной платформы мониторинга с настоящим CLI-first опытом. Вы получаете либо CLI с ограниченными возможностями, либо полную платформу, которая загоняет в браузер.

Каким должен быть terminal-first мониторинг#

Исходя из обсуждений на Reddit и реальных рабочих процессов разработчиков, вот что должен уметь нормальный CLI-инструмент мониторинга:

1. Цветной статус с одного взгляда#

Тред в r/commandline показал красочный вывод в терминале — зелёный для up, красный для down, бирюзовый для response time. Это не декорация, это плотность информации. Хорошо сформатированная таблица в терминале сообщает с одного взгляда больше, чем сетка карточек на дашборде.

$ novauptime status

  ● example.com         UP   142ms   SSL 284d   Email A
  ● api.example.com     UP    89ms   SSL 284d
  ● staging.example.com DOWN  503    INC-A3F291
  ● blog.example.com    UP   203ms   Email A

  4 domains · 3 up · 1 down · Checked 30s ago

2. Полный CRUD без браузера#

Добавление домена не должно требовать навигации по форме. novauptime domains add example.com --interval 300 — и готово.

3. Скриптуется для CI/CD#

Health-проверки после деплоя должны жить в вашем пайплайне, а не во вкладке браузера, которую можно забыть открыть:

# В вашем CI/CD-пайплайне
novauptime domains add staging.example.com --interval 59
sleep 120
STATUS=$(novauptime status --domain staging.example.com --json | jq -r '.state')
if [ "$STATUS" != "up" ]; then
  echo "Deployment verification failed!"
  exit 1
fi

4. Не только HTTP-проверки#

Большинство CLI-инструментов мониторинга останавливаются на «жив ли сайт?». Настоящий мониторинг включает доставляемость email (MX, SPF, DKIM, DMARC), отслеживание SSL-сертификатов, истечение домена и управление инцидентами. Всё это должно быть доступно из терминала.

5. Работает со стеком, а не против него#

CLI-инструмент должен дополнять существующий тулчейн. Используйте CLI для быстрых проверок и автоматизации. Веб-дашборд — когда нужны графики трендов за 90 дней. WhatsApp-алерты — на телефоне. CLI — не замена, а недостающий интерфейс для разработчиков, проводящих 80% дня в терминале.

Как Nova Uptime это решает#

Nova Uptime собирали для разработчиков, и наш CLI это отражает. Вот что вы получаете:

13 групп команд, покрывающих всю платформу: status, domains, email-health, incidents, urls, account, webhooks, team, tags, billing, config, logs и help.

Аутентификация по email-OTP — браузер не нужен. Запускаете novauptime auth login, вводите email, набираете код подтверждения — и вы внутри.

Всё, что делает дашборд — добавление/удаление доменов, email health-проверки, просмотр инцидентов с кодами INC-XXXXXX, управление тегами и папками, проверка статуса биллинга.

JSON-режим вывода для скриптов — направляйте в jq, скармливайте своему пайплайну алертов или интегрируйте с существующим стеком Prometheus/Grafana через webhook'и.

Все тарифы включают доступ к CLI, WhatsApp-алертам и API наряду с веб-дашбордом — одна платформа, несколько интерфейсов, никаких компромиссов.

Будущее — мультиинтерфейсное

Вопрос не «CLI против дашборда». Вопрос — «почему мне дают только один интерфейс?»

Лучший опыт мониторинга даёт:

Терминал — для быстрых проверок, автоматизации и интеграции с CI/CD
Веб-дашборд — для анализа трендов, визуальных отчётов и онбординга команды
Мобильные алерты (WhatsApp, SMS) — для критических инцидентов
API — для кастомных интеграций и сторонних инструментов
Встраиваемые виджеты — для статус-страниц лицом к клиенту

Nova Uptime — единственная платформа мониторинга, дающая все пять — включая CLI, который действительно уважает то, как работают разработчики.

Как начать

Установите CLI и начните мониторить из терминала:

npm install -g novauptime
novauptime auth
novauptime status

Или зарегистрируйтесь бесплатно и изучите всю платформу — веб-дашборд, CLI, WhatsApp-алерты и 5 бесплатных доменов в комплекте.

Почему разработчики бросают веб-дашборды ради CLI-мониторинга