5 Monitoring KPIs Web Agencies Should Report to Clients

The "What Do We Actually Report?" Problem

Most agencies know they should report uptime data to clients. Fewer know what else to include — or how to frame numbers so clients understand their significance without becoming anxious.

This guide covers the five monitoring-specific KPIs worth including in every monthly maintenance report: uptime rate, average response time, SSL certificate validity, mail authentication status, and mean time to recovery. These are distinct from SEO and conversion metrics — they are the indicators of infrastructure health that only your monitoring toolchain can supply.

Why Monitoring KPIs Need Their Own Section

Website performance data falls into two buckets:

Marketing metrics tell clients whether the site is attracting and converting visitors. Monitoring metrics tell clients whether the site is available and healthy enough for those visitors to reach it in the first place. Both matter, and both belong in a complete monthly report.

KPI 1: Uptime Rate

What It Measures

Uptime rate is the percentage of time a site responded successfully during the reporting period. Its inverse — downtime — is what clients actually feel. One minute of downtime on a high-traffic checkout page can mean meaningful lost revenue.

How to Frame It for Clients

"This month your site achieved 99.97% uptime (9 minutes of downtime from one brief incident). That exceeds the 99.9% industry baseline."

Comparing against the 99.9% baseline gives the number context without requiring the client to know what the number intrinsically means.

How to Retrieve It with Miterl

# Fetch 30-day uptime for a monitor
curl -s "https://miterl.com/api/v1/monitors/1" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  | jq '{name, uptime_30d, status}'

Output:

{
  "name": "Client A — Corporate Site",
  "uptime_30d": 99.97,
  "status": "up"
}

KPI 2: Average Response Time

What It Measures

Response time (TTFB — time to first byte) is how long it takes for the monitoring probe to receive the first byte of a response after sending an HTTP request. Even a site that never goes fully down can degrade user experience if it responds slowly.

Google's research shows that as page load time increases from 1 to 3 seconds, the probability of bounce increases by 32%. For server-side response (TTFB), keeping it under 500ms is a common target.

How to Frame It for Clients

"Average response time this month was 340ms, down from 380ms last month — meaning your site is responding faster to visitors."

Trend comparison (month over month) is more meaningful to most clients than the absolute number.

# List response times across all monitors
curl -s "https://miterl.com/api/v1/monitors?per_page=50" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  | jq -r '.data[] | "\(.name)\t\(.avg_response_time_ms // "N/A") ms"'

KPI 3: SSL Certificate Days Remaining

What It Measures

When an SSL certificate expires, browsers display a security warning that effectively blocks visitor access — a 0% uptime event with no alert from most monitoring setups unless you have SSL monitoring in place.

Auto-renewal is reliable until it is not. WordPress caching plugins can block the ACME challenge used by Let's Encrypt, server migrations can leave certbot configuration behind, and security plugins can intercept the certbot agent. For the WordPress-specific failure modes and how to monitor against them, see "Managing SSL Certificate Expiry Across WordPress Client Sites."

Recommended Alert Thresholds

How to Retrieve It with Miterl

# List all SSL monitors with expiry dates
curl -s "https://miterl.com/api/v1/monitors?per_page=100" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  | jq -r '.data[] | select(.type == "ssl") | "\(.name)\t\(.status)\t\(.expires_at)"'

Monthly report line: "All SSL certificates valid. Nearest expiry: 85 days remaining (Month YYYY)."

KPI 4: Mail Authentication Status (SPF, DMARC, DKIM, MX)

What It Measures

Mail authentication records — SPF, DMARC, DKIM, and MX — can break silently after any DNS edit. The first sign of a problem is usually a client telling you "our emails aren't getting through," well after the damage has been done and some messages are lost permanently.

Including mail authentication status in your monthly report proves that you are actively maintaining something clients otherwise assume is always working.

Report Format

When all records are healthy, one line suffices: "Mail authentication records (SPF, DMARC, DKIM, MX) all healthy." When something breaks, Miterl alerts before the client notices.

# Check mail authentication monitor status
curl -s "https://miterl.com/api/v1/monitors?per_page=100" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  | jq -r '.data[] | select(.type | test("spf|dmarc|dkim|mx")) | "\(.name)\t\(.status)"'

KPI 5: Mean Time to Recovery (MTTR)

What It Measures

MTTR is the average time from incident start to resolution. Two agencies can have identical uptime rates but very different service quality depending on MTTR: 40 one-minute outages spread across a month are a very different maintenance picture from a single 40-minute outage handled promptly.

A low MTTR demonstrates that your team responds fast — a concrete proof point for the value of having a dedicated agency managing the site.

How to Retrieve It with Miterl

# List resolved incidents for a monitor
curl -s "https://miterl.com/api/v1/incidents?monitor_id=1&status=resolved&per_page=10" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  | jq -r '.data[] | "\(.started_at)\t\(.duration_seconds) seconds"'

Calculate MTTR from duration_seconds:

# Calculate MTTR from a list of incident durations
incidents = [120, 300, 90, 480, 60]  # seconds
mttr_seconds = sum(incidents) / len(incidents)
mttr_min = mttr_seconds / 60
print(f"MTTR: {mttr_min:.1f} minutes")
# → MTTR: 17.5 minutes

How to Frame It for Clients

"The one incident this month was resolved in 15 minutes from the time our monitoring alert fired. Industry average recovery times typically run 40–60 minutes."

Monthly Report Template

=== [Client Name] — Site Monitoring Report (Month YYYY) ===

[Uptime]
Monthly uptime: 99.97% (industry baseline: 99.9%)
Downtime total: 9 minutes (1 brief incident)

[Response Time]
Monthly average: 340ms (prior month: 380ms)
Status: Healthy

[SSL Certificate]
Status: Valid
Days remaining: 85 days (next expiry: Month YYYY)

[Mail Authentication]
SPF / DMARC / DKIM / MX: All healthy

[Mean Time to Recovery]
Incidents this month: 1
Average recovery time: 15 minutes

Live status page: https://status.example-client.com

For the full script that pulls these five data points from the Miterl API and generates this report automatically for every client, see "Automating Monthly Uptime Reports for Clients."

Connecting KPIs to Pricing

Once you are delivering a five-KPI monthly report consistently, the value of your maintenance retainer is visible every month rather than invisible until something breaks. This is the foundation for tiered maintenance pricing:

• Basic: Uptime only ($20–40/month)
• Standard: Uptime + SSL + mail auth status ($40–80/month)
• Premium: All five KPIs + status page + monthly report delivery ($80–150/month)

For the full pricing structure, see "Pricing Monitoring Into Agency Maintenance Contracts." For SLA-level reporting with permitted downtime calculations, see "Uptime SLA Report Guide for Maintenance Contracts."

Summary

The five monitoring KPIs that belong in every agency client report are:

1. Uptime rate — the percentage of time the site was fully available
2. Average response time — server-side speed that directly affects user experience
3. SSL certificate days remaining — the safety margin before an expiry incident
4. Mail authentication status — SPF, DMARC, DKIM, and MX health
5. Mean Time to Recovery (MTTR) — how quickly your team resolves incidents

Together, these five numbers tell a complete story about infrastructure health that no marketing dashboard can replicate. Sign up for free to start pulling these metrics automatically, and see the documentation for configuration details. Agency-specific use cases are covered in the use cases section, and common setup questions are answered in the FAQ.