Когда агентство управляет 10-100 клиентскими сайтами, мониторинг становится логистической проблемой, не технической. 5 сайтов — можно проверить вручную. 50 сайтов — уже нужна автоматизация. 100+ сайтов — без инструмента это просто невозможно. И главное: клиенты ожидают, что вы узнаете об outage раньше, чем они.
Многие агентства покупают отдельный план мониторинга на каждый сайт (5-10 чихуа в месяц на каждый), тратя 500-1000 на все сайты в портфелио. Или ничего не покупают и полагаются на жалобы клиентов. Третий вариант: один план с 50-500 monitors за 5-15 в месяц, который покрывает весь портфолио и кроме того экономит 10 часов в месяц на support calls о downtime.
Почему агентства игнорируют мониторинг
Причина 1: Цена за монитор
Стандартный инструмент стоит 5-10 за monitor. На 50 клиентов по 3-5 monitors каждый = 750-2500 в месяц. Это больше, чем доход от многих клиентов. Вместо этого агентства либо платят очень дорогим enterprise инструментам (которые предоставляют 500 monitors за 500-1000), либо ничего не платят.
Причина 2: Complexity
Настроить мониторинг для каждого клиента отдельно — долго. Разных стеков, разных хостов, разных требований. Проще не настраивать.
Причина 3: Noise из false alerts
Если каждый glitch или temporary spike генерирует alert, команда быстро закрывает alerts автоматически. Мониторинг становится бесполезным.
Модель мониторинга для агентств
Один аккаунт, все клиенты
Создаёте один аккаунт AtomPing на агентство. Все 50-100 клиентов мониторятся из одного места. Один dashboard, один set аллертов, одна интеграция с Slack/Telegram. Это управляемо, когда все организовано по клиентам и тегам.
Названия monitors как иерархия
Вместо просто "Homepage", используйте: ClientName - Homepage - HTTP. Когда в Slack приходит alert, сразу видно, что это за клиент.
Tags для фильтрации
Добавьте tags каждому monitor: client:acme, type:checkout, priority:critical. Потом фильтруйте алерты по тагам: checkout failures отправляются только вам, домашние страницы — в общий канал.
Минимальный набор monitors на клиента
Homepage (HTTP + keyword): Базовая проверка. GET https://client.com + keyword на бренд/заголовок. Interval: 2-5 минут. Ловит major outages.
SSL Certificate (TLS): client.com. Alert за 30 дней до expiry. Совершенно забываемый monitor, но очень важный. Если сертификат истечёт, браузер заблокирует сайт.
DNS (DNS check): если используется кастом-домен или DNS маршрутизация. Проверяет, что A/CNAME резолвуются правильно.
WordPress specifics: + REST API endpoint /wp-json/wp/v2. Total: 4 monitors.
Shopify specifics: + checkout /cart с response time assert. Total: 4 monitors.
SaaS specifics: + login page + API health endpoint. Total: 4 monitors.
Agency overhead: 3 базовых monitors на каждый сайт = 150 на 50 клиентов. Остаётся 350 на развитие, специфичные checks и резерв.
Ценовое сравнение: почему AtomPing лучше
| Scenario | Datadog/New Relic | Pingdom (per monitor) | AtomPing Free | AtomPing Pro |
|---|---|---|---|---|
| 10 clients, 3 monitors each | $500-1000 | $150-300 | $0 | $5 |
| 50 clients, 3 monitors each | $2500-5000 | $750-1500 | $0 | $5 |
| 100 clients, 5 monitors each | $5000-10000 | $2500-5000 | N/A (oversized) | $5 |
| 500 clients, 5 monitors each | $25000+ | $12500+ | N/A | $5 |
Логика простая: Datadog/New Relic заряжают за инструмент как за корову за месяц. AtomPing заряжает фиксированную цену за unlimited monitors. До 50 monitors бесплатно. От 50+ — $5 в месяц за все что угодно.
White-label status pages
Status page — это лицо агентства перед клиентом. Когда сайт падает, клиент видит status page от вас, не от Datadog или uptime bot'а.
Брендирование: Каждый status page может быть отдельно branding'ован: логотип агентства, логотип клиента, цветовая схема. AtomPing Pro позволяет custom домен (status.client.com) для белоснежного white-label'а.
Компоненты: добавляйте компоненты в status page: Website, API, Checkout, Email Sending. Каждый component связан с одним или несколькими monitors. Когда monitor fails — component автоматически становится красным.
История инцидентов: Status page показывает все past incidents с временем начала и разрешения. Клиент видит, что сайт был down на 5 минут в понедельник утром.
Уведомления на status page: Опубликуйте notice когда вы планируете maintenance, и status page покажет это клиентам заранее (например, «Scheduled maintenance Sunday 2-4am").
Workflow: от incident'а к уведомлению
1. Monitor detects failure: Shopify checkout не отвечает. Monitor отмечен как failed.
2. Alert triggered (30s later): Если failure persists, alert отправляется в ваш Slack канал #acme-alerts.
3. Incident opened: Инцидент автоматически открывается в dashboard. Статус: investigating.
4. Status page updates: Status page для клиента показывает красный "Checkout" component. Клиент видит это на status.acme.com.
5. Customer notification: Опционально, отправить email/SMS клиенту (или клиент сам мониторит status page).
6. Fix & verify: Ваша team фиксит issue. Monitor снова returns success.
7. Incident closed: После 2 успешных проверок incident помечается как resolved. Status page становится зелёной. Отправляется notification о recovery.
Управление alerts: от noise к signal
100+ monitors = 100+ потенциальных alerts. Без фильтрации это noise, и команда начинает ignore alerts. Решение:
Alert rules by priority: Checkout failures (critical) → Slack + SMS + email. Homepage glitches (minor) → Slack only. SSL expiry (informational) → email digest раз в неделю.
Multi-region confirmation: Multi-region monitoring с quorum ловит реальные outages и отфильтровывает temporary glitches. Если 1 из 3 region'ов fails — не alert'им. Если 2+ fails — это реальный issue.
Mute по времени: Мейнтенанс окно (например, Sunday 2-4am)? Отключите alerts для этого monitor на это время. Или используйте maintenance mode в status page.
Escalation rules: Первый alert на Slack. Если не ответили в 5 минут — звонок на телефон. Если не ответили в 15 минут — alert второй person'е.
Scaling от 10 к 500 клиентам
10-30 clients: Один shared аккаунт, все monitors в одном месте. Naming convention: ClientName - Component - Type. Alerts в один Slack канал.
30-100 clients: Начните использовать tags больше. Tags по client, по priority, по сервис-type. Создайте отдельный Slack канал на каждого large client или каждый service type (ecommerce, SaaS, Agency Site).
100-300 clients: Создайте client portal (может быть на вашем сайте). Клиенты логируются, видят только свои monitors и status page. API read-only access для integration'а с вашим dashboard.
300+ clients: Implement'уйте separate monitoring account per client tier (например, Free clients в одном аккаунте, Premium в другом). Или используйте API для создания и управления monitors programmatically.
WordPress vs Shopify для агентств
Разные типы сайтов требуют разных мониторов. Агентство часто делает оба.
| Aspect | WordPress | Shopify |
|---|---|---|
| Критичные monitors | Homepage, API, SSL, DB | Homepage, Checkout, Payment, SSL |
| Hosting failures | Частые, shared hosting | Редкие, managed hosting |
| Plugin conflicts | 20+ плагинов, риск high | Apps встроены, риск lower |
| Performance baseline | 1-3s (зависит от plugins) | 500-800ms (very fast) |
| Revenue risk | Blog: low, E-comm: high | Always high (pure e-comm) |
Integration с вашим dashboard
Если у вас есть свой client portal, интегрируйте мониторинг в него. AtomPing REST API предоставляет доступ к:
Current status: GET /api/v1/monitors/{id}/current — uptime status и последняя проверка.
Incidents: GET /api/v1/incidents — история downtime'ов за период.
Metrics: GET /api/v1/metrics — uptime percentage, average response time.
Альтернатива: Используйте white-label status page из AtomPing и embed'ите как iframe в ваш portal.
Связанные материалы
Полное руководство по uptime monitoring — стартуйте отсюда
WordPress Monitoring Guide — специфика WordPress для агентств
Shopify Monitoring Guide — специфика Shopify для агентств
Status Pages Complete Guide — white-label status pages для clients
SSL Monitoring — обязательный monitor на каждый домен
Best Free Monitoring Tools — сравнение инструментов
FAQ
At what scale do I need a dedicated monitoring tool for agencies?
Once you have 10+ client sites, manual status checks become impossible. At 20+ sites, you need alerts that route to the right person for the right client. AtomPing Free covers 50 monitors—enough for 10-12 WordPress/Shopify sites (4-5 monitors each). Beyond that, AtomPing Pro ($5/month) gives unlimited monitors, which costs less than 1 client site's hosting.
How do I group monitoring by client for 100+ sites?
Create one AtomPing account (shared team), organize monitors by client: prefix each monitor name with client name (e.g., 'Acme Corp - Homepage', 'Acme Corp - Checkout'). Use tags in alerting rules to group by client. Create separate status pages for each client (white-label, branded with their domain). This way, alerts route to the client's email + your team's Slack.
What's the minimal set of monitors per client site?
Minimum 3: (1) homepage HTTP + keyword check, (2) SSL certificate monitoring (30-day alert), (3) DNS check if using custom domain. For WordPress: add REST API endpoint. For Shopify: add checkout endpoint. For SaaS: add login page + API health endpoint. This catches 95% of issues with minimal overhead.
Can I white-label status pages for clients?
AtomPing status pages can be branded with your agency name, your client's name, or custom domain (Pro only). You can give clients read-only access to their own status page via shareable link (no login required) or create a custom client portal that embeds status data via API.
How do I handle alerts for 100+ sites without alerting fatigue?
Centralize alerts to your team (Slack, email), not to individual clients initially. Use alert grouping by client or severity. Create weekly digest reports that go to clients showing uptime %, incident count, and slowest components. Only escalate to client if outage lasts >15 minutes or affects revenue-critical endpoint (checkout, login).
Can I integrate monitoring into my existing agency dashboard?
Yes. AtomPing has REST API for all monitoring data. You can fetch current status, incident history, and metrics for your own dashboard. Or use AtomPing's white-label status pages and embed them via iframe in your client portal. API key provides read-only access to your monitoring data.