CLI 8 records by default

cli/attaching-git-metadata.mdx

@@ -9,7 +9,7 @@ The CLI can attach git metadata like `branch`, `commit sha`, `owner` and more wh
 your test sessions and deployed resources in the UI and cross-reference them with any updates to your code.
 
 For example, in the screenshot below we ran a **test session** from our CI server after the project was deployed to our 
-Staging environment with the `npx checkly test --record` command.
+Staging environment with the `npx checkly test` command.
 
 ![test session with git info](/images/docs/images/cli/test_session_git_data.png)
 
@@ -28,11 +28,11 @@ can also set these data items specifically by using environment variables.
 For example, if you want to specifically set the Environment you invoke:
 
 ```bash Terminal
-CHECKLY_TEST_ENVIRONMENT=Production npx checkly test --record
+CHECKLY_TEST_ENVIRONMENT=Production npx checkly test
 ```
 
 Or, if you want to set repo URL you invoke:
 
 ```bash Terminal
-CHECKLY_REPO_URL="https://my.git.solution/project/" npx checkly test --record
+CHECKLY_REPO_URL="https://my.git.solution/project/" npx checkly test
 ```

cli/checkly-init.mdx

@@ -98,7 +98,7 @@ CI=true npx checkly init
 After initialization, the typical workflow is:
 
 1. **Log in** — `npx checkly login` to authenticate with your Checkly account
-2. **Test** — `npx checkly test --record` to dry-run your checks
+2. **Test** — `npx checkly test` to dry-run your checks
 3. **Deploy** — `npx checkly deploy` to deploy checks to Checkly
 
 ## Related Commands

cli/checkly-test.mdx

@@ -250,9 +250,9 @@ Record test results in Checkly as [a test session](/detect/testing/overview) wit
 **Usage:**
 
 ```bash Terminal
-npx checkly test --record
+npx checkly test
 npx checkly test --no-record
-npx checkly test --record --test-session-name="CI Build #123"
+npx checkly test --test-session-name="CI Build #123"
 ```
 
 </ResponseField>
@@ -301,8 +301,8 @@ A name to use when recording results in Checkly.
 **Usage:**
 
 ```bash Terminal
-npx checkly test --record --test-session-name="Release v1.2.3"
-npx checkly test --record -n="Nightly Test Run"
+npx checkly test --test-session-name="Release v1.2.3"
+npx checkly test -n="Nightly Test Run"
 ```
 
 </ResponseField>
@@ -378,10 +378,10 @@ Dry run checks that have `product` and `api` in the file name:
 npx checkly test product api
 ```
 
-Record a test session in Checkly with git branch info, full logging, videos and traces:
+Run a test session in Checkly with git branch info, full logging, videos and traces:
 
 ```bash Terminal
-npx checkly test --record
+npx checkly test
 ```
 
 Dry run all checks against a specific location:

cli/checkly-trigger.mdx

@@ -203,7 +203,7 @@ A name to use when recording results in Checkly.
 **Usage:**
 
 ```bash Terminal
-npx checkly trigger --record --test-session-name="Custom session name"
+npx checkly trigger --test-session-name="Custom session name"
 ```
 
 </ResponseField>
@@ -298,21 +298,21 @@ Record check results in Checkly as a test session with full logs, traces and vid
 **Usage:**
 
 ```bash Terminal
-npx checkly trigger --record
+npx checkly trigger
 npx checkly trigger --no-record
 ```
 
 **Examples:**
 
 ```bash Terminal
-# Record with a custom session name
-npx checkly trigger --record --test-session-name "Deploy validation"
+# Run with a custom session name
+npx checkly trigger --test-session-name "Deploy validation"
 
-# Record specific checks
-npx checkly trigger --record --tags critical
+# Run specific checks
+npx checkly trigger --tags critical
 
-# Record selected checks by ID
-npx checkly trigger --record --check-id=<check-id>
+# Run selected checks by ID
+npx checkly trigger --check-id=<check-id>
 
 # Run without recording
 npx checkly trigger --no-record
@@ -403,7 +403,7 @@ Default: 600 seconds (10 minutes). Adjust based on your longest-running checks.
 Run your deployed checks before promoting code to production:
 
 ```bash Terminal
-npx checkly trigger --tags staging --record --test-session-name "Pre-prod validation"
+npx checkly trigger --tags staging --test-session-name "Pre-prod validation"
 ```
 
 <Tip>If your production deployment includes monitoring changes and updates, [use `npx checkly test`](/cli/checkly-test) to validate your preview environment with the updated monitoring configuration.</Tip>

detect/synthetic-monitoring/browser-checks/visual-regressions.mdx

@@ -249,10 +249,9 @@ In a typical scenario, you would follow the steps below:
    The resulting files are stored in a `some-file-prepend.ts-snapshots` folder next to your browser check script.
 3. Commit the browser check script and the golden image / reference snapshot(s) to your version control system.
 4. Push your code to your CI/CD pipeline.
-5. In your CI/CD pipeline, optionally run your checks again. Maybe add the `--record` flag to record the test in 
-Checkly.
+5. In your CI/CD pipeline, test your checks before deploying. Test results will be uploaded to Checkly's test sessions for review.
    ```bash
-   npx checkly test --record 
+   npx checkly test 
    ```
 6. If your tests pass, deploy your checks to production. The CLI will push your snapshot to the
 Checkly cloud automatically.

detect/synthetic-monitoring/playwright-checks/environment-variables.mdx

@@ -32,11 +32,11 @@ Checkly sets the following environment variables on every Playwright Check Suite
 | `GROUP_RUN_ALL` | The "Run all checks" action on the group's edit screen started the run. |
 | `SCHEDULE_NOW` | The "Schedule now" action in the web app started the run. |
 | `SCHEDULER` | The regular check schedule started the run. |
-| `TEST_NO_RECORD` | `npx checkly test` started the run. |
-| `TEST_RECORD` | `npx checkly test --record` or `npx checkly pw-test` started the run. |
+| `TEST_NO_RECORD` | `npx checkly test --no-record` started the run. |
+| `TEST_RECORD` | `npx checkly test` or `npx checkly pw-test` started the run. |
 | `TRIGGER_API` | The API started the run. |
-| `TRIGGER_NO_RECORD` | `npx checkly trigger` started the run. |
-| `TRIGGER_RECORD` | `npx checkly trigger --record` started the run. |
+| `TRIGGER_NO_RECORD` | `npx checkly trigger --no-record` started the run. |
+| `TRIGGER_RECORD` | `npx checkly trigger` started the run. |
 
 ## Use built-in variables
 

detect/testing/creating-your-first-test.mdx

@@ -118,7 +118,7 @@ Before deploying, test your checks locally:
 npx checkly test
 
 # Test with recording (saves videos and traces)
-npx checkly test --record
+npx checkly test
 
 # Test specific checks
 npx checkly test homepage

guides/end-to-end-monitoring.mdx

@@ -275,9 +275,9 @@ Then we use the `expect` function to assert that the HTTP status code of the res
 `page.title()` retrieves the title of the page and compares it with the expected title ('Introduction to Checkly | Checkly') using the `expect` function. This ensures that the page title matches the expected value.
 Finally, we take a screenshot of the page and save it as 'homepage.jpg'.
 Step 4: Running Test Sessions
-Now that we have our test scripts ready, let’s execute them. We can use the Check CLI command to execute our monitoring pipeline in our staging environment, recording the results for inspection if something fails. Run the following command in the terminal of your project repository to execute the test:
-`npx checkly test --record`
-The `--record` flag is optional, you can use it if you want to record a test session with git info, full logging, videos and traces. `--record` sessions can be reviewed within the Checkly web interface.
+Now that we have our test scripts ready, let's execute them. Run the following command in the terminal of your project repository to test your checks against Checkly's infrastructure:
+`npx checkly test`
+You can review the test session with full logging, videos and traces in the Checkly web interface.
 Here is the result of the test we just executed:
 
 ![Running tests from the CLI](/images/guides/images/guides-checkly-cli-check-run.jpg "Running tests from the CLI")

guides/getting-started-with-monitoring-as-code.mdx

@@ -95,11 +95,11 @@ Finally, we take a screenshot of the page and save it as 'homepage.jpg'.
 
 ### 3. Running Test Sessions
 
-Now that we have our test scripts ready, let’s execute them. We can use the Check CLI command to execute our monitoring pipeline in our staging environment, recording the results for inspection if something fails. Run the following command in the terminal of your project repository to execute the test:
+Now that we have our test scripts ready, let's execute them. Run the following command in the terminal of your project repository to test your checks against Checkly's infrastructure:
 
-`npx checkly test --record`
+`npx checkly test`
 
-The `--record` flag is optional, you can use it if you want to record a test session with git info, full logging, videos and traces. `--record` sessions can be reviewed within the Checkly web interface.
+You can review the test session with full logging, videos and traces in the Checkly web interface.
 
 Here is the result of the test we just executed:
 

integrations/ci-cd/gitlab/overview.mdx

@@ -45,7 +45,7 @@ e2e-staging:
     CHECKLY_TEST_ENVIRONMENT: review/$CI_COMMIT_REF_SLUG
   script:
     - npm ci
-    - npx checkly test --record
+    - npx checkly test
   except:
     - main
 
@@ -61,7 +61,7 @@ e2e-production:
     CHECKLY_TEST_ENVIRONMENT: "production"
   script:
     - npm ci
-    - npx checkly test --record
+    - npx checkly test
   only:
     - main
 

integrations/ci-cd/jenkins/overview.mdx

@@ -10,11 +10,11 @@ We've optimized the [Checkly CLI](/cli/overview/) to work in any CI/CD workflow.
 1. For **authentication**, make sure to set the `CHECKLY_API_KEY` and `CHECKLY_ACCOUNT_ID` parameters as environment variables
 in your CI/CD platform.
 2. Set the **reporter** you want to use for the `test` command using the `--reporter` flag, i.e. `--reporter=dot`.
-3. To store a **test session** with full logging, traces and vides, set the `--record` flag for the `test` command.
+3. Use `npx checkly test` to validate your checks before deploying. Test results, traces, and videos are available in Checkly as a **test session**.
 4. Use the `--force` flag on the `deploy` and / or `destroy` commands to skip the normal confirmation steps.
 
-When using the `--record` flag, the CLI will attempt to parse `git` specific information from
-the environment to display in the recorded test session as metadata. However, you can also set these data items specifically by using environment variables.
+The CLI will attempt to parse `git` specific information from the environment to display in the test session as metadata.
+You can also set these data items specifically by using environment variables.
 
 <CliEnvVars />
 
@@ -83,7 +83,7 @@ pipeline {
         }
         stage('checkly test') {
             steps {
-                sh 'npx checkly test --record'
+                sh 'npx checkly test'
             }
         }
         stage('checkly deploy') {

integrations/ci-cd/overview.mdx

@@ -34,11 +34,10 @@ will come in handy when adapting the examples we give you to your own, specific
 1. For **authentication**, make sure to set the `CHECKLY_API_KEY` and `CHECKLY_ACCOUNT_ID` parameters as environment variables
 in your CI/CD platform.
 2. Set the **reporter** you want to use for the `test` command using the `--reporter` flag, i.e. `--reporter=dot`.
-3. To store a **test session** with full logging, traces and vides, set the `--record` flag for the `test` command.
+3. Use `npx checkly test` to validate your checks before deploying. Test results, traces, and videos are available in Checkly as a **test session**.
 4. Use the `--force` flag on the `deploy` and / or `destroy` commands to skip the normal confirmation steps.
 
-When using the `--record` flag, the CLI will attempt to parse `git` specific information from
-the environment to display in the recorded test session as metadata. However, you can also set these data items specifically
-by using environment variables.
+The CLI will attempt to parse `git` specific information from the environment to display in the test session as metadata.
+You can also set these data items specifically by using environment variables.
 
 <CliEnvVars />

quickstarts/playwright-check.mdx

@@ -23,7 +23,7 @@ The prompt guides your AI tool to:
 1. Inspect your Playwright configuration and test files
 2. Recommend which tests to monitor first
 3. Generate a minimal `checkly.config.ts` with alert channels
-4. Run `npx checkly test --record` and `npx checkly deploy`
+4. Run `npx checkly test` and `npx checkly deploy`
 
 <Accordion title="View the full prompt">
 <SetupPrompt />
@@ -132,12 +132,10 @@ Per-check `frequency` and `locations` override the global defaults set in Step 2
 Before deploying, validate your monitoring setup locally:
 
 ```bash terminal
-npx checkly test --record
+npx checkly test
 ```
 
-The `--record` flag uploads results to Checkly so you can review traces, logs, and screenshots in the UI.
-
-This runs your check suites in Checkly's infrastructure and shows results:
+This runs your check suites in Checkly's infrastructure and shows results in the terminal. You can also review traces, logs, and screenshots in the Checkly UI.
 
 ```bash
 Parsing your project... ✅
@@ -156,7 +154,7 @@ playwright.config.ts
 **Test specifying the environment type:**
 
 ```bash terminal
-npx checkly test --record --env ENVIRONMENT=staging
+npx checkly test --env ENVIRONMENT=staging
 ```
 
 <Info>