Uptimepage

Monitor history

get_monitor_history

Read-only

One monitor's history over a window (1h/24h/7d/30d): uptime, latency series, a per-region split of the same window, failures with error text, and incident windows. Pass region to narrow it to one probe region and tell a partial outage from a total one. Read-only.

Input Schema

Name	Required	Description
`id`	Yes	The monitor id (from `list_monitors`).
`region`	No	Narrow uptime, the latency series, and the region breakdown to one probe region (an id the monitor is assigned to, from `get_monitor.regions`). Omit for every region together.
`window`	Yes	Time window: `1h`, `24h`, `7d`, or `30d`.

Output Schema

Name	Required	Description
`region`	No	The region this answer was narrowed to, or `null` for all of them.
`uptime`	No	Uptime percentage over the window. `null` when the window holds no checks — that is unknown, not zero. Unfiltered it counts confirmed incidents; under a `region` filter it is that region's raw check rate, so the two are not comparable.
`regions`	Yes	Per-region split of the same window, so a partial outage is visible. Always every region the monitor runs in, including under a `region` filter, and empty when it runs in only one. Regions that ran no checks in the window are omitted; this reads per-minute data, which is kept for 30 days, so at the far edge of a `30d` window a region can be short of samples or absent while the headline numbers still cover it.
`failures`	Yes	Confirmed failures on the monitor as a whole. A `region` filter does not narrow these: an incident is raised for the monitor, not per region.
`incidents`	Yes	Incident windows on the monitor as a whole, unnarrowed by `region` for the same reason as `failures`.
`latency_series`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 23, 2026

addedOutput schema / $defs / IncidentWindow / properties / paused

Added value: +{
+  "description": "Stretches inside the window the monitor was paused in, so nothing\nchecked it. The incident stays open across them; `uptime` does not\ncount them.",
+  "items": {
+    "$ref": "#/$defs/PausedStretch"
+  },
+  "type": "array"
+}

changedOutput schema / $defs / IncidentWindow / required

Previous value: -[
-  "opened_at",
-  "counts_as_downtime",
-  "impact",
-  "recovered"
-]New value: +[
+  "opened_at",
+  "counts_as_downtime",
+  "impact",
+  "recovered",
+  "paused"
+]

addedOutput schema / $defs / PausedStretch

Added value: +{
+  "description": "A stretch an incident's monitor was paused in.",
+  "properties": {
+    "from": {
+      "description": "RFC 3339 start.",
+      "type": "string"
+    },
+    "until": {
+      "description": "RFC 3339 end, when it was resumed, or `null` while still paused.",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "from"
+  ],
+  "type": "object"
+}

Changed6 schema fields changedOct 9, 2026

changedOutput schema / $defs / IncidentWindow / properties / counts_as_downtime / description

Previous value: -"`false` when this window is listed but explains none of the `uptime` gap."New value: +"`false` when this window is listed but kept out of `uptime`."

addedOutput schema / $defs / IncidentWindow / properties / impact

Added value: +{
+  "description": "`major_outage`, `partial_outage` or `degraded`. A counted window\nexplains the `uptime` gap by it: a major outage in full, a partial\noutage for 30% of its length, a degraded one not at all.",
+  "type": "string"
+}

addedOutput schema / $defs / IncidentWindow / properties / recovered

Added value: +{
+  "description": "Stretches inside the window the monitor was back up in before the\nfailure returned. `uptime` does not count them.",
+  "items": {
+    "$ref": "#/$defs/RecoveredStretch"
+  },
+  "type": "array"
+}

addedOutput schema / $defs / IncidentWindow / properties / recovering_since

Added value: +{
+  "description": "RFC 3339 moment the monitor came back up while the incident waits out\nits recovery period. `uptime` stops counting the window here.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / $defs / IncidentWindow / required

Previous value: -[
-  "opened_at",
-  "counts_as_downtime"
-]New value: +[
+  "opened_at",
+  "counts_as_downtime",
+  "impact",
+  "recovered"
+]

addedOutput schema / $defs / RecoveredStretch

Added value: +{
+  "description": "A stretch an incident was back up in.",
+  "properties": {
+    "from": {
+      "description": "RFC 3339 start.",
+      "type": "string"
+    },
+    "until": {
+      "description": "RFC 3339 end, when the failure came back.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "from",
+    "until"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedSep 2, 2026

addedOutput schema / $defs / IncidentWindow / properties / counts_as_downtime

Added value: +{
+  "description": "`false` when this window is listed but explains none of the `uptime` gap.",
+  "type": "boolean"
+}

changedOutput schema / $defs / IncidentWindow / required

Previous value: -[
-  "opened_at"
-]New value: +[
+  "opened_at",
+  "counts_as_downtime"
+]

First observedAug 11, 2026

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

readOnlyHint=true already covers the safety profile, and the description reinforces it with 'Read-only.' It adds genuine value by disclosing the payload composition (per-region split, failure error text, incident windows), though the existing output schema would carry some of that weight.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence plus one purpose clause and a safety tag — dense but every listed item is informative. The comma-separated enumeration is slightly heavy but not wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a full input schema, an output schema, and a readOnly annotation, the description supplies everything else an agent needs: what the payload covers, the purpose of region filtering, and the safety profile. No material gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3; the description earns above baseline by explaining what `region` actually scopes (uptime, latency series, region breakdown) and why an agent would narrow it, which goes beyond the schema's wording. `id` and `window` need no extra explanation given the schema's enumerations.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('one monitor's history') and enumerates exactly what the response contains (uptime, latency, region split, failures, incident windows). This clearly separates it from get_monitor (config) and list_monitors (enumeration).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the operational purpose of the `region` param — telling a partial outage from a total one — which gives concrete when-to-use context. It does not explicitly contrast with get_monitor or list_monitors, so it stops short of full alternative routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Uptimepage tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Monitor history

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources