Overview
Uptrends provides several monitor types, such as uptime, browser (full-page check), and multi-step API monitors, to track the availability and performance of your websites. Every time a monitor runs, it generates a monitor check.
A check contains detailed monitor measurements, including error descriptions, resolve time, and other metrics that reflect the status and behavior of your website or service.
Prerequisites
Before using the MonitorCheck API, make sure you have:
- Uptrends API credentials
- Basic understanding of monitor types and their configuration
- Basic understanding of monitor results
MonitorCheck API endpoints
When you request a list of monitor checks, each entry includes basic metrics for that check. Depending on the monitor type, more detailed data may be available through additional GET requests. When related resources exist for a check, they appear in the Relationships array: each item includes Links.Self, which is the path to call to retrieve that detail (for example, /MonitorCheck/{monitorCheckId}/MultiStepAPI).
For schemas and interactive testing, refer to the Uptrends MonitorCheck API documentation.
The MonitorCheck API provides the following GET endpoints.
/MonitorCheck— returns monitor check data for the account./MonitorCheck/{monitorCheckId}— returns a single monitor check./MonitorCheck/Monitor/{monitorGuid}— returns monitor check data for the specified monitor./MonitorCheck/MonitorGroup/{monitorGroupGuid}— returns monitor check data for the specified monitor group.
Endpoints for monitor type
These GET endpoints return details for a specific monitor check, tailored to the monitor type:
/MonitorCheck/{monitorCheckId}/Http— returns HTTP or HTTPS check details, including URL, response body, and headers./MonitorCheck/{monitorCheckId}/MultiStepAPI— returns multi-step API check details, including URL, status code, assertions, request headers, and response body./MonitorCheck/{monitorCheckId}/Transaction— returns transaction check details, including step information. For waterfall, filmstrip, screenshots, page source, and console log, use the dedicated endpoints in this article.
Endpoints for monitor configuration
These GET endpoints return waterfall, page content, and media for browser and transaction monitors where applicable:
/MonitorCheck/{monitorCheckId}/Waterfall— returns waterfall data for browser (full-page) or transaction monitors. The response includes Core Web Vitals and related metrics (Cumulative Layout Shift, First Contentful Paint, Largest Contentful Paint, and Time to First Byte)./MonitorCheck/{monitorCheckId}/PageSource— returns page source (HTML) for browser and transaction monitors./MonitorCheck/{monitorCheckId}/ConsoleLog— returns the browser console log for browser and transaction monitors./MonitorCheck/{monitorCheckId}/Screenshot/{screenshotId}— returns the specific screenshot details for the monitor check./MonitorCheck/{monitorCheckId}/Filmstrip— returns filmstrip data for browser and transaction monitors.
Endpoint for concurrent monitors
/MonitorCheck/{monitorCheckId}/Concurrent— returns all partial checks for a concurrent monitor check.
MonitorCheck API response
{
"Data": [
{
"Type": "MonitorCheck",
"Id": 212790389158,
"Attributes": {
"MonitorGuid": "df2bc2d9-755c-45fa-880a-ee82e1eb7793",
"Timestamp": "2026-04-14T16:52:55",
"ErrorCode": 0,
"TotalTime": 101,
"ResolveTime": 0,
"ConnectionTime": 0,
"DownloadTime": 101,
"ResolvedIpAddress": "104.21.61.23",
"ErrorLevel": "NoError",
"ErrorDescription": "OK",
"ErrorMessage": "",
"StagingMode": false,
"ServerId": 1991,
"IsPartialCheck": false,
"IsConcurrentCheck": false
},
"Relationships": [
{
"Id": 1991,
"Type": "CheckpointServer",
"Links": {
"Self": "/Checkpoint/Server/1991"
}
},
{
"Id": 212790389158,
"Type": "MultiStepAPICheck",
"Links": {
"Self": "/MonitorCheck/212790389158/MultiStepAPI"
}
}
]
}
],
"Links": {
"Next": "/v4/MonitorCheck?Sorting=Descending&Take=100&PresetPeriod=Last24Hours&cursor=r%2b3aDoQMmmzQyn0gZpXRtuTPR9I1p481%2frdq5beRRu9fkwFNbL7g9EqtBTezyrx3cBfwgrEE8eSDh3WpqRTQEg%3d%3d",
"Self": "/v4/MonitorCheck?Sorting=Descending&Take=100&PresetPeriod=Last24Hours&cursor=Waul03CKWbe9wj%2fZ%2fs%2fYHhAtN5gst9iN3oZ6yP4JvGxZrwiTWxY13mhIivXfKkwKNgN0sY66uVfczabtWzrQMQ%3d%3d"
},
"Cursors": {
"Next": "r+3aDoQMmmzQyn0gZpXRtuTPR9I1p481/rdq5beRRu9fkwFNbL7g9EqtBTezyrx3cBfwgrEE8eSDh3WpqRTQEg==",
"Self": "Waul03CKWbe9wj/Z/s/YHhAtN5gst9iN3oZ6yP4JvGxZrwiTWxY13mhIivXfKkwKNgN0sY66uVfczabtWzrQMQ=="
}
}
MonitorCheck API parameters
The following parameters are used within the MonitorCheck API:
| Field name | Description |
|---|---|
monitorCheckId |
The unique identifier of the monitor check. |
monitorGuid |
The unique identifier of the monitor. |
monitorGroupGuid |
The unique identifier of the monitor group. |
ErrorLevel |
The severity level of the error returned. Possible values are:
|
ShowPartialMeasurements |
Applicable to concurrent monitors. Refers to the partial checks, where a check is considered partially successful instead of fully passed or fully failed.
|
Cursor |
A string (query) value used for traversing the dataset. For more details, see the Cursor knowledge base article.
|
Sorting |
Arranges data in ascending or descending order. The default value is Descending. |
Take |
Maximum number of records to return. Default and maximum: 100. |
Start |
A custom date parameter in YYYY-MM-DDTHH:MM:SS format (for example, 2025-01-20T08:00:00) used with the End parameter to specify the start date for the API response. This parameter cannot be used along with the PresetPeriod. |
End |
A custom date parameter in YYYY-MM-DDTHH:MM:SS format (for example, 2025-01-20T16:00:00) used with the Start parameter to specify the end date for the returned statistics records. This parameter cannot be used along with the PresetPeriod. |
PresetPeriod |
Returns a list of time durations to filter information within a specific period. This cannot be used along with the Start and End parameters. The default value is
Last24Hours. For more detailed explanation, refer to PresetPeriod. |
step |
Only required for transaction monitor checks. Refers to the specific step within the transaction monitor. For example, 1, 2, or 3. |
MonitorCheck API fields
Generic data structure
The root object can include:
Data— an array of monitor checks, or a single monitor check object (for example, forGET /MonitorCheck/{monitorCheckId}).Links— URLs for the current page and the next page of results. For more details, see the Links knowledge base article.Relationships— related resources (checkpoint server, detail types, and so on). Each item includesId,Type, andLinks.Self. See Relationships.Cursors— cursor values for traversing a data set. For more details, see the Cursor knowledge base article.Meta— metadata for the monitor check.
Data and attribute members
| Field | Description |
|---|---|
MonitorGuid |
Unique identifier of the monitor that produced this check. |
Timestamp |
Date and time of the check (for example, 2026-01-20T08:00:00). |
ErrorCode |
Numeric Uptrends error code when the result is an error; 0 when the result is OK. |
TotalTime |
Milliseconds to complete the monitor check. |
ResolveTime |
Milliseconds to perform the DNS query for this check, when applicable. |
ConnectionTime |
Milliseconds to establish a connection. |
DownloadTime |
Milliseconds to download the response data. |
TotalBytes |
Bytes downloaded for this check (when present). |
ResolvedIpAddress |
IP address resolved for the target domain for this check (when present). |
ErrorLevel |
NoError, Unconfirmed, or Confirmed. |
ErrorDescription |
Short description of the error, or OK if none. |
ErrorMessage |
Additional error information, if any. |
StagingMode |
Whether the check ran against a monitor in staging mode. |
ServerId |
Identifier of the Uptrends checkpoint server that ran the check. |
HttpStatusCode |
HTTP status code returned by the target, when applicable. |
IsPartialCheck |
Whether this row is a partial concurrent measurement. See Errors and alerting for concurrent monitors. |
IsConcurrentCheck |
Whether this record is a concurrent check. |
The monitored URL and other type-specific fields are returned from the detail endpoints (for example GET /MonitorCheck/{monitorCheckId}/Http or GET .../MultiStepAPI), not in the base Attributes object for every monitor type.
Troubleshooting
This section covers common HTTP errors and troubleshooting steps for the MonitorCheck API.
Common errors
Common HTTP status codes and their descriptions:
| Status Code | Description |
|---|---|
| 200 | OK — request successful. |
| 204 | No content — the request completed successfully and no response was returned. This is for DELETE, PUT, PATCH, and POST requests. |
| 400 | Bad request — invalid request parameters or missing required fields. |
| 401 | Unauthorized — invalid or missing authentication credentials. |
| 403 | Forbidden — one or more validation errors occurred. This may be related to account permissions. |
| 404 | Not Found — the specified monitor check ID, monitor GUID, monitor group GUID, or screenshot ID does not exist or is not accessible. |
| 500 | Internal Server Error — a server-side error occurred. |
General troubleshooting guide
Ensure that you:
- Always validate your request data before sending API calls.
- Use appropriate HTTP methods for each operation.
For further assistance, please reach out to our Support team.
Related articles
For more details, refer to the following articles:
- Uptrends MonitorCheck API documentation — interactive API documentation with detailed endpoint specifications.
- API changelog — for the latest API updates and deprecation notices.