WatchFor

Modern uptime and infrastructure monitoring for humans and AI agents. Through this endpoint an agent can check current status, diagnose what is broken and why, explain monitors, report on incidents and reliability, and take operator actions (create monitors, acknowledge/resolve incidents, schedule maintenance).

Skills

• Check current status
  Answer 'is it up right now?' for a single monitor or the whole organization: current up/down/degraded status, and the health-score snapshot across everything being watched.
  monitoringstatushealthuptime
• List monitors
  Enumerate what the organization is watching — id, name, type, target and current status — so an agent starting cold can discover monitors before checking or explaining one. Optionally filter by a search term, type or status.
  monitoringdiscoveryinventorylist
• Diagnose what's wrong
  Explain what is currently broken and WHY. Returns every active incident with what failed (the exact alert rule and trigger value), a plain-language category (TLS certificate, HTTP 5xx, DNS, latency, reachability…), which monitor, how long it has been down, and whether it has been acknowledged — everything needed to describe the problem to a human.
  monitoringincidentsdiagnosisroot-causetroubleshooting
• Explain a monitor
  Describe one monitor end to end so an agent can explain it: what it watches (type + target), its current status, recent uptime, its alert rules, and its recent incident history.
  monitoringexplainconfigurationuptime
• Report on an incident
  Reconstruct one incident after (or during) the fact: what fired, the trigger values, the full timeline (detected → acknowledged → resolved) with durations, and which monitor it affected. Use it to answer 'what happened?'.
  monitoringincidentspost-mortemtimeline
• Reliability report
  Summarise how reliable things have been over a period: incident counts by severity and mean time to resolution, plus the current health snapshot. Optionally scope to one monitor.
  monitoringuptimereliabilityreportingmttr
• Organization report
  The full organization report for a period, always compared with the previous equal-length period: uptime, incidents, MTTR/MTBF, downtime, response-time trend, per-monitor rows (worst first), type-aware sections (SSL/domain expiry, Core Web Vitals, heartbeat check-ins, DNS blocklists, MCP tool drift, hosts running the agent) and plain-language insights — the same document behind the dashboard Reports page and scheduled report emails. For a lighter incident-only summary use reliability-report.
  monitoringuptimereportingtrendsinsights
• Describe monitor types
  Discover what WatchFor can monitor and how to configure it: every monitor type (http, ssl, dns, tcp, ping, api, playwright/browser checks, browser/Core Web Vitals, heartbeat, …) with its target format and example, its config fields, and the exact alert metrics you can build rules from. Call this BEFORE create-monitor to choose a type and build a valid config. Optionally pass one type to get just its details.
  monitoringdiscoverycatalogconfigurationcapabilities
• List probe locations
  List the probe locations (cities/regions) a monitor can run from — their ids are what create-monitor's `locations` expects. Call this to pick where to check from.
  monitoringdiscoverylocationsregions
• Check servers
  Which servers running watchfor-agent are online, stale or offline right now, with their current CPU, memory and disk usage — the host-side counterpart of check-status. Pass status to narrow (e.g. offline). Each host's monitor_id links it to incidents and status pages.
  hostsserversinfrastructurestatusmonitoring
• Who is on call
  Who is on call right now and until when, who takes over next, the schedule's layers and any active override — and whether the current person can actually be paged (reachable). Ask this before asserting that someone was notified.
  on-callescalationincident-responsepeople
• Create a monitor
  Start watching something on the user's behalf. Provide the target and monitor type — call describe-monitor-types first for exact type ids, target formats and config fields, and list-locations for location ids. Credentials (config fields marked secret, e.g. a mailbox password) are write-only: stored encrypted, returned as "[redacted]". Requires the write scope.
  monitoringprovisioningsetup
• Acknowledge or resolve an incident
  Take ownership of an active incident: acknowledge it (I'm on it — pauses repeat notifications) or resolve it. Requires the write scope. Resolve is accepted asynchronously; if the underlying problem persists the incident re-fires.
  monitoringincidentson-calloperations
• Read or write an incident post-mortem
  The retrospective attached to an incident (plan feature). action: get (default) returns title, status, severity, root-cause category, the sections (summary, impact, root_cause, detection, resolution, what_went_well, what_could_have_gone_better), timeline and action items — or postmortem: null when there is none yet. action: update creates the draft on first use and applies only what you pass: `sections` replaces just the sections named, title/severity (minor|major|critical)/root_cause_category/status (draft|completed), and `add_timeline` [{at, text}] / `add_action_items` [{title, due_date?}] append (repeats skipped). Update requires the write scope; publishing to the status page and deleting stay in the dashboard. Pair with incident-report for the facts.
  incidentspost-mortemretrospectiveoperations
• Schedule or manage maintenance windows
  Suppress alerts and exclude downtime during planned work — useful for an agent doing a deploy that would otherwise trip monitoring. action: create (default), list or cancel. Requires the write scope for create/cancel. Times are ISO 8601; duration in minutes.
  monitoringmaintenancedeploymentsoperations
• Manage scheduled report emails
  Every organization has two report-email cadences — weekly (Mondays) and monthly (the 1st) — with up to 5 recipients each. action: list (default) shows both with recipients and enabled state; set toggles a cadence and/or replaces its recipients. Enabling needs at least one recipient; clearing the recipients disables the cadence. Requires the write scope for set.
  monitoringreportingemailsettings
• List incidents
  List incidents newest first with filters — status (firing/acknowledged/resolved), severity, a single monitor, and a started-at time range. Use this for history and reporting; use diagnose-incidents for what is broken right now.
  monitoringincidentshistoryreporting
• Manage a monitor
  Operate on an existing monitor: pause, resume, run an immediate check, update its fields (name/target/interval/config/tags), delete it, or — page integrity monitors — accept the latest state of the watched pages as the new baseline after a deploy (optional pages[]; fresh: true checks the pages first and accepts that check — use it right after a release; an open integrity incident resolves at once when nothing else differs), or — browser checks — test-script: run the check's saved Playwright script (or a new `script` before saving it with update) once in a sandboxed browser and return the result. Requires the write scope. Delete is permanent — confirm with the user first unless they explicitly asked. Never accept a baseline over unreviewed security findings (new scripts, forms, headers) without the user. Stored passwords read back as "[redacted]" — omit them (or send the mask) to keep them; changing the server, port, TLS mode or login they are used with needs the password again in the same update.
  monitoringoperationslifecycle
• Diagnose a target
  Investigate any public host or URL LIVE from WatchFor's probe fleet — 20+ locations across 7 regions — whether or not it is monitored. By default it runs the whole bundle at once (DNS, DNS propagation everywhere, TLS grade, HTTP headers, and ping from up to 3 regions) and returns one verdict with a status per check, a machine-readable list of what looks wrong and the TLS and security headers grades. Pass `check` to run just one of: smart-audit (Everything at once for a site: domain expiry, HTTPS/TLS, DNS records and email anti-spoofing, as one scored report.); cwv-check (How fast does this page feel to a real browser — LCP, CLS, TBT and the Lighthouse performance score?); dns-lookup (What does DNS return for this name right now — A/AAAA/MX/TXT/NS/CNAME/SOA/CAA/SRV and more, optionally from a specific resolver?); dns-propagation (Has a DNS change propagated yet — what does every one of our probe locations see for this record?); dns-health (Is this domain's DNS set up well — at least two nameservers on separate networks, no lame delegation, parent and zone agreeing, SOA serials in sync, DNSSEC valid, CAA published — as an A+…F grade? Add propagation:true to also grade whether every probe location sees the same answer.); whois (Who owns this domain, when does it expire, which registrar and nameservers does the registry list (live RDAP, cache bypassed)?); ping (Is this host reachable by ICMP from a given location, and what is the round-trip time and packet loss?); traceroute (Which network path do packets take to this host from a given location, and where do latency or loss appear?); port-checker (Is this TCP port open from a given location, and what banner does the service send?); blacklist (Is this IP or host listed on the major DNS blocklists (RBLs) that mail servers consult?); ssl-check (What certificate does this host serve — issuer, subject/SAN names, validity dates and days until expiry?); tls-grade (How good is this host's TLS configuration — an A+…F grade with the protocol versions, cipher suites and weaknesses behind it?); mcp-check (Is this Model Context Protocol endpoint alive and spec-compliant — protocol version, capabilities and the tools it advertises?); http-headers (What does this URL actually return right now — status code, redirect chain, response headers and timing?); api-tester (What does this API endpoint answer to a full request (method, headers, body) — status, headers and the complete response body?); cdn-check (Which CDN serves this URL, which edge answers in each region, is it actually being cached, and where is delivery going wrong?); sitemap-check (Does this domain publish a valid sitemap, is it reachable from robots.txt, and do its URLs resolve?); brotli-check (Does this domain serve Brotli or gzip compression, and how much bandwidth is it saving?); redirect-chain (Where does this URL end up — every redirect hop with its status code and Location, the final URL, and whether the chain is longer, slower or less secure than it should be?); websocket-test (Can a WebSocket be opened to this URL — handshake time, the server's IP, a ping/pong round-trip, and does it answer a message with the expected reply?); smtp-test (Does this mail server accept connections — its banner, whether STARTTLS is offered, whether reverse DNS matches, and whether it relays mail for strangers?); mail-server-check (How secure are this domain's mail servers — an A+…F grade per service (inbound MX, SMTP submission, IMAP, POP3) for TLS, certificates, STARTTLS, plain-text login, open relay, MTA-STS, TLS-RPT and DANE, checked from three regions?); ntp-test (Does this NTP server answer, and what stratum, clock offset, round-trip delay and leap indicator does it report per sample?); email-health (Is this domain protected against email spoofing — are SPF, DKIM and DMARC present and correctly configured?). Graded checks return a `grade`: the same A+ to F letter the WatchFor dashboard shows, its rubric id and the findings that cap it, each with its fix. This measures right now; use check-status or diagnose-incidents for what WatchFor already recorded. Each check spends the organization's per-plan allowance and the response says how much is left.
  diagnosticsnetworkdnstlstroubleshooting

How to call

https://watchfor.io/api/a2a

Listed in

Directories this entry was found in.