Watchfor Monitoring

WatchFor monitoring

WatchFor is an uptime & infrastructure monitoring platform with 25 check types, 18 on-demand diagnostics from its own probe fleet, and multi-location confirmed alerting (Down = verified from several regions; one failed check = Degraded, not an outage).

Setup

Preferred: connect the MCP server — https://watchfor.io/api/mcp (Streamable HTTP). OAuth-capable clients authenticate with no manual key (browser consent flow). Otherwise pass an org API key: Authorization: Bearer wf_live_… (created in dashboard → Settings → API keys; read or read+write scope).

REST alternative: https://watchfor.io/api/v1 — same auth, OpenAPI 3.1 at https://watchfor.io/openapi.json. Try without any account: https://watchfor.io/api/v1/sandbox (read-only sample data).

Core workflows

Is everything up?

1. get_summary (MCP) or GET /api/v1/summary — monitor counts by status, active incidents, health score. One call answers the question.

Diagnose what's broken

1. get_summary → if incidents are active:
2. list_incidents with status=firing — each incident includes the exact rule that fired (metric, operator, threshold) and its duration.
3. get_monitor_checks with success=false for the affected monitor — the failing probes with per-location detail.
4. Report: affected monitor, rule, duration, likely cause, next step.

Investigate something that is not monitored yet Monitors tell you what has been happening; diagnostics tell you what is true right now, from a specific place. Use them when the question is "has DNS propagated?", "what does the server return from Germany?", "is the port open from Singapore?".

1. list_diagnostics — the 18 checks, what each answers, and the allowance left on the plan.
2. run_diagnostic with a slug (dns-lookup, dns-propagation, tls-grade, http-headers, ping, traceroute, port-checker, email-health, …), a target and an optional location.
3. Or diagnose_target — DNS, propagation, TLS, headers and ping from up to three regions in one call, returned as a single verdict with findings.

A check that fails or times out comes back successful HTTP with success:false — that is the answer, not an error. Runs share the plan allowance with the dashboard's Toolbox, so pace them: the response carries what is left.

Create a monitor

1. ALWAYS call get_monitor_types first — it lists every type's target format, config fields and the EXACT alert-metric strings.
2. list_locations for location ids.
3. create_monitor (write scope) — interval is seconds, validated against the plan minimum.
4. Suggest alert rules using metric strings from step 1; create with create_alert_rule after the user confirms.

Silence planned downtime

• create_maintenance_window — alerts suppressed and uptime excluded for the window; checks keep running.

Rules

• Validation errors name the allowed values — correct the request and retry; do not guess enum values.
• delete_monitor is irreversible (removes rules + incident history): confirm with the user first.
• Back off on HTTP 429 using Retry-After.
• Do not use WatchFor for logs, APM traces or metrics ingestion.

More: https://watchfor.io/agents.md · https://watchfor.io/docs/api