The endpoints that are part of the Monitor API help you to manage your monitor settings in Uptrends. Monitors are the things you define in Uptrends to describe what needs to be monitored. Typically, a monitor checks a single web page, or a sequence of API calls, or an end-user click path in a web site.
The Monitor API has several endpoints that let you create, modify, clone or delete monitor definitions. Those endpoints are described below.
Getting started
- To access the API, you need to have an API account.
- You can discover/try out the Monitor API endpoints in our Swagger environment.
- Each API method is described below.
- For most of these methods, you’ll work with a monitor object that contains the settings for a monitor. You can review the appropriate settings and fields in the monitor object article.
GET /Monitor
Returns the list of monitors currently present in the account.
GET /Monitor
Response body:
[
{
"MonitorGuid": "1d2f5fac-730c-45b0-a077-4ab82aaee14e",
"Name": "Galactic Resorts homepage",
"IsActive": true,
"GenerateAlert": true,
"MonitorType": "Https",
"CheckInterval": 5
// More fields here
},
// More monitors here
]
GET /Monitor/{monitorGuid}
Returns a single monitor, identified by the specified monitorGuid.
GET /Monitor/1d2f5fac-730c-45b0-a077-4ab82aaee14e
Response body:
{
"MonitorGuid": "1d2f5fac-730c-45b0-a077-4ab82aaee14e",
"Name": "Galactic Resorts homepage",
"IsActive": true,
"GenerateAlert": true,
"MonitorType": "Https",
"CheckInterval": 5
// More fields here
}
PATCH /Monitor/{monitorGuid}
Updates the definition of the specified monitor. The request body for this request is expected to contain a partial list of fields you want to update. You’ll typically use this request to update just one or a few fields. In the request body, only list the fields you want to update. Including the MonitorGuid field is optional. If you do specify it, it must match the MonitorGuid you specify in the URL.
The following PATCH request is used to deactivate a monitor, by specifying a new value for its IsActive field.
PATCH /Monitor/1d2f5fac-730c-45b0-a077-4ab82aaee14e
Request body:
{
"MonitorGuid": "1d2f5fac-730c-45b0-a077-4ab82aaee14e",
"IsActive": false
}
PUT /Monitor/{monitorGuid}
Updates the definition of the specified monitor. The request body for this request is expected to contain the full list of all monitor fields. You’ll typically perform a GET request first to obtain the existing definition of the monitor you want to update, make the necessary changes in that content, and send it back using this PUT request.
The following PUT request is used to change the monitor’s Name and IsActive fields, but the other fields must be listed as well, since we’re doing a PUT request, not a partial PATCH request.
PUT /Monitor/1d2f5fac-730c-45b0-a077-4ab82aaee14e
Request body:
{
"MonitorGuid": "1d2f5fac-730c-45b0-a077-4ab82aaee14e",
"Name": "Galactic Resorts product page",
"IsActive": false,
"GenerateAlert": true,
"MonitorType": "Https",
"CheckInterval": 5
// Remaining fields here
}
POST /Monitor
Creates a new monitor. The request body for this request is expected to contain the full list of all monitor fields that are appropriate for the type of monitor you’re creating.
If you’re creating an API request like this for the first time, it may be useful to create a monitor in the Uptrends application first, retrieve the definition for that monitor using a GET request, and inspect the structure of that monitor definition as an example.
The following POST request is used to create a basic HTTPS monitor that runs on checkpoints in Europe:
POST /Monitor
Request body:
{
"Name": "My new monitor",
"IsActive": true,
"GenerateAlert": true,
"IsLocked": false,
"CheckInterval": 5,
"MonitorMode": "Production",
"CustomFields": [],
"SelectedCheckpoints": {
"Regions": [
1004
]
},
"UsePrimaryCheckpointsOnly": true,
"MonitorType": "Https",
"Notes": "Monitors uptime for the homepage",
"AlertOnLoadTimeLimit1": true,
"LoadTimeLimit1": 2500,
"AlertOnLoadTimeLimit2": true,
"LoadTimeLimit2": 5000,
"RequestHeaders": [],
"UserAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.79 Safari/537.36",
"Username": "",
"AuthenticationType": "None",
"CheckCertificateErrors": true,
"IpVersion": "IpV4",
"AlertOnMinimumBytes": false,
"MinimumBytes": 0,
"HttpMethod": "Get",
"CheckHttpStatusCode": false,
"ExpectedHttpStatusCode": 401,
"TlsVersion": "Tls12_Tls11_Tls10",
"RequestBody": "",
"Url": "https://galacticresorts.com"
}
DELETE /Monitor/{monitorGuid}
Deletes the specified monitor.
DELETE /Monitor/1d2f5fac-730c-45b0-a077-4ab82aaee14e
POST /Monitor/{monitorGuid}/Clone
Creates a clone (duplicate) of the specified monitor. The copied monitor will initially be inactive, so you can make changes before activating it.
Optional parameters
- includeMaintenancePeriods: true or false (default: true). Indicates whether or not to also copy the existing maintenance periods from the source monitor into the clone.
- includeMonitorGroups: true or false (default: true). Indicates whether or not to also copy the monitor group memberships into the clone. If true is specified, the new copy will be part of the same monitor groups as the source monitor. If false is specified, it will only be part of the All monitors group.
The following POST request creates a copy of an existing monitor, and specifies that the maintenance periods must not be copied from the source, but that the new monitor should be part of the same monitor groups.
POST /Monitor/1d2f5fac-730c-45b0-a077-4ab82aaee14e/Clone?includeMaintenancePeriods=false&includeMonitorGroups=true
Other APIs related to monitors
- If you’re looking for monitor data (i.e. monitor check data produced by a monitor), please look at the MonitorCheck API.
- Monitors can be organized into groups. Look at the MonitorGroup API.
- Monitors have automated on/off schedules called Maintenance Periods. Look at the Maintenance Period API.