monitor-health-summary

name	monitor-health-summary
description	Generate a one-shot health snapshot — monitor counts by state, which are currently down, recent incident count, and total downtime — useful as a daily brief or ad-hoc check.
tags	["monitoring","health","summary","uptime","downtime","uptimerobot"]

Monitor health summary

Preflight — read first. If you cannot see any uptimerobot:* MCP tools in your tool list, invoke the uptimerobot:setup skill before doing anything else. Do not tell the user the MCP is misconfigured — setup's Step 0 detects the common case (server connected, tools loaded after session start) and resolves it without re-keying.

A fast overview of your monitoring account's current state. Combines account-wide stats, live down/paused lists, and recent incident activity into a single report.

Use this when the user asks "how's everything looking?", "give me a health check", "what's our monitoring status?", or "morning standup brief".

Step 1 — Account-wide snapshot

{ "timeRange": "24h" }

Call get-monitor-stats. Returns:

• Counts of monitors in each state (up, down, paused, notStarted).
• Overall uptime percentage across active monitors.
• Total incident count and downtime duration for the range.
• Plan-level monitor cap vs. current usage.

Adjust timeRange if the user wants a longer window (e.g. "7d" for a weekly brief).

Step 2 — List currently down monitors

{ "filter": ["DOWN"], "limit": 50 }

Paginate with cursor until hasMore: false. Collect each monitor's id and friendlyName and the timestamp from get-monitor-details if you need exact downtime duration.

If there are zero DOWN monitors, skip step 3 and say so clearly.

Step 3 — List paused monitors

{ "filter": ["PAUSED"], "limit": 50 }

Paginate until hasMore: false. You only need names and count — no need to fetch details for each.

Step 4 — Recent incidents

{ "timeRange": "24h", "limit": 25 }

Call list-incidents. Paginate until hasMore: false. Collect total count and sum of incident durations for the report footer.

Step 5 — Spot-check degraded monitors (optional)

For each DOWN monitor (limit to the top 3–5 by name if there are many), check response times to distinguish a full outage from degradation:

{ "monitorId": 800123456, "timeRange": "1h", "bucketSize": 60 }

Only call this when the user wants more detail or when the monitor count is small. Avoid looping over dozens of monitors.

Output format

Health summary — 2026-05-01 (last 24h)

Status: 2 DOWN · 3 PAUSED · 42 UP  (47 total)
Uptime: 98.7% across active monitors
Incidents last 24h: 4  (total downtime: 2h 13min)

Currently DOWN (2):
  • prod-api (800123456) — down since 14:02 UTC (~58 min)
  • staging-db (800123457) — down since 13:45 UTC (~1h 15min)

Paused (3): deploy-preview, load-test-env, sandbox-api

If everything is up:

Health summary — 2026-05-01 (last 24h)

Status: 0 DOWN · 1 PAUSED · 46 UP  (47 total)
Uptime: 100.00% across active monitors
Incidents last 24h: 0

All active monitors are up. One monitor paused: sandbox-api.

Common mistakes

• Counting NOT_STARTED monitors as "down" — they're unstarted, not failing. Exclude them from down/up tallies or list them separately.
• Reporting PAUSED monitors as "healthy" — they're unmonitored. Always surface them so the user is aware.
• Looping get-response-times over every UP monitor — expensive and unnecessary. Reserve it for DOWN or flagged monitors.
• Forgetting to paginate list-monitors or list-incidents — with many monitors or incidents you'll silently under-count.
• Confusing notStarted with paused — they're different states. notStarted means the monitor was never activated.

Related

• incident-response — to triage what the summary surfaces as down.
• stats — simpler alternative when the user only wants uptime % without the full breakdown.
• incidents — to list and investigate individual downtime events.
• bulk-pause — to act on the paused-monitor list (resume all at once).
• conventions — time range formats and pagination patterns.