Uptime-мониторинг для агентств: как вести 50+ доменов клиентов и не сойти с ума

Проблема мониторинга в агентстве

9:14 утра. Цифровое агентство ведёт 60 клиентских сайтов — микс магазинов на Shopify, маркетинговых сайтов на WordPress и одна-две SaaS-панели. Дежурный аккаунт-менеджер открывает Slack и видит три красных алерта об инцидентах за ночь.

Какие клиенты упали? Какой ещё лежит? Был ли кто-то из них на «Tier 1»-SLA, где агентство обещало 99,9% месячного аптайма? Кто-нибудь уже сообщил клиентам, или они сейчас напишут с вопросом, почему checkout сломан?

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

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

Чем агентский мониторинг отличается

Большинство uptime-инструментов проектируются под одну команду, ведущую один продукт. Агентство — не такая команда. У агентского мониторинга свои ограничения:

• Multi-tenant масштаб. Вы мониторите не 5 эндпоинтов — вы мониторите от 50 до 500+ по многим клиентам, у каждого свои поддомены, маркетинговые сайты и API.
• Разные SLA по тиру клиента. Клиент с retainer на $15 000 в месяц получает другую реакцию, чем разовый сайт за $200/мес. Мониторинг должен это отражать.
• Границы доступа команды. Junior-разработчик должен видеть три сайта, на которых он работает на этой неделе — не весь портфель агентства. Senior-инженерам и аккаунт-менеджерам нужна более широкая видимость.
• Видимость для клиента. Одни клиенты хотят status page для своих покупателей. Другие просто хотят, чтобы им сообщали, когда что-то сломалось. Третьи хотят полного молчания и только квартальных отчётов.
• Сложность биллинга. Одни клиенты платят отдельной строкой за мониторинг. У других он зашит в retainer. В любом случае нужно понимать стоимость на клиента, чтобы правильно ценообразовывать.
• Маршрутизация уведомлений. Кого вызывать, когда падает клиент X? PM? Разработчика, делавшего сайт? Самого клиента? Ответ обычно «зависит от клиента и от времени суток».

Если ваш инструмент мониторинга не моделирует эти шесть пунктов, вы будете склеивать их таблицами, Slack-каналами и Notion-документами — и именно там тихо вытекает маржа агентства.

Столп 1: Организация доменов на масштабе#

Первое, что ломается на 50+ доменах — сам дашборд. Плоский список «все мои мониторы» перестаёт быть полезным после 20 доменов. На 50 уже невозможно проскроллить, не теряя контекст.

Решение — структурированная организация, и рабочая лошадка здесь — теги (в разных инструментах их зовут folders или groups).

Стратегия тегирования, которая масштабируется для агентств, обычно сочетает несколько осей:

• По клиенту. client:acme-corp, client:helio-shopify, client:beta-bank. Главная ось — по ней группируются инвойсы, отчёты и коммуникация по инцидентам.
• По тиру SLA. tier-1, tier-2, tier-3. Tier 1 может означать 60-секундные проверки, WhatsApp-алерты основателю и реакцию 24/7. Tier 3 — 5-минутные проверки и ежедневный email-дайджест.
• По стэку. stack:wordpress, stack:shopify, stack:next-js, stack:custom-saas. Когда CDN или общая зависимость ломается, нужно мгновенно отфильтровать «покажи каждый WordPress, который у меня хостится» без кликов по 60 карточкам.
• По региону. region:eu, region:us, region:apac. Полезно при региональном простое — нужно сразу понять, кого из клиентов это затронуло.

Nova Uptime поддерживает теги как first-class концепт на каждом мониторе, и дашборд можно фильтровать по любой комбинации. В сочетании с массовыми операциями теги открывают workflow, невозможные без них: выделить все tier-1-домены и одним действием снизить интервал до 59 секунд; выделить все client:acme-corp и поставить мониторинг на паузу на выходные миграции.

Две недооценённые фичи дополняют картину: inline-переименование (чтобы дашборд показывал «Acme — Checkout API» вместо https://api-prod-3.acme.internal) и поиск по сотням доменов с подстрокой. Вместе они превращают 200-доменный дашборд из стены URL в нечто, что человек реально может просканировать.

Глубже про то, как агентства используют Nova Uptime, — в агентском use case на странице use cases.

Столп 2: Управление доступом команды#

Как только агентство переваливает за пару человек, «все админы на каждом мониторе» становится неприемлемым. Junior-разработчик не должен иметь силы случайно удалить монитор критичного клиента. Фрилансер на одном проекте не должен видеть весь ваш список клиентов. Аккаунт-менеджер должен видеть инциденты и отчёты, но не менять интервалы проверок.

Инструменту мониторинга, заточенному под агентства, нужен role-based access control минимум с тремя слоями:

• Owner / Admin — полный контроль над workspace, включая биллинг.
• Member с полным доступом — может добавлять, редактировать и резолвить инциденты на любом мониторе.
• Member с per-domain доступом — видит и действует только на доменах, к которым ему дали доступ.

Слой per-domain доступа — то, что делает агентскую жизнь нормальной. Вы берёте фрилансера на Shopify на трёхмесячный проект; даёте доступ к четырём мониторам, которые имеют значение для его проекта, и больше ни к чему. Когда проект заканчивается — отзываете доступ одним кликом, без общих паролей и осиротевших учётных данных.

Nova Uptime поддерживает приглашение членов команды по email, включая ghost-аккаунты для тех, у кого ещё нет логина в Nova Uptime (они получают настоящий аккаунт при первом входе с уже настроенным доступом). Также поддерживается read-only доступ для стейкхолдеров — полезно для аккаунт-директора, которому нужна видимость, но не нужно крутить настройки.

И что важнее всего, каждое действие команды записывается в activity log: кто добавил домен, кто поставил мониторинг на паузу, кто подтвердил инцидент, кто менял канал алерта. Когда клиент спрашивает «почему мой сайт не мониторился во вторник?» — вы отвечаете timestamped аудит-следом, а не догадкой.

Столп 3: Многоканальные уведомления#

Только-email-алертинг был нормой при двух клиентах. На 50 ваш inbox становится кладбищем алертов — важное хоронится под рассылками, каждый алерт смешивается со следующим, дежурный разработчик заглушает уведомления, потому что во время ужина пришло 12 штук.

Мониторингу агентского уровня нужны многоканальные уведомления, маршрутизируемые по домену и тяжести:

• Email всё ещё базовая линия. Используйте для всех — команда, аккаунт-менеджер, по желанию клиент. Здесь живёт аудит-след.
• WhatsApp — правильный канал для критических инцидентов, требующих немедленной реакции человека. Основатель, CTO, дежурный инженер — все они смотрят WhatsApp быстрее, чем email. Nova Uptime поддерживает WhatsApp-алерты на каждом тарифе (1 номер на Free, 3 на Pro, 5 на Agency).
• Webhook'и — суперсила агентств. Перенаправляйте алерты прямо в существующий клиентский Slack, Microsoft Teams, PagerDuty или Opsgenie. Клиенту не нужно логиниться в ваш мониторинг — алерты приходят в каналы, в которых он уже живёт.

Принципиальная деталь — per-domain маршрутизация. Клиент A хочет алерты в свой Slack-канал #engineering. Клиент B не хочет ничего в рабочее время, но после 18:00 — SMS-эскалация на дежурный номер. Клиент C хочет дайджест-email два раза в день, без real-time шума. Плоская конфигурация «все алерты во все каналы» этого не моделирует — нужен per-domain выбор каналов.

Две связанные фичи завершают картину: пауза уведомлений (чисто отключать алерты на плановых работах, без фейковых инцидентов потом) и routing по тяжести (warning о медленном ответе только в email; полный простой — WhatsApp + webhook). Сделанное правильно, это даёт громкие сигналы, когда нужно, и тишину, когда нет — единственный способ агентскому on-call выживать долгосрочно.

Столп 4: Коммуникация с клиентом#

Самый большой разлом для агентского мониторинга — не внутренний, а внешний. То, как ваши данные мониторинга текут обратно к клиентам, определяет их опыт во время инцидентов и доверие к вам между ними.

Embed-виджеты статуса — самая простая и максимально рычажная фича здесь. Вставьте небольшой iframe на сайт клиента (или на его status-поддомен), показывающий живой uptime URL, которые вы мониторите от его имени. Его клиенты перестают писать ему «сайт упал?», потому что могут посмотреть сами. Его внутренняя команда перестаёт спрашивать вас в Slack «что-то не так?», потому что видит зелёные галочки. Nova Uptime поддерживает embed-виджеты на каждом домене — token-based, с проверкой origin и настройкой per-domain.

Публичные share-ссылки — более лёгкая альтернатива: URL, который можно вставить в письмо клиенту, когда инцидент в процессе. Они кликают, видят живой статус, и вы заменяете 30-минутную переписку 15-секундной ссылкой.

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

Скриншоты при сбое значат больше, чем кажется. Когда сайт падает, скриншот реальной страницы ошибки (или таймаута, или отдаваемого не того контента) драматически полезнее статус-кода. Клиенты понимают картинки. Клиенты спорят со статус-кодами.

Антипаттерн, который стоит избегать: заставлять клиента ставить ваш мониторинг-агент на свой сервер. Не делайте этого. Держитесь URL-based внешнего мониторинга — быстрее ставится, не ломает их стек и работает одинаково, на дешёвом ли shared-хостинге сайт или на вашей премиум-инфре.

Столп 5: Биллинг и прибыльность#

Мониторинг должен приносить агентству деньги, а не уносить. Математика простая, но её нужно сделать.

Тарифные тиры Nova Uptime спроектированы ровно под этот вопрос:

• Free — 5 доменов. Полезен для презейла и пробников на маленьких клиентах.
• Pro — $99/год, 100 доменов. Правильный тир для агентств с 20–80 клиентских сайтов.
• Agency — $699/год, 1 000 доменов. Правильный тир, когда вы перевалили за 100 клиентских доменов или хотите WhatsApp-алерты на 5 номеров, максимум API-доступа и наивысшую частоту проверок.

Domain add-ons (+10 / +50 / +100) позволяют расти без апгрейда тира — полезно, когда у вас 105 доменов и не хочется сразу прыгать на Agency.

Биллинговый вопрос, на который отвечает каждое агентство: зашивать мониторинг в retainer или брать отдельно? Зашивать проще операционно и щедрее на вид клиента. Брать отдельной строкой ($25–$100 за сайт в месяц — типичная вилка) прибыльнее, даёт повод раз в квартал обсудить uptime и позволяет клиентам выбирать тир сервиса. Большинство mid-market агентств приходят к гибриду: мониторинг зашит в Tier 1-retainer'ы, отдельной строкой — для разовых проектов.

Что бы вы ни выбрали, еженедельные отчёты (упомянутые выше) работают и как биллинг-артефакты. Это доказательство SLA, которое вы оказываете — и самое простое доказательство, чтобы прикрепить к разговору о продлении. Глубже про затраты — в гайде по сравнению стоимости uptime-мониторинга.

Реальный workflow агентства#

Вот день из жизни operations-лида агентства, ведущего мониторинг на Nova Uptime:

• 09:00. Открываю дашборд. Фильтр по тегу tier-1. Три ночных инцидента — два авто-резолвнулись, один ещё расследуется. Кликаю в открытый, смотрю скриншот сбоя, пишу PM-у клиента однострочный апдейт со ссылкой на публичный share.
• 09:15. Триггер еженедельных отчётов для всех tier-1-клиентов. Каждый получает чистое письмо со своим uptime, числом инцидентов и статусом SLA за неделю. Делается одним действием.
• 11:00. Кикофф онбординга нового клиента. Агентство только что подписало Shopify-ритейлера на 12 доменов (главный магазин + 8 страновых поддоменов + 3 маркетинговых страницы). Bulk-импорт всех 12 через CSV (Nova Uptime поддерживает bulk-импорт до 100 за раз). Тегирую client:retailer-x и tier-2. Приглашаю CTO клиента членом команды с read-only-доступом только к этим 12 мониторам.
• 14:00. Slack пингует: webhook от монитора client:beta-bank api-checkout показывает медленные ответы. Никто не упал — пока — но warning даёт дежурному инженеру 20 минут расследовать до того, как клиенты заметят. База под нагрузкой, autoscaler срабатывает, проблема решена.
• 16:30. Клиент на Tier 3 пишет: «завтра утром катим новую тему, можете поставить алерты на паузу, чтобы команда не вставала по ложным срабатываниям?» Ставлю мониторинг на паузу на трёх их доменах, авто-возобновление в 11:00 следующего дня.
• 17:30. Конец дня. В activity log 47 записей — каждое действие команды, каждый алерт, каждое изменение домена, аккуратно с timestamps. Если завтра кто-то спросит, что было сегодня, ответ — в одном фильтре.

Это реальный агентский вторник. Никакого героизма не нужно — нужен правильный инструмент с правильной настройкой.

Чек-лист настройки для агентств

Если начинаете с нуля (или мигрируете с инструмента, упёршегося в лимиты), вот порядок:

1. Регистрируйтесь на правильном тарифе. Pro — до 100 доменов, Agency — больше 100 или нужны 5 WhatsApp-номеров. Смотрите тарифы.
2. Bulk-добавляйте клиентские домены. CSV-импорт — до 100 за раз. Не добавляйте по одному.
3. Тегируйте домены по клиенту и тиру SLA. Используйте единое именование (client:slug, tier-N, stack:name). Запишите конвенцию в командной wiki.
4. Приглашайте членов команды с подходящим доступом. Owners + admins для senior-сотрудников, per-domain для junior'ов и контракторов, read-only для аккаунт-менеджеров.
5. Настройте WhatsApp-алерты для senior on-call ротации. Не вешайте на всех — это убьёт смысл.
6. Настройте webhook-интеграции в существующие у клиентов Slack/Teams/PagerDuty. Самая высокоимпактная интеграция.
7. Встраивайте status-виджеты на status-страницы или панели клиентов. Бонус: добавьте ссылку на ваше агентство в виджет.
8. Расписывайте еженедельные отчёты для всех Tier 1- и Tier 2-клиентов. Автоматизируйте, не пишите вручную.
9. Задокументируйте ваш incident-response. Кто подтверждает? Кто общается? Кто разрешает? Кто пишет постмортем? Запишите один раз и следуйте.

Для более широкой стратегии мониторинга кроме uptime — комбинируйте этот гайд с гайдом по uptime для SaaS и обзором мульти-регионального мониторинга. И не забывайте: uptime — лишь половина истории для агентств, обслуживающих клиентов с email — прогоняйте бесплатный email-чекер на каждом новом клиенте при онбординге, чтобы ловить ошибки SPF, DKIM и DMARC до того, как они стоят клиенту доставляемости.

Заключение

Агентский мониторинг — операционная задача, замаскированная под техническую. Пинги — простые; люди, клиенты и биллинг — где он живёт или умирает. Сделайте пять столпов правильно — организацию, доступ, уведомления, общение с клиентом и биллинг — и мониторинг перестанет быть margin sink, превратившись в одну из самых защитимых частей вашего сервиса.

Попробуйте 30-минутный триал Nova Uptime без регистрации или сразу переходите на Pro или Agency-тариф и bulk-импортируйте клиентские домены сегодня. Каждая фича из этого гайда есть в стандартных тарифах — без add-ons и сюрпризов. Полный список — на странице фич.

Связанные материалы

• Uptime-мониторинг для SaaS: гайд 2026
• Сравнение стоимости uptime-мониторинга
• Мульти-региональный мониторинг: глобальное покрытие
• Тарифы и фичи
• Бесплатный email-чекер
• Агентский use case