defineConfig
to define core settings for your entire Checkly CLI project. This is typically configured in your checkly.config.ts
file and provides global defaults for all CLI-powered checks and monitors.
Configuration
Parameter | Type | Required | Default | Description |
---|---|---|---|---|
projectName | string | ✅ | - | Friendly name for your project |
logicalId | string | ✅ | - | Unique identifier for this project (should be stable) |
repoUrl | string | ❌ | - | Optional URL to a Git repository |
checks | object | ❌ | - | Top-level defaults for all checks in this project |
cli | object | ❌ | - | Defaults for CLI commands |
Core Project Options
Friendly name for your project that will be displayed in the Checkly dashboard and used for identification.Usage:Use cases: Dashboard identification, project organization, team coordination.
Unique identifier for this project that should remain stable across deployments. Changing this will cause Checkly to treat it as a new project.Usage:Use cases: Project identification, deployment tracking, configuration persistence.
The
logicalId
should remain stable across deployments. Changing it will cause Checkly to treat it as a new project, losing historical data and configurations.Optional URL to a Git repository for documentation and team collaboration purposes in Checkly UI.Usage:Use cases: Documentation linking, team collaboration, source code reference.
Defaults for CLI commands like Properties:
Use cases: Local testing defaults, CI/CD configuration, development workflow.
checkly test
and checkly trigger
.Usage:Parameter | Type | Required | Default | Description |
---|---|---|---|---|
runLocation | string | ❌ | - | Default location for checkly test and checkly trigger |
privateRunLocation | string | ❌ | - | Default private location for CLI commands |
retries | number | ❌ | 0 | Default retry count for failing checks (max 3) |
Check and Monitor Configuration
Thechecks
property allows you to set global defaults for all checks and monitors in your project. Individual checks and groups can override these settings.
Top-level defaults for all checks in this project. Individual checks and groups can override these settings.Usage:Properties:
Parameter | Type | Required | Default | Description |
---|---|---|---|---|
activated | boolean | ❌ | true | Whether checks are enabled by default |
alertChannels | Array<AlertChannel | AlertChannelRef> | ❌ | [] | Default alert channels for all checks |
checkMatch | string | ❌ | - | Glob pattern to find check construct files |
environmentVariables | EnvironmentVariable[] | ❌ | [] | Default environment variables for all checks |
frequency | Frequency | ❌ | - | Default frequency for all checks |
ignoreDirectoriesMatch | string[] | - | - | Glob patterns for directories to ignore |
locations | string[] | ❌ | [] | Default public locations for all checks |
muted | boolean | ❌ | false | Whether alert notifications are muted by default |
playwrightConfig | object | ❌ | - | Subset of Playwright configuration options |
playwrightConfigPath | string | ❌ | - | Path to the Playwright configuration file |
privateLocations | string[] | ❌ | [] | Default private locations for all checks |
retryStrategy | object | ❌ | - | Control the retry behavior for failed checks |
runtimeId | string | ❌ | - | Default runtime ID for all checks |
shouldFail | boolean | ❌ | false | Whether the behavior of when a check/alert is considered to fail is inverted. |
tags | string[] | ❌ | [] | Default tags applied to all checks |
browserChecks | object | ❌ | - | Default settings for browser checks |
multiStepChecks | object | ❌ | - | Default settings for multi-step checks |
playwrightChecks | object | ❌ | - | Default settings for Playwright Check Suites |
General Settings for All Check and Monitor Types
Define global defaults for all checks and monitors in this project. Individual checks and groups can override these settings.Whether the checks and monitors are enabled and will run according to its schedule.Usage:
Default alert channels for all checks and monitors.Usage:
Glob pattern where the CLI looks for files containing Check constructs, i.e. all
.check.ts
files.Usage:We recommend to establish a clear file convention like
*.check.ts
to easily identify files containing Checkly constructs.Environment variables available to the check script and monitors.Usage:
Default frequency at which the checks and monitors are executed.Usage:Available frequencies:
EVERY_1M
, EVERY_2M
, EVERY_5M
, EVERY_10M
, EVERY_15M
, EVERY_30M
, EVERY_1H
, EVERY_2H
, EVERY_3H
, EVERY_6H
, EVERY_12H
, EVERY_24H
Use
UrlMonitor
or TcpMonitor
construct for high-frequency checks running up to every ten seconds.Directories to ignore when looking for check files.Usage:
Array of public location codes where the URL monitor should run from. Multiple locations provide geographic coverage.
Find a list of all public locations in the general documentation.
Determine if any notifications will be sent out when a check fails and/or recovers. Muting checks is useful for temporarily silencing alerts during maintenance.Usage:
Global configuration options for the Playwright Test Runner use in Browser Checks and MultiStep Checks. This allows you to configure your Playwright-powered checks in a single place, instead of having to repeat the same configuration for each test file.Usage:
Learn more about the supported Playwright configuration options in the Browser Check Playwright documentation.
Browser Checks don’t support the
projects
, globalSetup
, globalTeardown
and storageState
options. Check Playwright Check Suites for full Playwright support.Private Locations to run your monitors and checks from.Usage:
Learn more about Private Locations in the general documentation.
checks.retryStrategy
Set a retry policy for your checks and monitors. Use
RetryStrategyBuilder
to create a retry policy.Usage:Learn more about alerting and retries in the general documentation.
The runtime version used to execute checks and monitors.Usage:
Learn more about Checkly runtimes in the general documentation.
The tags assigned to the checks and monitors.Usage:
Default Settings for Complex Check Types
If your project doesn’t require specific configuration and you want to quickly transform your Playwright end-to-end tests into Browser Checks, use the
Example:
browserChecks.testMatch
property.Properties:Parameter | Type | Required | Default | Description | |
---|---|---|---|---|---|
testMatch | string | string[] | ❌ | - | Glob pattern for Playwright tests uses as Browser Checks |
The
checks.browserChecks
property gives your monitoring setup a head start by turning your existing end-to-end tests into monitors. For more advanced use cases and individual configuration use the BrowserCheck
construct.If your project doesn’t require specific configuration and you want to quickly transform your Playwright API tests into Multistep Checks, use the
Example:
multiStepChecks.testMatch
property.Properties:Parameter | Type | Required | Default | Description | |
---|---|---|---|---|---|
testMatch | string | string[] | ❌ | - | Glob pattern for Playwright tests uses as Browser Checks |
The
checks.multiStepChecks
property gives your monitoring setup a head start by turning your existing API tests into monitors. For more advanced use cases and individual configuration use the MultistepCheck
construct.Usage:Parameters:
Parameter | Type | Required | Default | Description |
---|---|---|---|---|
playwrightConfigPath | string | ✅ | - | Path to the Playwright configuration file |
installCommand | string | ❌ | - | Command to install dependencies before running tests |
testCommand | string | ❌ | - | Command to execute Playwright tests |
pwProjects | string | string[] | ❌ | - | Projects to run from your configuration |
pwTags | string | string[] | ❌ | - | Tags to filter tests using Playwright’s grep functionality |
include | string | string[] | ❌ | - | File patterns to include when bundling the test project |
groupName | string | ❌ | - | Name of the check group to assign this check to |
The
checks.playwrightChecks
property gives your monitoring setup a head start by turning your existing Playwright test suite into synthetic monitoring. For more advanced use cases and individual configuration use the PlaywrightCheck
construct.