URL Monitor Configuration

​

Basic Setup

Monitor public URLs by specifying the endpoint you want to track.

• Request method: Always GET.
• URL: The HTTP(S) URL to monitor (e.g. https://api.example.com).
• IP family: Defaults to IPv4.
• Follow redirects: Automatically follow 30x redirects.
• Skip SSL: Skip SSL certificate validation.
• This request should fail: Treat HTTP error codes (4xx and 5xx) as passed. Please note that successful responses still pass. Only failed assertions will cause the check to fail.

​

Assertions

Use assertions to validate the status code of your URL request. When one or more assertions fail, an alert is triggered: For more details, see our documentation on Assertions.

​

Response Time Limits

Set performance thresholds to ensure your application meets speed requirements: Degraded After: Time threshold (in milliseconds) after which the check is marked as degraded but not failed. Use for performance warnings without triggering failure alerts. Failed After: Time threshold after which the check fails completely. Use for hard performance limits where slow responses should trigger alerts.

​

Frequency

Determine how often your monitors run. Choose a frequency that balances monitoring coverage with resource usage. Higher frequencies provide faster detection but may not be necessary for all services.

​

Scheduling Strategy

Choose when and how your checks run across multiple locations: Round Robin (Default): Checks run on one of the selected locations each time it is scheduled. Parallel: Checks run from all selected locations simultaneously. Higher consumption but provides immediate global visibility for critical services.

​

Locations

Select from Checkly’s global monitoring locations to test your URLs from different regions: We recommend to chose at least 2-3 locations that best represent your user base for optimal monitoring coverage. See Locations for the complete list of available regions and guidance on location selection.

​

Retries

Select the retry strategy to determine how failed checks are retried:

​

Alert Settings

Configure notifications for your team:

​

Notification Scope

Choose how alerts are configured for this monitor:

​

Escalation Rules

Control when alerts are triggered: Primary Trigger (Choose one):

• When a check has failed X time(s): Sends alert after specified consecutive failures
• When a check is failing for more than Y minutes: Sends alert if failure duration exceeds threshold

Additional Condition (Optional):

• When a check is failing in Z% of locations: Only applies to checks running in parallel across multiple locations

​

Reminders

Configure follow-up alerts after initial failure notification:

​

Alert Channels

Define where notifications are sent when checks fail or recover. Additional channels can be configured in global notification settings. Alert Types (per channel):

• ✅ Success/Recovery: Check has recovered from failure
• ⚠ Degraded: Check is degraded but not failed
• ❌ Failure: Check has failed