Skip to main content
The Project and CheckGroup constructs allow you to use file-based routing to discover files and create checks and monitors. This approach enables you to add and remove files from your project, and have the corresponding Checks created or removed automatically when you run npx checkly deploy.

​
checks.checkMatch

The checkMatch property takes a glob pattern to match files inside your project structure that contain instances of a Check, i.e. **/__checks__/*.check.ts. The goal of this property is so you can add files to an existing repo that are automatically detected. This pattern should be very familiar to unit testing: the test runner takes care of finding, building and running all the files. Removing files containing your check and monitoring configuration will lead to deleted monitoring resources once you run npx checkly deploy. Here are some best practices:
  1. Establish a file name convention for your Check files, e.g. *.check.ts.
  2. Store any Checkly related Checks inside a __checks__ folder. This neatly indicates where your Checks are organized.
  3. Use multiple __checks__ folders throughout your code base, near the functionality it should be checking.
checkly.config.ts
const config = defineConfig({
  checks: {
    // A glob pattern that matches the Checks inside your repo.
    checkMatch: "**/__checks__/**/*.check.ts",
  },
})

​
browserChecks.testMatch

The testMatch property is very similar to checkMatch. This property allows you to write standard *.spec.ts Playwright files with no proprietary Checkly config or code added — this is why it’s nested under browserChecks as it only applies to Browser Checks. In turn, this allows you to just use npx playwright test on the command line to write and debug these Checks. Some caveats:
  1. As a .spec.ts file does not contain any Checkly specific properties like frequency or tags, the CLI will add these properties based on the defaults set inside the browserChecks config object.
  2. A logicalId and name will be generated based on the file name.
  3. If you want to explicitly set the properties for a Browser Check and not use the defaults, you need to add a BrowserCheck construct in a separate .check.ts file and set file path to the .spec.ts file in the code.entrypoint property.
  4. When you rename a file that was previously deployed, the logicalId will change. The effect is that once you deploy again the new logicalId will trigger a deletion of the “old” Check and a creation of this “new” Check and you will lose any historical metrics.
const config = defineConfig({
  checks: {
    checkMatch: "**/__checks__/**/*.check.ts",
    browserChecks: {
      // A glob pattern matches any Playwright .spec.ts files
      // and automagically creates a Browser Check.
      testMatch: "**/__checks__/**/*.spec.ts",
    },
  },
})

​
multiStepChecks.testMatch

The testMatch property for Multistep checks work the same as for Browser checks described above. Some caveats:
  1. browserChecks.testMatch will have priority to resolve directories. We recommend having a clear definition for each Browser and Multistep check to prevent loading the wrong check type. For example using browserChecks.testMatch: ['__checks__/**/*.ts'] and browserChecks.testMatch: ['__checks__/multistep/**/*.ts'] will result in all checks created as Browser checks.
const config = defineConfig({
  checks: {
    checkMatch: "**/__checks__/**/*.check.ts",
    // A glob pattern matches any Playwright .spec.ts files
    // and automagically creates MultiStep Checks.
    multiStepChecks: {
      testMatch: "**/__checks__/**/*.spec.ts",
    },
  },
})
Note that the recommended patterns are just conventions. You can set any glob pattern or turn off any globbing by setting checkMatch: false and / or testMatch: false.