Get a monitor
get_monitorOne monitor with its settings, alert channels, tags, dependencies, maintenance windows, the status pages it appears on, its 30 most recent results and the interval it actually runs at under your plan. region_auto is true when InfraNest picked the monitor’s one region for you; it measures that choice when you create the monitor and again every week (region_placed_at, the last time), and moves the monitor only to a region that is clearly faster or when the region’s probes are unavailable. Choosing regions yourself turns it off. When a monitor checked from one region fails, another probe checks it once before the failure counts: the failed result then carries meta.second_opinion with the place it failed from, the place that checked it again (by) and the verdict — confirmed (the failure counted) or contradicted (it did not, and nothing was alerted). A monitor that watches a third-party status page also carries external_service with its components (each with the status it reads as — up, degraded or down — and, where the page gives it, vendor_status, the provider's own word, such as under_maintenance), uptime_90d, and provider_incidents: the incidents open on that status page that touch the components the monitor follows, each with its title, the provider’s vendor_status, its impact (up, degraded or down), a url to the provider’s page, the components it names and the updates the provider posted, newest first. Each incident also carries its key, the provider’s own id for it (its title when the page gives none), which is what you send to say an incident does not affect you; provider_verdicts lists the incidents of that status page you said do not affect you, with the keys each covers, its title, who said so (by) and when (at), until the provider closes them. provider_month says, for this calendar month, how many incidents the provider had on the components the monitor follows, how many of them reached your own monitors (grouped under it, or failing while it lasted, among the monitors that sit behind that provider) and for how many minutes. provider_probe is what InfraNest's probes saw of the provider's open incident, when it names a place one of them stands in or near: state confirmed (one of your monitors behind the provider failed from there, named in failing) or no_effect (they were checked from there and all came back up), with the place, whether the probe is only near it (in the same country), how many monitors were checked and since when; null when there is no such incident, probe or check to go on. One monitor's settings, target, alert channels and current state. For its uptime and response times use monitor_stats; for individual checks monitor_results.
Tool call template
Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {
"monitor_id": "<monitor_id>"
},
"name": "get_monitor"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| monitor_id | Yes | The monitor id, from list_monitors or the number of a search hit monitor:N. | |
| organization_id | No | The organization to read. Leave it out when the token reaches only one. |