When an agency manages 10-100 client sites, monitoring becomes a logistics problem, not a technical one. 5 sites — you can check manually. 50 sites — you need automation. 100+ sites — without a tool it's simply impossible. And most importantly: clients expect you to know about outages before they do.
Many agencies buy separate monitoring plans for each site (5-10/month per site), spending 500-1000 on their entire portfolio. Or they buy nothing and rely on client complaints. Third option: one plan with 50-500 monitors for 5-15/month that covers the whole portfolio and saves 10 hours/month on downtime support calls.
Why Agencies Skip Monitoring
Reason 1: Cost Per Monitor
Standard tools cost 5-10 per monitor. For 50 clients at 3-5 monitors each = 750-2500/month. That's more than revenue from many clients. Instead, agencies either pay for expensive enterprise tools (500-1000 for 500 monitors) or skip monitoring entirely.
Reason 2: Complexity
Setting up monitoring for each client separately takes time. Different stacks, different hosts, different requirements. Easier to skip it.
Reason 3: False Alert Noise
If every glitch or temporary spike generates an alert, your team quickly starts ignoring them automatically. Monitoring becomes useless.
Monitoring Model for Agencies
One Account, All Clients
Create one AtomPing account for your agency. All 50-100 clients are monitored from one place. Single dashboard, single alert set, single Slack/Telegram integration. This is manageable when organized by clients and tags.
Monitor Names as Hierarchy
Instead of just "Homepage", use: ClientName - Homepage - HTTP. When a Slack alert comes in, you immediately know which client is affected.
Tags for Filtering
Add tags to each monitor: client:acme, type:checkout, priority:critical. Then filter alerts by tags: checkout failures alert only you, homepages go to general channel.
Minimal Monitor Set Per Client
Homepage (HTTP + keyword): Basic check. GET https://client.com + keyword for brand/title. Interval: 2-5 minutes. Catches major outages.
SSL Certificate (TLS): client.com. Alert 30 days before expiry. Often forgotten but very important. If certificate expires, browsers block the site.
DNS (DNS Check): if using custom domain or DNS routing. Verifies A/CNAME records resolve correctly.
WordPress specifics: + REST API endpoint /wp-json/wp/v2. Total: 4 monitors.
Shopify specifics: + checkout /cart with response time assertion. Total: 4 monitors.
SaaS specifics: + login page + API health endpoint. Total: 4 monitors.
Agency overhead: 3 base monitors per site = 150 for 50 clients. Leaves 350 for development, custom checks, and reserve.
Pricing Comparison: Why AtomPing Wins
| 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 |
Logic is simple: Datadog/New Relic charges like a subscription service. AtomPing charges one fixed price for unlimited monitors. Up to 50 monitors free. From 50+ — $5/month for everything.
White-Label Status Pages
Status page is your agency's face to the client. When a site goes down, client sees status page from you, not from Datadog or an uptime bot.
Branding: Each status page can be separately branded: agency logo, client logo, color scheme. AtomPing Pro allows custom domain (status.client.com) for true white-label.
Components: add components to status page: Website, API, Checkout, Email Sending. Each component links to one or more monitors. When monitor fails — component automatically turns red.
Incident History: Status page shows all past incidents with start and resolution times. Client sees that site was down 5 minutes Monday morning.
Status Page Notices: publish notice when planning maintenance, status page shows this to clients in advance (e.g., "Scheduled maintenance Sunday 2-4am").
Workflow: From Incident to Notification
1. Monitor detects failure: Shopify checkout not responding. Monitor marked as failed.
2. Alert triggered (30s later): If failure persists, alert sent to your Slack #acme-alerts channel.
3. Incident opened: Incident automatically opens in dashboard. Status: investigating.
4. Status page updates: Status page for client shows red "Checkout" component. Client sees this on status.acme.com.
5. Customer notification: Optionally, send email/SMS to client (or client monitors status page themselves).
6. Fix & verify: Your team fixes issue. Monitor returns success again.
7. Incident closed: After 2 successful checks, incident marked resolved. Status page turns green. Recovery notification sent.
Managing Alerts: From Noise to Signal
100+ monitors = 100+ potential alerts. Without filtering, this is noise and your team ignores alerts. Solution:
Alert rules by priority: Checkout failures (critical) → Slack + SMS + email. Homepage glitches (minor) → Slack only. SSL expiry (informational) → weekly email digest.
Multi-region confirmation: Multi-region monitoring with quorum catches real outages and filters temporary glitches. If 1 of 3 regions fails — don't alert. If 2+ fail — this is real.
Mute by time: Maintenance window (e.g., Sunday 2-4am)? Disable alerts for that monitor at that time. Or use maintenance mode in status page.
Escalation rules: First alert to Slack. No response in 5 min — call phone. No response in 15 min — alert second person.
Scaling from 10 to 500 Clients
10-30 clients: Single shared account, all monitors in one place. Naming: ClientName - Component - Type. Alerts to one Slack channel.
30-100 clients: Use tags more heavily. Tags by client, by priority, by service type. Create separate Slack channels for large clients or service types (ecommerce, SaaS, agency site).
100-300 clients: Create client portal (can be on your site). Clients log in, see only their monitors and status page. Read-only API access for integration with your dashboard.
300+ clients: Implement separate account per client tier (e.g., Free clients in one account, Premium in another). Or use API to create/manage monitors programmatically.
WordPress vs Shopify for Agencies
Different site types need different monitors. Agencies often handle both.
| Aspect | WordPress | Shopify |
|---|---|---|
| Critical monitors | Homepage, API, SSL, DB | Homepage, Checkout, Payment, SSL |
| Hosting failures | Frequent, shared hosting | Rare, managed hosting |
| Plugin conflicts | 20+ plugins, high risk | Built-in apps, lower risk |
| Performance baseline | 1-3s (depends on plugins) | 500-800ms (very fast) |
| Revenue risk | Blog: low, E-comm: high | Always high (pure e-comm) |
Integration with Your Dashboard
If you have your own client portal, integrate monitoring. AtomPing REST API provides access to:
Current status: GET /api/v1/monitors/{id}/current — uptime status and last check.
Incidents: GET /api/v1/incidents — downtime history over period.
Metrics: GET /api/v1/metrics — uptime percentage, average response time.
Alternative: Use white-label status page from AtomPing and embed as iframe in your portal.
Related Articles
Complete Guide to Uptime Monitoring — start here
WordPress Monitoring Guide — WordPress specifics for agencies
Shopify Monitoring Guide — Shopify specifics for agencies
Status Pages Complete Guide — white-label status pages for clients
SSL Monitoring — mandatory monitor on every domain
Best Free Monitoring Tools — tools comparison
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.