update_monitor
shallowsh.fettle/mcp · Verify this server
Change an existing monitor's settings and return it (the get_monitor shape); its type and target cannot change (sending either is a 422). Requires a key with the write scope. monitor_id (uuid, required) is the monitor's id from list_monitors; an id that is not a monitor of this organization (or a deleted one) is a 404. Every other field is optional: name (1 to 255 characters), interval_seconds, timeout_seconds, regions, config, confirmation_threshold, notification_cooldown_seconds, channel_ids, badge_enabled and tags. Only the fields you pass are modified: omit a field to leave it unchanged, and never send null. At least one field besides monitor_id is required (422 otherwise). config is the exception to partial updates: passing it replaces the monitor's entire config, not just the keys you include — any field of that type's schema you leave out is reset to its default. Passing only port on a TCP monitor whose expected_state is closed silently resets expected_state to open unless you include it too. config is a JSON object whose shape depends on type. HTTP takes method (GET, HEAD, POST, PUT, PATCH or DELETE, any case; default GET), expected_status_codes (a non-empty list of codes 100 to 599, default [200]), keyword (case-sensitive substring the response body must contain, at most 1024 characters; not allowed with HEAD), follow_redirects (default true), verify_ssl (default true; false skips TLS verification, which also means that monitor can no longer report a TLS_INVALID failure), request_headers (an object of header name to value: at most 20 headers; a name is at most 128 characters of letters, digits and ! # $ % & ' * + - . ^ _ ` | ~; a value is at most 1024 bytes of printable ASCII, space or tab; the whole object at most 8192 bytes as JSON; two names differing only in case, and the reserved names Host, Content-Length, Transfer-Encoding, Connection, Upgrade, TE, Trailer, Keep-Alive, CF-Connecting-IP and any Proxy-* name, are a 422) and request_body (a string of at most 8192 bytes as UTF-8; requires POST, PUT, PATCH or DELETE), all optional. Reads never return request_header values: each one comes back as the literal __FETTLE_UNCHANGED__, and writing that value back in an update keeps the stored header unchanged (on create it is a 422). PING takes packet_count (1 to 20, default 4), optional. SSL takes warn_before_days (1 to 365, default 14) and port (1 to 65535, default 443), both optional. TCP takes either port (one port, 1 to 65535, expected_state "open" by default or "closed") or ports — a list of 1 to 20 distinct ports that must all be closed: ports requires expected_state "closed", exactly one region and interval_seconds of at least 300, and a check fails when any listed port accepts a connection (the monitor goes DOWN once confirmation_threshold failures confirm it). Passing both port and ports, or neither, is a 422. expected_state values are lowercase. DNS requires record_type (A, AAAA, CNAME, MX, TXT or NS; no default) and takes optional expected_value (at most 2048 characters): when set, one answer must equal it (case-insensitive, ignoring surrounding spaces and a trailing dot; exact for TXT); when absent, any answer passes. For MX the answers are the mail host names only, without priority (mail.example.com, not 10 mail.example.com). A and AAAA both look up every address of the host, IPv4 and IPv6 alike, and any one of them may match; write an IPv6 address in its shortest form. The ports rules above are checked against the monitor after the change, so changing only the interval or the regions of a ports monitor can be rejected too. A monitor that checks a list of ports cannot switch to a single port (422): create a new monitor instead. regions is a list of one or more distinct region codes (get_plan_usage lists them in limits.allowed_regions, for example eu-central; an unknown code is a 403) — SSL and DNS monitors must target exactly one region (422 otherwise). interval_seconds (integer, 30 to 86400) is the time between checks; timeout_seconds (integer, 1 to 120) is how long one check may take. confirmation_threshold (integer, 1 to 10; 3 when not set on create) is how many checks in a row must fail in every region before the monitor goes DOWN and an incident opens. notification_cooldown_seconds (integer, 60 to 86400; 1800 when not set on create) only holds back a duplicate first alert for the same incident within that window. Repeat reminders while the incident stays open and unacknowledged follow the plan's renotify_interval_seconds and renotify_max_count (see get_plan_usage; 0 means no reminders), not this value; it never holds back the recovery alert. Plan limits apply: minimum interval_seconds, how many monitors may use an interval below 60 seconds (only moving a monitor from 60 seconds or more to below 60 takes a slot), and max_regions per monitor. Breaking one is a 403 that names the limit. get_plan_usage shows the limits and current usage. Use pause_monitor and resume_monitor, not this tool, to stop or restart checks. channel_ids (array of channel uuids), when passed, replaces the whole binding; an empty list clears it, after which every verified, active channel is alerted; omit it to leave the binding unchanged; an id that is not an active channel of this organization is a 404; list_channels gives the ids. badge_enabled (boolean) turns the monitor's public status badge on or off; a monitor on a published status page has a badge even when it is false. tags, when passed, replaces the monitor's whole tag list (at most 10); pass an empty list to clear it. Tags are trimmed, lowercased and deduplicated on write, each at most 50 characters of lowercase letters, digits and : _ . / - , starting with a letter or digit. Call list_tags first to reuse the organization's existing names instead of inventing near-duplicates. Example: {"monitor_id": "<id from list_monitors>", "interval_seconds": 600}
1 trials · measured today
update_monitor scores 100.0/100 on Vouch's measured behaviour index, from 1 real invocation trials against sh.fettle/mcp, measured 20 Oct 2026 under methodology v0.2.0. Every measured component scored 100.
Component breakdown
| Component | Weight | Value |
|---|---|---|
| Reliability | 35% | not applicable |
| Schema integrity | 25% | 100.0 |
| Failure behaviour | 15% | not applicable |
| Latency | 15% | not applicable |
| Concurrency | 10% | not applicable |
Tool details
- Transport
- remote + stdio
- Credential class
- gated
- Category
- Developer infrastructure
- Input schema
- not declared
- Output schema
- not declared
- Side-effect classification
- unclassified
Score history
| Day | Score | Tier | Methodology |
|---|---|---|---|
| 2026-10-20 | 100.0 | shallow | v0.2.0 |
Probe evidence
| Probe | Outcomes |
|---|---|
| schema_integrity | pass: 1 |
Raw request/response logs are not archived yet — the outcome counts above are drawn directly from every recorded trial.
Embed this score
Available for every tool, scored or not — not a verification perk. Always links back to this page.
[](https://vouch.tools/tools/3b115832-af77-4f95-8215-0cb6db4bb4c9)