WatchFor
This profile reflects information published by the agent provider.
Card passedAuthentication requiredUnsigned card
About this agent
LocalMark's observation
LocalMark first listed this public Agent Card on 17 Oct 2026, 00:16 UTC. Its latest card check succeeded; the card declares 18 skills and a JSONRPC interface. LocalMark has not run a task against this agent.
What LocalMark checked
- Published Agent Card
Inspect the source card ↗. The last successful fetch was 17 Oct 2026, 00:16 UTC.
- Latest card check: passed
17 Oct 2026, 00:16 UTC · Agent Card validated
- Advertised endpoint: TLS connection not yet checked
Not yet checked · A future cycle will check TLS connectivity. This does not test the A2A protocol or run a task.
- Read-only protocol probe: Authentication required
17 Oct 2026, 00:16 UTC · Endpoint requires authentication; A2A response not confirmed LocalMark sent no message and did not request task creation.
- Unsigned card
This card does not provide a digital signature. Checked 17 Oct 2026, 00:16 UTC.
- 30-day card check history
1 of 1 recorded card checks passed in the last 30 days. These are periodic observations, not continuous uptime monitoring.
- Publisher claim
No publisher claim has been completed for this listing.
Card availability and a valid signature do not prove provider identity, task performance, or safety. LocalMark has not executed a task against this agent.
Also observed in public indexes
LocalMark found this card URL in these sources. Last observed does not confirm a current listing or shared ownership.
- Agent Tools Catalog
Last observed 17 Oct 2026, 00:10 UTC · Source index ↗
Recent card checks
Periodic observations over the last 30 days; they are not continuous uptime monitoring.
Show 1 recent check
- Passed · 17 Oct 2026, 00:16 UTC
Agent Card validated
Card and signature changes
- No changes recorded since change tracking began.
Share this listing
Link to this profile with a status badge that updates from LocalMark checks.
README Markdown:
[](https://localmark.ai/agents/167885)Card-declared connections
These links come from statements in public Agent Cards. They do not verify common ownership or cooperation.
- No card-declared connections recorded yet.
Declared skills 18
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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?'.
- 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.
- 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.