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:

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.

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.

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."

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 full picture of how to bundle monitoring into a maintenance retainer, read Why Agencies Should Include Monitoring in Contracts.

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.