Monitors

What are Monitors?

Monitors are the core component of UptimeEye that allow you to check the health and performance of your websites, APIs, and services. Each monitor consists of one or more steps that define what to check and how to validate the results.

Monitor Types

UptimeEye supports the following monitor types:

• HTTP - Monitor HTTP/HTTPS endpoints with customizable requests and response validation
• DNS - Check DNS records and validate their values
• ICMP - Ping servers to check their availability and response time
• TCP - Check that a port (host:port, e.g. a database, SSH or SMTP server) accepts connections, and how fast

Creating a Monitor

Monitors are created and edited in the monitor builder. To create a new monitor:

1. Open Monitors in the sidebar and click "New monitor"
2. Enter the URL or host to check. The Check chip below it sets the type (HTTP(s), DNS, Ping or TCP port) and, for HTTP, the method. The name is optional: left empty, the monitor is named after its domain
3. Click "Test". The live response shows the status code, response time, SSL certificate, headers and body. Click a value in it to add it as a check
4. Under Counts as up when, add or edit the checks. Quick checks add common ones (Status 2xx, Body contains…, Response time < 10 s, SSL > 14 days, DNS record contains…). Without checks, the monitor counts as up as soon as any response arrives
5. Set the schedule and alerting with the chips below the URL: every (check interval), from (regions, and how many must fail before an alert), Alert to (notification channel, and how many consecutive failures before an alert) and Tags
6. Click "Start monitoring". The first execution starts within about 30 seconds

For several requests in a row, or to pass values from one response to the next request, click Switch to multi-step mode. There every step is a card with its own URL, headers, body, checks and variables (see Monitor Steps). "Add step" adds a step, steps are reordered by dragging, and "Test all steps" runs them in order with the extracted variables. The Monitor settings card below the steps holds the notification channel, check interval, regions and tags; Advanced (timeout, thresholds) in it holds the timeout, both thresholds and Follow redirects. Click "Create monitor" to save.

To change a monitor later, open its Settings tab: it is the same builder, saved with "Save monitor".

Monitor Options

When creating or editing a monitor, you can configure the following options:

• Check Interval - The time between two executions of the monitor (30s, 1m, 2m, 3m, 5m, 10m, 30m, 6h, 12h, or 24h). Minimum interval depends on your plan: 5 minutes on Free, 30 seconds on Pro and Agency.
• Timeout - How long to wait for a response before considering the check failed, in seconds. The app offers 5 to 60 seconds (default 15); the API and Terraform accept any value from 5 seconds.
• Follow Redirects - Whether to follow HTTP redirects automatically (on by default)
• Failure Threshold - Number of consecutive failures before a monitor is marked as down (default 2). The app offers 1 to 5, the API and Terraform accept 1 to 10.
• Location Threshold - Number of locations that must report failure before triggering an alert (default 1). The app offers 1 up to the number of selected locations, the API and Terraform accept 1 to 10.
• Locations - Which locations to run checks from (see Locations). How many a monitor can use is a plan limit: 1 on Free, 3 on Pro, 6 on Agency. The probe IP addresses for firewall allowlists are listed on the Trust & Security page.

The number of steps per monitor is a plan limit: 5 on Free, 10 on Pro, 20 on Agency. In multi-step mode, "Paste cURL…" in an HTTP step imports the method, URL, headers and body of a cURL command.

Locations

Monitors check from these locations. The app shows the name; the API, Terraform and MCP use the id, as GET /v1/locations lists it. New monitors in the app start with Europe (Germany).

What are Monitor Steps?

Monitor steps define the individual checks that a monitor performs. Each step can have its own configuration, assertions, and variable extractions. Steps are executed in sequence, and variables extracted in one step can be used in subsequent steps.

Step Configuration

Each step is configured in the monitor builder; in multi-step mode every step is a card with these parts:

• Type and target - HTTP(s), DNS, Ping (ICMP) or TCP port, and the URL or host to check. Click the step's name to rename it
• Headers and Body - The request details of an HTTP step: method, headers, and a body for POST and PUT
• Checks - The assertions that validate the response. Test the step and click a value in the live response, or use the quick checks
• Variables for later steps - Values extracted from the response for use in the steps after it

Assertions

Assertions allow you to validate the response from your monitored endpoint; the monitor builder calls them checks. Different assertion types are available depending on the monitor type:

HTTP Assertions

• Status Code - Check if the status code is or is not a specific value
• Response Time - Check if the response time is less than a specific value
• Body - Check if the response body contains, does not contain, is, or is not a specific value
• Body JSON Path - Check if a specific JSON path in the response body meets certain criteria
• Header - Check if a specific header contains, does not contain, is, or is not a specific value
• SSL Certificate - Validate SSL certificate properties:
  • Issuer - Certificate issuer name
  • Subject - Certificate subject name
  • Expires In - Days until certificate expiration (e.g., alert if less than 30 days)
  • DNS Names - Subject Alternative Names (SANs) on the certificate

DNS Assertions

• DNS Record - Check if a specific DNS record (A, AAAA, MX, etc.) contains, does not contain, is, or is not a specific value

ICMP Assertions

• Response Time - Check if the ping response time is less than a specific value

TCP Assertions

A TCP step fails when the port refuses or does not accept the connection within the timeout. Private, loopback and link-local addresses cannot be checked.

• Response Time - Check if the connect time is less than a specific value

Global Variables

UptimeEye supports global variables to help you dynamically generate values inside your requests. These can be used in URLs, headers, bodies, or assertions.

Syntax follows the pattern: {{ variable(args) }}

Available global variables:

These dynamic variables are especially useful for load testing, simulating unique users or sessions, and avoiding caching effects.

Example usage in a request body:

{
  "email": "user+{{ numeric 5 }}@example.com",
  "password": "{{ alphanumeric 12 }}"
}

Variable Extraction

Variables allow you to extract values from the response of one step and use them in subsequent steps. This is useful for scenarios like extracting an authentication token from a login response and using it in subsequent API calls. In the monitor builder, test a step, click a body or header value in the live response and choose "Extract as variable"; the step lists it under Variables for later steps.

You can extract variables from:

• Response Body - Extract the entire response body or a specific JSON path
• Headers - Extract the value of a specific header
• Status Code - Extract the status code as a variable

To use a variable in a subsequent step, use the syntax {{variableName}} in the URL, headers, or body of the step.

What are Secure Variables?

Secure Variables allow you to store sensitive information, such as API keys, passwords, or tokens, securely in UptimeEye. These variables can then be used in your monitors without exposing the actual values in the UI or logs.

Creating Secure Variables

To create a new secure variable:

1. Open Variables in the sidebar
2. Click "New variable"
3. Enter a key (name) for your variable
4. Enter the value you want to store
5. Check the "Secure" checkbox to mark the variable as secure
6. Click "Create variable" to save your configuration

Using Secure Variables in Monitors

To use a secure variable in a monitor step, use the syntax {{variableName}} in the URL, headers, or body of the step. UptimeEye will automatically replace this placeholder with the actual value when executing the monitor.

This allows you to use sensitive information in your monitors without exposing it in the UI or logs. For example, you can use secure variables for:

• API keys in request headers
• Passwords in authentication requests
• Tokens in request parameters
• Sensitive data in request bodies

Related