Как мониторить несколько сайтов клиентов Битрикс в одном кабинете

Понедельник, 9:12: десять вкладок Beget, Timeweb и reg.ru, три бота от разных uptime-сервисов – и ни одной картины "что красное прямо сейчас по клиентам". Если сопровождаете 10–50 сайтов на 1С-Битрикс, ручной обход панелей не масштабируется. Соберите мониторинг нескольких сайтов в одном кабинете: сетка статусов, критичность и онбординг нового URL в день контракта – без 20 вкладок и без путаницы с Метрикой.

Один кабинет портфеля – это не счётчик аналитики и не модуль в админке одной установки. Модель простая: карточка сайта → статус (ок / риск / инцидент) → кто смотрит по критичности. Для агентства с клиентами на разных хостерах "один ping на сервер" почти никогда не закрывает портфель – нужны отдельные проверки и единый экран поверх них.

Речь про CMS "1С-Битрикс: Управление сайтом" на хостинге клиента. Это не CRM Bitrix24 и не "несколько сайтов в кабинете Метрики". Настройка одного сайта за ~15 минут – в гайде по мониторингу на Битрикс. Каналы алертов – в статье про уведомления о падении. Сравнение SaaS – в обзоре аналогов UptimeRobot. Ниже – как вести мониторинг сайтов клиентов как операционный портфель.

Порог простой: больше пяти клиентских панелей хостинга – уже сигнал, что "зайти и глянуть" съедает утро. Рынок в 2026 году продаёт multi-site панели с лимитами вроде 3 / 15 / 50 / 200+ сайтов; агентствам важны ещё группировка по клиенту и маршрутизация алертов.

Разберите боль: двадцать панелей хостинга вместо одной сетки

Типичный день: у каждого клиента свой хостер, свой SSL, свой "бот, который иногда орёт". На практике пятый магазин добавили "как остальные" в общий Telegram – в пятницу в 23:40 падает SSL у VIP, дежурный видит пуш, но не понимает приоритет. Клиент уже пишет в WhatsApp.

FAQ Monitorus формулирует правило: на одном аккаунте виртуального хостинга достаточно проверять один сайт; на разных аккаунтах – минимум один монитор на аккаунт. У агентства клиенты почти всегда на разных аккаунтах, поэтому экономия "проверим один сервер на всех" ломается.

Сделайте: считайте единицей сопровождения клиентский URL (и его хостинг-аккаунт), а не "наш общий сервер". Не делайте: держите портфель в голове и во вкладках панелей.

Соберите модель кабинета: сайты, статусы, инциденты

Кабинет портфеля отвечает на три вопроса: какие сайты наши, что с ними сейчас, что случилось за неделю. Не путайте с виджетом Marketplace в админке одной установки – он живёт внутри одного проекта и не заменяет multi-client экран.

Схема кабинета:
Онбординг URL → карточка сайта (критичность) → внешние проверки + внутренние сигналы Bitrix → статус ок/риск/инцидент → еженедельный обзор → эскалация клиенту

В BX Pulse внешние HTTP/SSL/домен стыкуются с внутренними проверками Битрикс (~10 типов), подключение обычно около 15 минут, без SSH и доступа к БД. Тариф "Агентство" – по запросу под портфель интегратора.

Сделайте: заведите одну сетку, где у каждого клиента есть карточка и история инцидентов. Не делайте: считайте "несколько сайтов в кабинете Метрики" заменой uptime-портфелю. Используйте, например, группировку по клиенту, а не общий список без меток.

Разделите критичность клиентов до первого ночного пуша

Без критичности любой красный кружок кричит одинаково – VIP тонет в шуме. Заведите три уровня заранее:

• VIP / продакшен с деньгами: магазин, оплата – будить дежурного сразу.
• Стандарт: визитки и лендинги – алерт в рабочий канал, без паники в 3 ночи.
• Непродакшен: staging и тест – дневной канал или mute на окно работ.

Куда слать сигнал и как резать дубли – в гайде по алертам. В карточке сайта зафиксируйте критичность и кто ack'ает ночью. Быстрый triage "у всех или у нас" – в чеклисте проверки работоспособности.

Сделайте: проставьте критичность в день добавления сайта. Не делайте: сыпьте все алерты в один общий чат без приоритета. Избегайте mute "на потом" для VIP.

Пройдите чек-лист онбординга нового сайта клиента

Типичная ошибка – "забыли добавить в мониторинг". Новый контракт = новая карточка в тот же день. Пройдите чеклист ниже и проверьте, что карточка сразу живая:

1. Зафиксируйте канонический URL (https) и хостинг-аккаунт клиента.
2. Выберите критичность: VIP / стандарт / staging.
3. Добавьте сайт в кабинет; setup одного Bitrix – по инструкции мониторинга на Битрикс, здесь важен факт "попал в сетку".
4. Назначьте канал алерта и ответственного по имени.
5. Прогоните тест статуса: карточка должна быть осмысленной, не "молча сломанной".
6. В первую неделю отметьте SSL/домен-риски и странные внутренние сигналы Битрикс.

Делать: онбординг в день контракта по чек-листу выше. Не делать: откладывать "добавим в мониторинг на следующей неделе".

Проведите еженедельный обзор портфеля за минуты, не за часы

Автоматика 24/7 ловит падения; еженедельный обзор – накопленный риск. Паттерн сильных SLA-команд: автомониторинг плюс короткая ручная диагностика раз в неделю. Для агентства это один проход по сетке, а не 20 панелей.

Weekly review workflow:
Открыть кабинет → красные/жёлтые за 7 дней → SSL и домен с ближайшим сроком → повторяющиеся инциденты → эскалация клиенту / внутренний фикс → запись в тикете

Какие сайты горели чаще одного раза? Где сертификат истекает раньше "когда-нибудь потом"? Где снаружи зелёный, а внутри Битрикс уже жёлтый (агенты, бэкапы, диск)? Ответы – на одном экране.

Делать: поставить weekly review в календарь (30 минут максимум). Не делать: считать, что "раз бот молчит – всё хорошо навсегда".

Отделите кабинет портфеля от Grafana и списка SaaS

Prometheus + Grafana на крупном Bitrix – сильный экран для DevOps, но для 30 витрин на разных хостерах это overkill. Сначала кабинет портфеля; deep observability – точечно на тяжёлые проекты.

Сравнение SaaS – в обзоре аналогов UptimeRobot. Здесь важнее модель агентства: кто смотрит сетку, как онбордят, как эскалируют. Собрать портфель можно через демо BX Pulse: ранний доступ бесплатный, тариф "Агентство" – по запросу.

Делать: закрыть боль вкладок кабинетом. Не делать: разворачивать Grafana на каждый мелкий клиентский сайт "на всякий случай".

Что сделать на этой неделе

Короткий план без героизма:

1. Выпишите все клиентские URL, которые реально сопровождаете.
2. Заведите (или почистите) одну сетку статусов – без дублей в трёх ботах.
3. Проставьте критичность VIP / стандарт / staging.
4. Онбордите тех, кого "забыли": URL + канал + тест.
5. Поставьте в календарь 30-минутный weekly review.
6. Уберите лишние боты и дублирующие пуши в один канал.

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

Материал проверен. Автор: Максим Мольков, основатель BX Pulse, инженер по эксплуатации 1С-Битрикс.
Источники: Monitorus: один или все сайты, FirstVDS: multi-site тарифы 2026, PingMap, Merlonix: agency monitoring, 1С-Битрикс: Инспектор сайтов, Marketplace: itiso.monitoring.