One client calling about their website being down is a support ticket. Five clients calling simultaneously about different outages is an operational failure.
Managed service providers operate at a scale where the tools that work for a single organization break down quickly. You're responsible for uptime across dozens or hundreds of client environments, each with different SLA commitments, different technical contacts, and different definitions of "critical." This guide covers how MSPs can use Vigilmon to monitor client websites, APIs, and infrastructure from a unified dashboard, deliver SLA compliance reports, and automate client-specific alerting and status pages.
The MSP Monitoring Challenge
The structural problem for MSPs is that most monitoring tools are built for a single organization monitoring its own infrastructure. Adapting them for multi-client use requires workarounds: separate accounts, manual aggregation, spreadsheet-tracked SLAs, and constant context-switching between environments.
The specific challenges:
Visibility across clients: Your team needs to see all client monitor statuses in one view, not by logging into 20 separate accounts. When the morning shift starts, the first thing your on-call engineer does should be a single dashboard check—not a tour of individual client portals.
Per-client SLA tracking: A client on an SLA that promises 99.9% monthly uptime needs uptime data tracked against their specific monitors. Manual SLA tracking is error-prone and time-consuming. Automated uptime reporting makes this defensible.
Alert routing to the right people: When a client site goes down, your NOC needs to know immediately. The client's designated technical contact may also need to know, but not for every minor incident. Routing alerts to the right people based on incident type and severity is a configuration problem, not a manual process.
Client-facing status communication: MSP clients increasingly expect a status page for their own environment—something they can bookmark and check when they suspect an issue, rather than calling your help desk.
Onboarding efficiency: Adding a new client to your monitoring stack should take minutes, not hours. With the right structure in place, client onboarding is a checklist, not a project.
Structuring Vigilmon for MSP Use
Account Architecture
You have two main options for organizing client monitoring in Vigilmon:
Option A: Single shared account All client monitors live in one Vigilmon account, organized by naming convention and monitor groups.
Best for MSPs with up to 30–40 clients where your internal team needs unified cross-client visibility. All monitors appear in one dashboard, and your on-call engineers can see everything in a single login.
Option B: Per-client accounts Each client gets their own Vigilmon account, which your team manages.
Best for MSPs offering monitoring as a client-facing service, where clients want to log in and see their own environment, or where client isolation is a contractual requirement.
Recommended hybrid approach: Run a single shared account for your internal NOC view, and create per-client accounts for clients with specific requirements (own login, branded status page, strict data isolation). Most MSPs end up managing 1 internal account and a handful of per-client accounts for their enterprise clients.
Naming Conventions at Scale
When you're managing 200 monitors across 50 clients, naming conventions are the difference between a usable dashboard and an unusable one.
Use this format:
[ClientName] - [ServiceName]
Examples:
Meridian Legal - Main WebsiteMeridian Legal - Client PortalMeridian Legal - SSLLakeside Dental - Booking SystemLakeside Dental - Payment Gateway
This convention means monitors sort alphabetically by client, your team immediately identifies which client is affected from an alert message, and monitor counts per client are visible at a glance.
What to Monitor Per Client
Standard Client Package
At minimum, every managed client should have:
- Primary website — homepage or main URL
- Key functional page — the page that drives business: booking, contact, e-commerce, login
- SSL certificate — Vigilmon alerts 30 days before expiry, catching this before it becomes a client incident
- API or backend (for software clients) — the internal service that powers the frontend
Infrastructure Clients
For clients where you manage servers or hosting:
-
TCP port monitors for open services:
- Port 22 (SSH) — infrastructure accessibility
- Port 3306 or 5432 (MySQL/PostgreSQL) — database availability
- Port 443 (HTTPS) — web services (redundant with HTTP check but catches TCP-level issues)
- Port 6379 (Redis) — cache layer
-
Heartbeat monitors for scheduled jobs: cron jobs, backup processes, nightly syncs. If a client's backup job hasn't run in 26 hours, you want to know before they ask why their last backup is two days old.
Application Clients
For clients running SaaS applications or APIs you manage:
- Monitor key API endpoints (authentication, core business logic, data retrieval)
- Monitor webhook endpoints the application sends to (payment processors, fulfillment, notifications)
- Monitor admin or internal tools separately from the customer-facing product
Automating Client Alert Routing
Layered Alert Structure
Configure Vigilmon alerts in two layers:
Layer 1 — Internal NOC alerts: All monitors alert your internal team immediately. Use a webhook integration to your NOC's Slack workspace or incident management system (PagerDuty, OpsGenie, etc.). This should be a single aggregated channel where your team first sees all client alerts.
Layer 2 — Client-specific alerts: For clients who want direct notification, configure secondary alert recipients on each client's monitors. Options:
- Email alerts to the client's designated technical contact for critical services
- A client-specific Slack webhook if the client has a Slack workspace your team has access to
- A status page (see below) that the client checks on demand rather than receiving push alerts
The goal is to ensure your team sees everything first and is never surprised by a client calling about an outage you didn't know about.
When to Notify the Client Directly
Not every alert needs to go to the client. Use this heuristic:
- Transient failures (resolved in < 5 minutes): Internal alert only; include in monthly SLA report as a note
- Sustained outage (> 5 minutes): Alert your NOC immediately, notify client within 10 minutes
- Total downtime affecting revenue: Alert your NOC and client simultaneously; activate incident response
Client communications should be timely but not noisy. If a client gets a 2 AM alert every time a monitor has a 30-second blip, they'll either disable alerts or call your account manager to complain about monitoring-induced insomnia.
SLA Reporting with Vigilmon
Calculating Monthly Uptime
Vigilmon tracks uptime history per monitor. For SLA compliance reporting, pull each client's monitor uptime data monthly:
Common SLA tiers:
- 99.9% uptime = 43.8 minutes allowed downtime per month
- 99.5% uptime = 3.6 hours allowed downtime per month
- 99.0% uptime = 7.3 hours allowed downtime per month
From Vigilmon's historical uptime data, you can calculate actual uptime percentage per monitor and compare against the committed SLA. Export this data for inclusion in monthly client reports.
Monthly SLA Report Format
Include per-client in your monthly service report:
Client: Meridian Legal
Reporting Period: June 2026
Website Uptime: 99.97% (SLA: 99.9% ✓)
Client Portal Uptime: 99.94% (SLA: 99.9% ✓)
SSL Certificate: Valid — expires 2027-03-15
Incidents:
June 14, 2:47 AM — Website unavailable for 4 minutes (resolved)
Root cause: Hosting provider maintenance
Next Certificate Renewal: September 2026 (auto-alert configured)
This format shows clients the value of your monitoring service in concrete, defensible terms and gives you documentation if SLA credits are disputed.
Client-Facing Status Pages
A status page per client is increasingly expected in managed service contracts. For clients asking "is my website up?"—a status page gives them self-service visibility without calling your help desk.
Status Page Options
Shared account approach: Create a status page with sections per client. The page URL is branded to your MSP (e.g., status.yourmsp.com). Show each client only their section, or provide the full page to enterprise clients who want visibility into your network.
Per-client approach: Create a separate status page per client with a custom domain (status.clientdomain.com). The client sees only their services; the page can be branded for the client. This is the premium option for enterprise clients and a differentiator in sales conversations.
For most MSPs with standard contracts, the shared status page covers 80% of client requests. Per-client branded pages are a value-add for enterprise or mid-market clients.
Client Onboarding Workflow
When onboarding a new client, use this checklist to standardize setup and ensure nothing is missed:
- [ ] Identify key URLs and services (ask the client for a list; augment with technical discovery)
- [ ] Create monitors with
[ClientName] - [ServiceName]naming convention - [ ] Set check frequency: 1 minute for critical services, 5 minutes for secondary
- [ ] Select monitoring regions appropriate to the client's user geography
- [ ] Enable SSL monitoring for all HTTPS endpoints (30-day expiry alert)
- [ ] Configure alert recipients: NOC internally; client contact if requested
- [ ] Add to status page (or create per-client page if appropriate)
- [ ] Document the client's SLA tier and which monitors are in scope
- [ ] Share the status page URL with the client contact
- [ ] Record all monitor IDs in your internal client documentation
Total onboarding time: 15–20 minutes per client with this structure.
Vigilmon for MSPs: Plan Considerations
| Tier | Monitors | Interval | Best For | |---|---|---|---| | Free | 5 | 1 minute | Testing, or single-client MSP pilots | | Pro | Expanded | 30 seconds | MSPs with 5–25 clients and standard monitoring packages | | Self-hosted | Unlimited | Configurable | MSPs managing 25+ clients; infrastructure-focused practices |
The self-hosted option is particularly compelling for MSPs: deploy Vigilmon on a VPS (~$5–10/month) and add unlimited monitors as you grow without per-monitor cost concerns. At 50+ clients with 5–10 monitors each, the cost differential versus a SaaS plan at that scale is significant.
Conclusion
The MSPs that build efficient monitoring operations don't do it by being more careful—they do it by having the right structure in place. Unified visibility across clients, automated alert routing that reaches the right people, SLA data that's captured automatically rather than manually tracked, and client-facing status pages that reduce help desk inbound—these are structural advantages, not effort advantages.
Vigilmon gives MSPs the building blocks to monitor client environments at scale without the overhead of per-client tool configurations or manual aggregation. The result is a NOC team that catches issues before clients call and a monthly SLA report that writes itself.
Start with Vigilmon at vigilmon.online — free for up to 5 monitors, with Pro and self-hosted options that scale with your client base.
Tags: #msp #managedservices #monitoring #uptime #sla #clientmanagement #networking #it #devops #noc