Check if any website is down, from two continents, with uptime history and TLS expiry
Scored across 5 tools
Each tool targets a distinct operation, but check_site and site_history both report current state and user-report counts, which could cause some mis-selection. The descriptions mitigate this by noting that site_history is only for monitored sites and check_site is the fallback for anything else.
Most names follow a clear verb_noun pattern: check_certificate, check_site, list_monitored_sites, list_outages. site_history breaks the pattern by omitting a verb, though the inconsistency is minor and the names remain readable.
Five tools are well-scoped for a website status and monitoring service. Each earns its place: live checks, certificate checks, monitored inventory, current outages, and history.
The tool surface covers the main user needs: live status, certificate expiry, monitored-site inventory, ongoing outages, and historical uptime. There are no significant missing operations for a read-only status service.
Reads the HTTPS certificate of a public domain and reports days until expiry, the expiry date and the issuer.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to inspect, e.g. "example.com". |
| Name | Required | Description |
|---|---|---|
| state | Yes | |
| domain | Yes | |
| issuer | Yes | |
| validTo | Yes | |
| daysRemaining | Yes | Negative once expired |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description usefully adds that the tool performs a live read of a public domain's HTTPS certificate, but it does not surface failure modes, latency, or other behavioral nuances beyond what annotations and the output schema already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise, front-loaded sentence that names the action, the resource, and the key outputs without filler or restating the tool name. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only, idempotent tool with an output schema and safety annotations, the description is sufficient for correct invocation. It does not cover edge cases or alternative tool selection, but the low complexity and existing structured metadata make this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single `domain` parameter with an example, giving 100% coverage. The description adds only the qualification 'public domain' and ties the parameter to HTTPS certificate retrieval, which is marginal extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action (Reads), resource (HTTPS certificate of a public domain), and expected outputs (days until expiry, expiry date, issuer). This clearly distinguishes it from sibling tools like check_site or list_outages, which concern site status rather than certificate details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for certificate-expiry checks, and the sibling names make it inferable that check_site covers availability. However, it does not explicitly say when to prefer this tool over alternatives or when not to use it, leaving the selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live up/down check of any public website from an independent server (Singapore; Boston for sites that geo-block Singapore). Returns a one-sentence verdict plus status code, latency, resolved IP, redirect target, the view from the other region when available, and how many users reported problems in the last hour. Results are cached 30 s per domain.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain or URL to check, e.g. "github.com" or "https://www.reddit.com/r/all". Scheme, path, port and query are ignored; the host is checked as given. |
| Name | Required | Description |
|---|---|---|
| ip | No | |
| up | Yes | |
| tls | No | |
| url | Yes | |
| state | Yes | |
| domain | Yes | |
| reason | Yes | |
| scheme | No | |
| server | No | |
| status | Yes | |
| curated | Yes | true if the site is one of the monitored sites |
| regions | Yes | Fresh result from each region that has one |
| finalUrl | No | |
| checkedAt | Yes | ISO 8601 |
| latencyMs | Yes | |
| statusUrl | Yes | |
| redirected | No | |
| checkedFrom | Yes | sg = Singapore, us = Boston |
| reportsLastHour | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld/idempotent annotations, the description discloses non-obvious behavior: server locations, geo-block fallback, caching for 30 seconds, and the exact set of returned fields. It also clarifies scope by noting the check is live and independent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The opening phrase states the core purpose, and the second sentence efficiently packs return values, regional behavior, user-report data, and caching into a digestible list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with an output schema, the description covers operational context: server location, geo-block handling, caching, and returned verdict. Nothing important is missing for an agent to call this tool appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the domain parameter is already well documented, including ignored parts such as scheme, path, port, and query. The tool description does not need to add much parameter detail; its 'any public website' phrasing adds only minor reinforcement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Live up/down check of any public website'. It clearly distinguishes itself from sibling tools like check_certificate, site_history, and list_outages by focusing on immediate availability from an independent server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the usage context clear: use this for an immediate, live availability check of any public website, with independent-server visibility and a 30-second cache. It does not explicitly name alternatives or exclusion cases, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The 634 sites checked every 5 minutes, grouped in 17 categories. Without arguments returns the category list with counts; filter by category or a text query to get domains (at most 200 per call).
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Case-insensitive substring of the domain or display name, e.g. "bank" or "google". | |
| category | No | Category slug or name: social, streaming, ai, work, developer, shopping, finance, banks, gaming, telecom, government, education, messaging, news, travel, health, dating. |
| Name | Required | Description |
|---|---|---|
| query | No | |
| sites | No | |
| total | Yes | |
| matched | No | |
| category | No | |
| returned | No | |
| categories | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds valuable behavior beyond these: the 5-minute check interval, 17 predefined categories, the 200-result cap per call, and the mode-dependent output. It fully discloses what happens with and without arguments, with no contradiction to the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the key facts (sites, frequency, categories), and wastes no words. Every clause contributes to understanding invocation behavior or output scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and annotations cover safety, the description covers the essential invocation modes, the pagination limit, and the grouping structure. An agent has enough information to call the tool correctly without needing additional explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds the semantic that filters produce domains and no-args produce categories, but it does not clarify whether query and category are mutually exclusive or combined. It provides marginal extra meaning beyond the schema, not enough to raise the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it lists the 634 monitored sites, details their check frequency, and explains the two output modes (category list or domain list). It clearly differentiates from siblings like check_site or site_history by focusing on the list of sites with stored history, so an agent can select it without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: without arguments returns categories with counts; filtering by category or query returns domains. It does not explicitly route to alternatives or state when not to use this tool, but the behavior is unambiguous enough for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the monitored sites (634 across 17 categories) that are confirmed down right now: two consecutive failed checks from their home region and no other region seeing them up in the last 15 minutes. Optional category filter.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional category slug or name: social, streaming, ai, work, developer, shopping, finance, banks, gaming, telecom, government, education, messaging, news, travel, health, dating. |
| Name | Required | Description |
|---|---|---|
| asOf | Yes | |
| down | Yes | |
| category | Yes | |
| monitored | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnly and idempotent annotations by explaining the meaning of 'confirmed down'—two consecutive failed checks from the home region and no other region seeing it up in the last 15 minutes. This behavioral context helps the agent interpret the results correctly without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose, then condenses the confirmation rules into a clearly parenthetical explanation. There is no filler, and every clause contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one optional parameter, full schema coverage, an output schema, and readOnly/idempotent annotations, the description fills the critical gap by defining what 'confirmed down' means. It does not need to describe the return shape, as the output schema covers that, making it complete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, fully documenting the optional 'category' parameter with its allowed values. The description adds only 'Optional category filter,' which repeats schema information and provides no additional behavioral nuance, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Lists the monitored sites ... that are confirmed down right now.' The title reinforces the purpose, and the confirmation criteria distinguish it from siblings like list_monitored_sites or check_site. An agent can immediately tell what this tool does and what makes it unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by defining the precise scope (confirmed down sites with a 15-minute window) and mentions the optional category filter. However, it never explicitly contrasts with alternatives such as list_monitored_sites or check_site, nor does it state when it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Uptime percentage over 24 h and over the requested window (up to 7 days), the list of outages in that window, when the site was last seen down, the current state and user-report counts. Only for monitored sites (see list_monitored_sites); use check_site for anything else.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Window in days (1–7, default 7). | |
| domain | Yes | A monitored domain, e.g. "github.com". |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| days | Yes | |
| name | Yes | |
| domain | Yes | |
| current | Yes | |
| category | Yes | |
| lastDown | Yes | |
| incidents | Yes | |
| statusUrl | Yes | |
| uptime24h | Yes | Percent, null if no data yet |
| reports24h | Yes | |
| checkedFrom | Yes | sg = Singapore, us = Boston |
| uptimeWindow | Yes | Percent over `days`, null if no data yet |
| reportsLastHour | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description need not restate safety. It adds useful context about the monitored-site restriction and the specific time windows and data returned, which helps an agent predict behavior without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The first sentence enumerates visible outputs and constraints; the second gives direct sibling routing. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity read-only tool with a complete input schemaebb and an output schema, the description is fully sufficient. It covers scope, usage boundaries, and alternatives, leaving no critical gap for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed descriptions for both domain and days. The description merely restates the 7-day window and adds the monitored-site constraint, providing no new parameter-level meaning beyond what the schema already covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's data outputs: uptime percentages, outages, last-down time, current state, and user-report counts for a site. It also differentiates itself from siblings by explicitly limiting use to monitored sites and pointing to check_site for all other cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: only for monitored sites, referencing list_monitored_sites, and directs agents to use check_site for anything else. This directly answers the selection question and prevents misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_certificate1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "daysRemaining": {
+ "description": "Negative once expired",
+ "type": "number"
+ },
+ "domain": {
+ "type": "string"
+ },
+ "issuer": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "state": {
+ "enum": [
+ "valid",
+ "expiring soon",
+ "EXPIRED"
+ ],
+ "type": "string"
+ },
+ "validTo": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "domain",
+ "daysRemaining",
+ "validTo",
+ "issuer",
+ "state"
+ ],
+ "type": "object"
+}check_site1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "checkedAt": {
+ "description": "ISO 8601",
+ "type": "string"
+ },
+ "checkedFrom": {
+ "description": "sg = Singapore, us = Boston",
+ "enum": [
+ "sg",
+ "us"
+ ],
+ "type": "string"
+ },
+ "curated": {
+ "description": "true if the site is one of the monitored sites",
+ "type": "boolean"
+ },
+ "domain": {
+ "type": "string"
+ },
+ "finalUrl": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ip": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "latencyMs": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "reason": {
+ "type": "string"
+ },
+ "redirected": {
+ "type": "boolean"
+ },
+ "regions": {
+ "description": "Fresh result from each region that has one",
+ "properties": {
+ "sg": {
+ "properties": {
+ "checkedAt": {
+ "description": "ISO 8601",
+ "type": "string"
+ },
+ "domain": {
+ "type": "string"
+ },
+ "finalUrl": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ip": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "latencyMs": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "reason": {
+ "type": "string"
+ },
+ "redirected": {
+ "type": "boolean"
+ },
+ "scheme": {
+ "enum": [
+ "https",
+ "http",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "server": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "state": {
+ "enum": [
+ "up",
+ "slow",
+ "error",
+ "maintenance",
+ "down"
+ ],
+ "type": "string"
+ },
+ "status": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "tls": {
+ "properties": {
+ "daysRemaining": {
+ "type": "number"
+ },
+ "issuer": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "validTo": {
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "up": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "domain",
+ "up",
+ "state",
+ "status",
+ "latencyMs",
+ "checkedAt",
+ "reason"
+ ],
+ "type": "object"
+ },
+ "us": {
+ "properties": {
+ "checkedAt": {
+ "description": "ISO 8601",
+ "type": "string"
+ },
+ "domain": {
+ "type": "string"
+ },
+ "finalUrl": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ip": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "latencyMs": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "reason": {
+ "type": "string"
+ },
+ "redirected": {
+ "type": "boolean"
+ },
+ "scheme": {
+ "enum": [
+ "https",
+ "http",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "server": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "state": {
+ "enum": [
+ "up",
+ "slow",
+ "error",
+ "maintenance",
+ "down"
+ ],
+ "type": "string"
+ },
+ "status": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "tls": {
+ "properties": {
+ "daysRemaining": {
+ "type": "number"
+ },
+ "issuer": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "validTo": {
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "up": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "domain",
+ "up",
+ "state",
+ "status",
+ "latencyMs",
+ "checkedAt",
+ "reason"
+ ],
+ "type": "object"
+ }
+ },
+ "type": "object"
+ },
+ "reportsLastHour": {
+ "type": "integer"
+ },
+ "scheme": {
+ "enum": [
+ "https",
+ "http",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "server": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "state": {
+ "enum": [
+ "up",
+ "slow",
+ "error",
+ "maintenance",
+ "down"
+ ],
+ "type": "string"
+ },
+ "status": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "statusUrl": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "tls": {
+ "properties": {
+ "daysRemaining": {
+ "type": "number"
+ },
+ "issuer": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "validTo": {
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "up": {
+ "type": "boolean"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "domain",
+ "up",
+ "state",
+ "status",
+ "latencyMs",
+ "checkedAt",
+ "reason",
+ "checkedFrom",
+ "regions",
+ "reportsLastHour",
+ "curated",
+ "statusUrl",
+ "url"
+ ],
+ "type": "object"
+}list_monitored_sites1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "description": "Without arguments: total + categories. With category or query: total, matched, returned, category, query, sites.",
+ "properties": {
+ "categories": {
+ "items": {
+ "properties": {
+ "count": {
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "name",
+ "count",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "category": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "matched": {
+ "type": "integer"
+ },
+ "query": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "returned": {
+ "type": "integer"
+ },
+ "sites": {
+ "items": {
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "checkedFrom": {
+ "description": "sg = Singapore, us = Boston",
+ "enum": [
+ "sg",
+ "us"
+ ],
+ "type": "string"
+ },
+ "domain": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "statusUrl": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "domain",
+ "name",
+ "category",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total"
+ ],
+ "type": "object"
+}list_outages1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "asOf": {
+ "type": "string"
+ },
+ "category": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "down": {
+ "items": {
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "checkedFrom": {
+ "description": "sg = Singapore, us = Boston",
+ "enum": [
+ "sg",
+ "us"
+ ],
+ "type": "string"
+ },
+ "domain": {
+ "type": "string"
+ },
+ "downForMinutes": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "since": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "statusUrl": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "domain",
+ "name",
+ "category",
+ "url",
+ "since",
+ "downForMinutes"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "monitored": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "asOf",
+ "monitored",
+ "category",
+ "down"
+ ],
+ "type": "object"
+}site_history1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "checkedFrom": {
+ "description": "sg = Singapore, us = Boston",
+ "enum": [
+ "sg",
+ "us"
+ ],
+ "type": "string"
+ },
+ "current": {
+ "properties": {
+ "checkedAt": {
+ "description": "ISO 8601",
+ "type": "string"
+ },
+ "domain": {
+ "type": "string"
+ },
+ "finalUrl": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ip": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "latencyMs": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "reason": {
+ "type": "string"
+ },
+ "redirected": {
+ "type": "boolean"
+ },
+ "scheme": {
+ "enum": [
+ "https",
+ "http",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "server": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "state": {
+ "enum": [
+ "up",
+ "slow",
+ "error",
+ "maintenance",
+ "down"
+ ],
+ "type": "string"
+ },
+ "status": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "tls": {
+ "properties": {
+ "daysRemaining": {
+ "type": "number"
+ },
+ "issuer": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "validTo": {
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "up": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "domain",
+ "up",
+ "state",
+ "status",
+ "latencyMs",
+ "checkedAt",
+ "reason"
+ ],
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "days": {
+ "type": "integer"
+ },
+ "domain": {
+ "type": "string"
+ },
+ "incidents": {
+ "items": {
+ "properties": {
+ "durationMinutes": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "end": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ongoing": {
+ "type": "boolean"
+ },
+ "start": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "start",
+ "end",
+ "durationMinutes",
+ "ongoing"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "lastDown": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "reports24h": {
+ "type": "integer"
+ },
+ "reportsLastHour": {
+ "type": "integer"
+ },
+ "statusUrl": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "uptime24h": {
+ "description": "Percent, null if no data yet",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "uptimeWindow": {
+ "description": "Percent over `days`, null if no data yet",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "domain",
+ "name",
+ "category",
+ "checkedFrom",
+ "days",
+ "uptime24h",
+ "uptimeWindow",
+ "current",
+ "incidents",
+ "lastDown",
+ "reportsLastHour",
+ "reports24h",
+ "statusUrl",
+ "url"
+ ],
+ "type": "object"
+}check_certificatecheck_sitelist_monitored_siteslist_outagessite_historyWebsite uptime monitoring: run checks from 300+ locations, manage monitors, alerts and incidents
Uptime monitoring: create and manage HTTP, API, SSL, ping, port and domain checks
Monitor website uptime, SSL certificates, DNS, domain expiry and page changes, and manage alerts.
DNS lookups, health reports, SSL certs, security scans, GEO scoring, uptime checks
Add one secure layer between your agents and this server.
