Miterl Setup Guide for Agencies: Monitor Client Sites Fast

Cut Through the Setup Complexity

The most common reason agencies delay adding monitoring to their maintenance stack is setup friction. Manually configuring each client site one at a time does not scale, and a tool that takes hours to set up rarely gets fully adopted.

This guide walks through the complete Miterl initial setup for agencies — from account creation to publishing a branded client status page. By the end, you will have a monitoring foundation you can sell as a managed maintenance subscription with investigation support included.

Step 0: Overview of the Setup Flow

The first client takes 30–40 minutes. Every additional client takes half that time once you have a script or template in place.

Step 1: Account Creation and Plan Selection

Start by signing up for Miterl. Here is how to choose the right plan for an agency:

• Free: Up to 3 monitors — good for testing and internal validation only
• Standard: Multi-client support, white-label (remove "Powered by Miterl"), custom domain on status pages
• Pro: Everything in Standard plus 3 incident investigations per month (with NDA access to server internals), priority support — use this if you want to offer investigation-included maintenance

For reselling monitoring as a managed service, Standard or above is the minimum. White-label allows clients to see only your agency brand throughout.

Step 2: Create a Workspace per Client

Separating clients into individual Workspaces makes permission management and per-client reporting straightforward.

1. Click your workspace name in the top-left of the dashboard
2. Select "Create new workspace"
3. Enter the client name (for example: "Acme Corp")

Assign your project managers viewer access and engineers member access. That way engineers can edit monitoring rules while PMs can check status without touching configuration.

Step 3: Add Monitors

From the Dashboard

Click "+ Add monitor" in the dashboard. For a well-rounded maintenance offering, create the following checks per client site:

Managing HTTP, SSL, and DNS in a single tool prevents a sprawl of per-client tools and keeps both monitoring cost and renewal oversights down. For why consolidation matters when these checks are split across separate tools, see "Why You Should Consolidate DNS and SSL Monitoring Into One Tool."

Via the API (Recommended for Multiple Sites)

For your second client onward, the API is significantly faster. Generate an API key under Settings → API Keys in the dashboard.

# 1. Add an HTTP monitor for a client site
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Acme Corp - Corporate Site",
    "url": "https://acme-example.com",
    "type": "http",
    "interval_seconds": 180,
    "alert_contact_ids": [1, 2]
  }'

# 2. Add an SSL certificate monitor for the same site
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Acme Corp - SSL",
    "url": "https://acme-example.com",
    "type": "ssl",
    "interval_seconds": 86400,
    "ssl_expiry_alert_days": 30,
    "alert_contact_ids": [2]
  }'

Wrapping these calls in a shell script means you can stand up full monitoring coverage for a new client on the same day you sign the maintenance contract.

Step 4: Configure Alert Channels

Setting up notification channels is where agencies often make the biggest gains. Keep internal and client-facing notifications separate from the start.

Slack (Internal On-Call Team)

Slack destinations are created under Alert Contacts in the dashboard by registering a Slack webhook URL. From the API you fetch the contact's ID and wire it into a monitor's alert_contact_ids.

# List existing alert contacts and their IDs
curl -s https://miterl.com/api/v1/alert-contacts \
  -H "Authorization: Bearer YOUR_API_KEY"
# → pass the returned id into alert_contact_ids when creating a monitor

Email (Client Project Manager)

Add the PM's email address under Alert Contacts in the dashboard, then attach it to the relevant monitors. If you do not want Miterl to contact clients directly, wire only internal contacts here and define an internal escalation procedure.

Recommended Channel Strategy

Step 5: Publish the Status Page

A client-facing status page is one of the strongest differentiators when selling monitoring as part of a maintenance package. Clients can check status themselves, which reduces inbound support calls during incidents.

1. Select "Status Pages" from the dashboard
2. Choose which monitors to display and give the page a name
3. Set visibility to public

Custom domain setup (Standard and above):

Add a single CNAME record in the client's DNS:

; Point status.acme-example.com to Miterl's status page infrastructure
status.acme-example.com.    3600    IN    CNAME    cname.miterl.com.

With this in place, clients visit status.acme-example.com and see a fully branded page with no Miterl branding. The "Powered by Miterl" attribution is hidden on Standard plans and above.

Even a small agency can project the same trustworthiness as a large firm by publishing a status page. For the full case, see "Why Small Agencies Need a Status Page."

Step 6: Set Up Maintenance Webhooks

Planned downtime — WordPress major version upgrades, server migrations, cache rebuilds — should never trigger false alerts. Maintenance webhooks suppress monitoring during those windows automatically.

Generate a webhook token under Settings → Maintenance Webhooks in the dashboard.

# Before starting planned maintenance
curl -X POST https://miterl.com/api/v1/webhooks/maintenance/$MITERL_TOKEN/start \
  -H "Content-Type: application/json" \
  -d '{"duration_hours": 2, "name": "WordPress 6.5 upgrade"}'

# --- Run your deployment or maintenance work here ---

# After maintenance completes
curl -X POST https://miterl.com/api/v1/webhooks/maintenance/$MITERL_TOKEN/end

The duration_hours value acts as a safety net: if the END call is never sent, monitoring resumes automatically when the window expires. Add these two lines to your GitHub Actions workflow or deployment script and false alerts disappear entirely.

Beyond suppressing alerts during maintenance, wiring incident webhooks into your CI/CD, auto-recovery scripts, or chatbots lets you automate everything from detection to first response. "Automating Monitoring with Webhooks: A Practical DevOps Guide" walks through real-world integration patterns from a DevOps perspective.

If your clients' sites are built on WordPress, coordinating maintenance windows with uptime monitoring is especially relevant. "Add Uptime Monitoring to WordPress Maintenance Plans" covers how to structure a WordPress maintenance offering that includes external monitoring as a formal, priced line item. For agencies managing SSL certificates across many WordPress sites, "SSL Certificate Monitoring for WordPress Agencies" covers WordPress-specific renewal failure patterns and bulk monitoring setup.

Post-Setup Verification Checklist

• All monitors show "UP" status in the dashboard
• Send a test alert and confirm it arrives in Slack and email
• Status page renders correctly (verify the custom domain too)
• Send a test maintenance webhook and confirm alerts pause during the window
• Project manager has been granted viewer access to the Workspace

Turning the Setup into a Sellable Service

Once monitoring is live, you have everything you need to include it in a maintenance proposal. A straightforward pitch:

"Under the current maintenance contract, you would typically discover a site outage before we do. With 24/7 automated monitoring, we detect issues within an average of three minutes and start investigating before you notice anything is wrong. You also get a monthly uptime report so the value of the contract is visible every month."

If your pitch promises a specific uptime figure, define the measurement scope and target number before you sign. "How to Set an SLA for Maintenance Contracts: Agreeing on 99.9% Uptime Without the Pitfalls" explains how to choose between 99.9% and 99.99%, the client agreement process, and the common traps to avoid, with concrete examples.

As your client roster grows beyond 10-20 sites, operational discipline becomes as important as the initial setup. "10 Tips for Managing Multi-Site Monitoring at Scale" covers workspace organization, alert fatigue prevention, and cost optimization strategies that apply directly once you have the basics from this guide in place.

For pricing guidance and ROI numbers, see Monitoring ROI for Agencies. For the specific pricing models to use when billing clients, see "Pricing Monitoring Into Agency Maintenance Contracts." For the full picture of how to bundle monitoring into a maintenance retainer, read Why Agencies Should Include Monitoring in Contracts. If you are migrating an existing UptimeRobot setup while following this guide, the "UptimeRobot to Miterl Migration Guide" covers the full migration process including a script to recreate your monitors automatically.

When onboarding a new client site, use the "Pre-Launch Monitoring Checklist" to ensure all eight monitoring items are live before the site goes public.

The complete operations scenario — Workspace separation, incident investigation requests, and automated monthly reports — is covered in the Web Agency use case.

Full API and feature documentation is at /en/docs. Common pre-sales questions are covered in the FAQ.

Once the initial setup is complete, consider building a dedicated client-facing view so clients can check their own site status without contacting you. Miterl's client portal lets you control exactly which monitors and data each client can see, removing a whole class of "is the site up?" emails. See "Visualizing Monitoring Data Through a Client Portal" for the full setup walkthrough and permission design.