Skip to main content
Learn more about URL Monitors in the URL monitor overview.
Use URL Monitors to track basic availability and HTTP status codes of your services and websites. The examples below show how to configure monitoring for different types of HTTP endpoints.
Before creating URL Monitors, ensure you have:
  • An initialized Checkly CLI project
  • URLs or HTTP endpoints you want to monitor
  • Understanding of HTTP status codes and response behavior
  • Network access to the URLs you want to monitor
For additional setup information, see CLI overview.

Configuration

The URL Monitoring configuration consists of specific URL monitoring options and inherited general monitoring options.

UrlMonitor Options

object
required
HTTP request configuration that defines the URL to monitor and how to handle the request.Usage:
Parameters:Examples:
Use cases: Website availability, API health checks, service uptime monitoring.
number
default:"3000"
Response time threshold in milliseconds for marking the monitor as degraded (warning state).Usage:
Use cases: Early performance warnings, gradual degradation detection.
number
default:"5000"
Maximum response time in milliseconds before the monitor is marked as failed.Usage:
Examples:
Use cases: Performance monitoring, SLA compliance, user experience optimization.

UrlMonitor Assertions

To define assertions for the request of an UrlMonitor you should use the UrlAssertionBuilder. The following source is available for URL monitor assertions:
  • statusCode(): Assert the HTTP status code for the HTTP response, e.g. 200 or 201
Here is an example:
  • Assert the status code of a HTTP request
Learn more in our docs on Assertions.

General Monitor Options

string
required
Friendly name for your URL monitor that will be displayed in the Checkly dashboard and used in notifications.Usage:
Frequency
How often the URL monitor should run. Use the Frequency enum to set the check interval.Usage:
Examples:
Available frequencies: EVERY_10S, EVERY_20S, EVERY_30S, EVERY_1M, EVERY_2M, EVERY_5M, EVERY_10M, EVERY_15M, EVERY_30M, EVERY_1H, EVERY_2H, EVERY_3H, EVERY_6H, EVERY_12H, EVERY_24H
string[]
default:"[]"
Array of public location codes where the URL monitor should run from. Multiple locations provide geographic coverage.Usage:
Examples:
Use cases: Global performance monitoring, regional compliance, CDN performance validation.
boolean
default:"true"
Whether the URL monitor is enabled and will run according to its schedule.Usage:
Examples:
CheckIntent
Describe what your check is intended to verify and the behavior that should be preserved. Checkly uses intent for root cause analysis across all check types. It is separate from description and does not replace executable assertions.
Intent is used for automatic repair only for Browser and Multistep Checks.
The object accepts the following fields:Each constraint has a required type and statement:
  • REQUIRED_OUTCOME: an outcome the check must verify.
  • MUST_PRESERVE: behavior or an assertion that should be preserved when repairing the check.
Each statement must contain 1–1,000 characters after trimming. You can specify at most 20 constraints of each type. The CLI trims leading and trailing whitespace from the goal and statements and rejects unknown fields.For example, configure intent on a Browser Check:

Examples

URL monitors only support status code assertions. For more complex assertions on response bodies, headers, or response time, use API checks instead.
When skipSSL is set to true, SSL certificate validation is bypassed. Use this only for testing environments or when monitoring services with self-signed certificates.