> ## Documentation Index
> Fetch the complete documentation index at: https://checklyhq.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Create Checks Automatically from Files

> Learn how to automatically include checks in your project

The [Project](/constructs/project) and [CheckGroup](/constructs/check-group-v2) 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](https://www.npmjs.com/package/glob) 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.

```ts checkly.config.ts highlight={4} theme={null}
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](/constructs/browser-check) 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.

<CodeGroup>
  ```ts checkly.config.ts highlight={7} theme={null}
  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",
      },
    },
  })
  ```

  ```ts group.check.ts highlight={6} theme={null}
  const group = new CheckGroupV2("api-monitoring-group", {
    name: "Browser Check Monitoring Group",
    browserChecks: {
      // A glob pattern matches any Playwright .spec.ts files
      // and automagically creates a Browser Check for this group.
      testMatch: "./*.spec.ts",
    },
  })
  ```
</CodeGroup>

## `multiStepChecks.testMatch`

The `testMatch` property for Multistep checks work the same as for [Browser checks described above](#browserchecks-testmatch).

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.

<CodeGroup>
  ```ts checkly.config.ts highlight={7} theme={null}
  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",
      },
    },
  })
  ```

  ```ts group.check.ts highlight={6} theme={null}
  const group = new CheckGroupV2("api-multistep-group", {
    name: "API Multistep Monitoring Group",
    multiStepChecks: {
      // A glob pattern matches any Playwright .spec.ts files
      // and automagically creates MultiStep Checks for this group.
      testMatch: "./*.multi-step.spec.ts",
    },
  })
  ```
</CodeGroup>

<Note>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`.</Note>