Skip to main content
Learn more about DNS Monitors in the DNS monitor overview.
Use DNS Monitors to verify that DNS records resolve correctly and to track lookup performance over time.
Before creating DNS Monitors, ensure you have:
  • An initialized Checkly CLI project
  • A domain or hostname you want to monitor
  • Basic understanding of DNS record types (A, AAAA, CNAME, MX, NS, TXT, SOA, HTTPS)
For additional setup information, see CLI overview.

Configuration

A DNS Monitor has its own DNS-specific settings, plus the standard monitor options shared across all check types.

DnsMonitor Options

object
required
DNS request configuration that defines the DNS query to perform and how to validate the response.Usage:
Parameters:
number
default:"500"
Response time threshold in milliseconds for marking the DNS Monitor as degraded (warning state).Usage:
number
default:"1000"
Maximum response time in milliseconds before the DNS Monitor is marked as failed.Usage:

DnsMonitor Assertions

To define assertions for the request of an DnsMonitor you should use the DnsAssertionBuilder. The following sources are available for DNS monitor assertions:
  • responseTime(): Assert the total response time of the DNS request in milliseconds. Use this to set thresholds for failed lookups
  • responseCode(): By default, DNS monitors pass when the return code is NOERROR and fail on error codes (FORMERR, SERVFAIL, NXDOMAIN, etc.). You can override this behavior by defining a custom return code assertion
  • textAnswer(): The raw DNS response as plain text. Use this to check for specific strings in the response
  • jsonAnswer(property?): The DNS response in JSON format. This allows you to target specific fields using JSON path assertions. The response structure varies by record type. Learn more about using JSON path.
Here are some examples:
  • Assert the total response time of the DNS request
  • Assert the DNS response code
  • Assert against specific JSON fields in the response.
Learn more in our docs on Assertions.

General Monitor Options

string
required
Friendly name for your DNS Monitor that will be displayed in the Checkly dashboard and used in notifications.Usage:
Frequency
How often the DNS Monitor should run. Use the Frequency enum to set the check interval.Usage:
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 DNS Monitor should run from. Multiple locations provide geographic coverage and help detect regional DNS issues.Usage:
boolean
default:"true"
Whether the DNS Monitor is enabled and will run according to its schedule.Usage:
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: