Run Monitoring for Your Clients
A practical guide for agencies and MSPs: onboard clients in minutes, route alerts per client, present white-label status pages, and prove your SLA every month.
Overview
If you run websites or applications for clients, monitoring is part of the service whether it is on the invoice or not. This guide walks through the full client lifecycle on upti.my: standing up monitoring for a new client, keeping clients organized as you grow, presenting status under your own brand, proving your SLA every month, and handling day-to-day operations like maintenance windows and incident communication.
Everything runs in a single workspace shared by your whole team: one dashboard, one on-call rotation, every client visible at a glance. There is no context switching between client accounts, and any team member can see the state of every client immediately. If a client contractually requires hard isolation, the Enterprise plan offers multiple workspaces.
The Scale plan is built for this workload: 100 healthchecks, 25 team members, 15-second check intervals, 50 heartbeats, browser (Playwright) checks, white-label branding with custom domains, 5 public status pages with 250 subscribers each, unlimited private status pages, premium workflow nodes (SMS, WhatsApp, Railway self-heal), and 90-day log retention. That is enough headroom to run monitoring for dozens of clients from one place.
Onboard a Client in Minutes
The fastest way to onboard consistently is to treat monitoring as code. Keep a standard healthcheck template in your repo, fill in the client's details, and stand it up with uptimyctl. Every client gets the same baseline coverage, and onboarding stops depending on someone remembering to click through the dashboard.
{
"name": "Acme Corp - Marketing Site",
"type": "http",
"method": "GET",
"url": "https://www.acme-client.com",
"expected_status_code": 200,
"interval_seconds": 60,
"timeout_seconds": 10,
"tags": ["client:acme", "tier:standard"]
}Create an application for the client, then upsert the checks from your template. For clients with many services, apply them all in one command.
# Authenticate (API keys start with upt_)
export UPTIMYCTL_API_KEY=upt_your-api-key
# Create an application for the new client
uptimyctl applications create
# Stand up the standard checks from your template
uptimyctl healthchecks upsert --application <uuid> -f client-template.json
# Or apply many checks at once
uptimyctl healthchecks bulk -f checks.jsonFor whole-workspace configuration, uptimyctl export -f backup.json and uptimyctl import give you a reviewable, version-controllable snapshot of everything â useful both as a backup and as a way to audit what is monitored for whom.
Organize and Route Per Client
As the client count grows, structure is what keeps the dashboard readable and alerts landing in the right place.
- Applications â create one application per client service (or one per client for smaller engagements). Applications group related checks and give each client a clear home in the dashboard.
- Tags â tag every resource with the client it belongs to. Tags drive filtering, grouping, and alert routing across the workspace.
đĄ Use Tags as the Client Boundary
Adopt a consistent tag convention like client:acme on every healthcheck, heartbeat, and application that belongs to a client. One tag then answers "what do we run for Acme?" everywhere: dashboard filters, workflow routing, and status page composition all key off the same label.
Routing happens in workflows. Filter nodes match on severity, source, tags, or specific resources, so each client's incidents can flow to that client's dedicated Slack channel, an email distribution list, or the internal account owner â while everything else goes to your general on-call channel. Deduplicate and Delay nodes keep flapping checks from spamming anyone, and on-call schedules resolve who the current responder is so escalation always reaches a human. On Scale, premium workflow nodes add SMS, WhatsApp, and Railway self-heal actions to the toolbox.
Present Under Your Brand
Give each client their own status page showing only their services. White-label options cover the full surface: your logo (light and dark variants), favicon, brand colors, company name, a custom font, and removing upti.my branding entirely. The page your client sees is your product.
Custom domains complete the picture. The client adds a CNAME record â for example status.client.com pointing to status.upti.my â and SSL is provisioned and renewed automatically. No certificates to manage, per client or otherwise.
The Scale plan includes 5 public status pages, each with up to 250 email subscribers (double opt-in, so lists stay clean). Password-protected private pages are unlimited: they use a shared password with rate-limited verification, and viewers do not need an upti.my account. That makes private pages the natural default for every client beyond your public-page quota â reserve the public pages for clients who want a fully public status site with subscriber notifications.
Prove Your SLA Every Month
The recurring question from every client is the same: did you hit the SLA? SLA reports answer it with a link instead of a spreadsheet. Create a monthly or quarterly report per client, named for them, with a fixed period and an SLA target anywhere from 99% to 99.99%.
Each report gets a shareable public link at app.upti.my/reports/{token}. The numbers are recomputed live, so you can hand the client the link at the start of the month and it fills in as the period progresses. Links are revocable at any time â offboard a client, revoke the link â and the page is print-to-PDF friendly for clients who want a document attached to the invoice.
Shared report pages show uptime and SLA content only. Incident internals and response metrics like MTTR and MTTA stay private to your team, so you can share the link freely without exposing how the sausage is made.
Operate: Maintenance and Incident Communication
When you deploy for a client, schedule a maintenance window covering that client's services. Checks keep running and recording data, but alerts are suppressed, the client's status page shows the maintenance, and subscribers are notified ahead of time. Planned work never pages your on-call and never looks like an outage on the client's page or in their SLA report.
Maintenance windows are automatable, so your deploy pipeline can open one before it ships.
uptimyctl maintenances create \
--title "Acme Corp - platform upgrade" \
--description "Scheduled platform upgrade for Acme production services" \
--start-at "2026-09-01T02:00:00Z" \
--finish-at "2026-09-01T04:00:00Z"When something does break, incident communication runs through the same per-client channels you set up earlier: the workflow posts to the client's Slack channel or email, the incident appears on their status page, and subscribers are kept in the loop. Your team works the incident from the shared dashboard while each client sees only their own picture.
âšī¸ Where to Go Next
Dig into the pieces this guide is built on: the uptimyctl CLI for onboarding as code, status pages for white-label branding and custom domains, and SLA reports for client-ready uptime reporting.