docs: document intent for supported checks and monitors

constructs/api-check.mdx

@@ -5,6 +5,8 @@ sidebarTitle: 'API Check'
 canonical: 'https://www.checklyhq.com/docs/constructs/api-check/'
 ---
 
+import CheckIntent from '/snippets/check-intent.mdx';
+
 <Tip>
 Learn more about API Checks in [the API Checks overview](/detect/synthetic-monitoring/api-checks/overview).
 </Tip>
@@ -94,6 +96,7 @@ The API Check configuration consists of specific API Check options and inherited
 |----------|------|----------|---------|-------------|
 | `name` | `string` | ✅ | - | Friendly name for your check |
 | `description` | `string` | ❌ | `null` | A description of the check. Supports markdown. Max 500 characters |
+| `intent` | `CheckIntent` | ❌ | - | Structured guidance for root cause analysis and check repair. See [General Check Options](#general-check-options). |
 | `activated` | `boolean` | ❌ | `true` | Whether the check is enabled |
 | `alertChannels` | `AlertChannel[]` | ❌ | `[]` | Array of AlertChannel objects for notifications |
 | `alertEscalationPolicy` | `AlertEscalationPolicy` | ❌ | - | Advanced alert settings |
@@ -461,6 +464,10 @@ AssertionBuilder.headers('strict-transport-security', 'max-age=(\\d+)').greaterT
 { source: 'HEADERS', regex: 'max-age=(\d+)', property: 'strict-transport-security', comparison: 'GREATER_THAN', target: '10000' }
 ```
 
+### General Check Options
+
+<CheckIntent />
+
 ## Examples
 
 <CodeGroup>

constructs/browser-check.mdx

@@ -5,6 +5,8 @@ sidebarTitle: 'Browser Check'
 canonical: 'https://www.checklyhq.com/docs/constructs/browser-check/'
 ---
 
+import CheckIntent from '/snippets/check-intent.mdx';
+
 <Tip>
 Learn more about Browser Checks in [the Browser Checks overview](/detect/synthetic-monitoring/browser-checks/overview).
 </Tip>
@@ -81,6 +83,7 @@ The Browser Check configuration consists of specific Browser Check options and i
 |----------|------|----------|---------|-------------|
 | `name` | `string` | ✅ | - | Friendly name for your check |
 | `description` | `string` | ❌ | `null` | A description of the check. Supports markdown. Max 500 characters |
+| `intent` | `CheckIntent` | ❌ | - | Structured guidance for root cause analysis and check repair. See [General Check Options](#general-check-options). |
 | `activated` | `boolean` | ❌ | `true` | Whether the check is enabled |
 | `alertChannels` | `AlertChannel[]` | ❌ | `[]` | Array of AlertChannel objects for notifications |
 | `alertEscalationPolicy` | `AlertEscalationPolicy` | ❌ | - | Advanced alert settings |
@@ -437,6 +440,8 @@ new BrowserCheck("feature-test", {
 **Use cases**: Test configuration, authentication, API keys, feature flags, environment-specific settings.
 </ResponseField>
 
+<CheckIntent />
+
 ## Examples
 
 <CodeGroup>

constructs/dns-monitor.mdx

@@ -5,6 +5,8 @@ sidebarTitle: 'DNS Monitor'
 canonical: 'https://www.checklyhq.com/docs/constructs/dns-monitor/'
 ---
 
+import CheckIntent from '/snippets/check-intent.mdx';
+
 import GeneralMonitorOptionsTable from '/snippets/general-monitor-options-table.mdx';
 
 <Tip>
@@ -85,6 +87,7 @@ A DNS Monitor has its own DNS-specific settings, plus the standard monitor optio
 | Parameter | Type | Required | Default | Description |
 |-----------|------|----------|---------|-------------|
 | `request` | `object` | ✅ | - | DNS request configuration object |
+| `intent` | `CheckIntent` | ❌ | - | Structured guidance for root cause analysis and check repair. See [General Monitor Options](#general-monitor-options). |
 | `degradedResponseTime` | `number` | ❌ | `500` | Response time threshold in milliseconds for degraded status |
 | `maxResponseTime` | `number` | ❌ | `1000` | Maximum response time in milliseconds before marking as failed |
 
@@ -258,4 +261,6 @@ new DnsMonitor("my-monitor", {
 })
 ```
 
-</ResponseField>
+</ResponseField>
+
+<CheckIntent />

constructs/grpc-monitor.mdx

@@ -5,6 +5,8 @@ sidebarTitle: 'gRPC Monitor'
 canonical: 'https://www.checklyhq.com/docs/constructs/grpc-monitor/'
 ---
 
+import CheckIntent from '/snippets/check-intent.mdx';
+
 import GeneralMonitorOptionsTable from '/snippets/general-monitor-options-table.mdx';
 
 <Tip>
@@ -94,6 +96,7 @@ gRPC monitors have their own gRPC-specific settings, plus the standard monitor o
 | Parameter | Type | Required | Default | Description |
 |-----------|------|----------|---------|-------------|
 | `request` | `object` | ✅ | - | gRPC request configuration object |
+| `intent` | `CheckIntent` | ❌ | - | Structured guidance for root cause analysis and check repair. See [General Monitor Options](#general-monitor-options). |
 | `degradedResponseTime` | `number` | ❌ | `10000` | Response time in milliseconds at which the monitor is marked as degraded |
 | `maxResponseTime` | `number` | ❌ | `20000` | Response time in milliseconds at which the monitor is marked as failed (max 180,000) |
 
@@ -319,6 +322,8 @@ new GrpcMonitor('my-grpc-monitor', {
 
 </ResponseField>
 
+<CheckIntent />
+
 ## Examples
 
 <Tabs>

constructs/icmp-monitor.mdx

@@ -5,6 +5,8 @@ sidebarTitle: 'ICMP Monitor'
 canonical: 'https://www.checklyhq.com/docs/constructs/icmp-monitor/'
 ---
 
+import CheckIntent from '/snippets/check-intent.mdx';
+
 import GeneralMonitorOptionsTable from '/snippets/general-monitor-options-table.mdx';
 
 <Tip>
@@ -73,6 +75,7 @@ ICMP monitors have their own ICMP-specific settings, plus the standard monitor o
 | Parameter | Type | Required | Default | Description |
 |-----------|------|----------|---------|-------------|
 | `request` | `object` | ✅ | - | ICMP request configuration object |
+| `intent` | `CheckIntent` | ❌ | - | Structured guidance for root cause analysis and check repair. See [General Monitor Options](#general-monitor-options). |
 | `degradedPacketLossThreshold` | `number` | ❌ | `10` | Packet loss percentage at which the monitor is marked as degraded |
 | `maxPacketLossThreshold` | `number` | ❌ | `20` | Packet loss percentage at which the monitor is marked as failed |
 
@@ -235,4 +238,6 @@ new IcmpMonitor("my-monitor", {
 })
 ```
 
-</ResponseField>
+</ResponseField>
+
+<CheckIntent />

constructs/multistep-check.mdx

@@ -5,6 +5,8 @@ sidebarTitle: 'Multistep Check'
 canonical: 'https://www.checklyhq.com/docs/constructs/multistep-check/'
 ---
 
+import CheckIntent from '/snippets/check-intent.mdx';
+
 <Tip>
 Learn more about Multistep Checks in [the Multistep Checks overview](/detect/synthetic-monitoring/multistep-checks/overview).
 </Tip>
@@ -79,6 +81,7 @@ new MultiStepCheck("complex-multistep-check", {
 |----------|------|----------|---------|-------------|
 | `name` | `string` | ✅ | - | Friendly name for your check |
 | `description` | `string` | ❌ | `null` | A description of the check. Supports markdown. Max 500 characters |
+| `intent` | `CheckIntent` | ❌ | - | Structured guidance for root cause analysis and check repair. See [General Check Options](#general-check-options). |
 | `activated` | `boolean` | ❌ | `true` | Whether the check is enabled |
 | `alertChannels` | `AlertChannel[]` | ❌ | `[]` | Array of AlertChannel objects for notifications |
 | `alertEscalationPolicy` | `AlertEscalationPolicy` | ❌ | - | Advanced alert settings |
@@ -362,3 +365,5 @@ new MultiStepCheck("eu-workflow", {
 <Warning>
 Multistep checks are only supported on runtime `2023.09` or later. Make sure to specify a compatible `runtimeId` in your check configuration.
 </Warning>
+
+<CheckIntent />

constructs/playwright-check.mdx

@@ -5,6 +5,8 @@ sidebarTitle: 'Playwright Check Suites'
 canonical: 'https://www.checklyhq.com/docs/constructs/playwright-check/'
 ---
 
+import CheckIntent from '/snippets/check-intent.mdx';
+
 import GeneralMonitorOptionsTable from '/snippets/general-monitor-options-table.mdx';
 
 <Tip>
@@ -78,6 +80,7 @@ The Playwright Check Suite configuration consists of specific Playwright Check S
 |----------|------|----------|---------|-------------|
 | `name` | `string` | ✅ | - | Friendly name for your check |
 | `description` | `string` | ❌ | `null` | A description of the check. Supports markdown. Max 500 characters |
+| `intent` | `CheckIntent` | ❌ | - | Structured guidance for root cause analysis and check repair. See [General Check Options](#general-check-options). |
 | `activated` | `boolean` | ❌ | `true` | Whether the check is enabled |
 | `alertChannels` | `AlertChannel[]` | ❌ | `[]` | Array of AlertChannel objects for notifications |
 | `alertEscalationPolicy` | `AlertEscalationPolicy` | ❌ | - | Advanced alert settings |
@@ -518,6 +521,8 @@ new PlaywrightCheck("feature-test", {
 **Use cases**: Test configuration, authentication, API keys, feature flags, environment-specific settings.
 </ResponseField>
 
+<CheckIntent />
+
 ## Examples
 
 <CodeGroup>

constructs/tcp-monitor.mdx

@@ -5,6 +5,8 @@ sidebarTitle: 'TCP Monitor'
 canonical: 'https://www.checklyhq.com/docs/constructs/tcp-monitor/'
 ---
 
+import CheckIntent from '/snippets/check-intent.mdx';
+
 import GeneralMonitorOptionsTable from '/snippets/general-monitor-options-table.mdx';
 
 <Tip>
@@ -81,6 +83,7 @@ The TCP Monitoring configuration consists of specific TCP monitoring options and
 | Parameter | Type | Required | Default | Description |
 |-----------|------|----------|---------|-------------|
 | `request` | `object` | ✅ | - | TCP connection configuration object |
+| `intent` | `CheckIntent` | ❌ | - | Structured guidance for root cause analysis and check repair. See [General Monitor Options](#general-monitor-options). |
 | `degradedResponseTime` | `number` | ❌ | `4000` | Response time threshold in milliseconds for degraded status |
 | `maxResponseTime` | `number` | ❌ | `5000` | Maximum response time in milliseconds before marking as failed |
 | `shouldFail` | `boolean` | ❌ | `false` | Treat connection failures (e.g. timeouts or refused ports) as passed. Successful connections still pass. Only failed assertions will cause the check to fail. |
@@ -429,6 +432,8 @@ new TcpMonitor("maintenance-db", {
 ```
 </ResponseField>
 
+<CheckIntent />
+
 ## Examples
 
 <Tabs>

constructs/url-monitor.mdx

@@ -5,6 +5,8 @@ sidebarTitle: 'URL Monitor'
 canonical: 'https://www.checklyhq.com/docs/constructs/url-monitor/'
 ---
 
+import CheckIntent from '/snippets/check-intent.mdx';
+
 import GeneralMonitorOptionsTable from '/snippets/general-monitor-options-table.mdx';
 
 <Tip>
@@ -76,6 +78,7 @@ The URL Monitoring configuration consists of specific URL monitoring options and
 | Parameter | Type | Required | Default | Description |
 |-----------|------|----------|---------|-------------|
 | `request` | `object` | ✅ | - | HTTP request configuration object |
+| `intent` | `CheckIntent` | ❌ | - | Structured guidance for root cause analysis and check repair. See [General Monitor Options](#general-monitor-options). |
 | `degradedResponseTime` | `number` | ❌ | `3000` | Response time threshold in milliseconds for degraded status |
 | `maxResponseTime` | `number` | ❌ | `5000` | Maximum response time in milliseconds before marking as failed |
 | `shouldFail` | `boolean` | ❌ | false | Treat HTTP error codes (4xx and 5xx) as passed. Please note that successful responses still pass. Only failed assertions will cause the check to fail. |
@@ -405,6 +408,8 @@ new UrlMonitor("maintenance-site", {
 ```
 </ResponseField>
 
+<CheckIntent />
+
 ## Examples
 
 <Tabs>

resolve/automatic-check-repair.mdx

@@ -7,7 +7,7 @@ canonical: 'https://www.checklyhq.com/docs/resolve/automatic-check-repair/'
 
 For a check managed in Checkly, automatic repair can attempt to fix a Browser or Multistep Check when its script fails because of a check issue. A check intent states the goal, required outcomes, and guardrails that a repair must preserve. A failed check is not automatically repaired just because this setting is on; Rocky AI first needs a repairable failure and a valid intent.
 
-Checks linked to a GitHub source file can also receive a repair proposal through a pull request, including other check types. Merge and deploy that change to update the running check.
+Browser and Multistep Checks linked to a GitHub source file can also receive a repair proposal through a pull request. Merge and deploy that change to update the running check.
 
 <Accordion title="Prerequisites">
 
@@ -32,6 +32,71 @@ For an existing Browser or Multistep Check, select **Initialize from saved check
 
 You can also write the intent yourself. Use this option when the script does not express all of the business requirements a repair must preserve. For example, a script might check that a page loads while the actual goal also requires a signed-in user to see the correct account.
 
+## Define intent with Monitoring as Code
+
+You can also define `intent` in your [Monitoring as Code](/cli/overview) configuration using the Checkly CLI. Keep the goal, required outcomes, and guardrails alongside your check definition. See the General Check Options in the [Browser Check](/constructs/browser-check#general-check-options) and [Multistep Check](/constructs/multistep-check#general-check-options) construct references for the `intent` schema and a complete configuration example.
+
+Use your existing Browser or Multistep Check test file in these examples.
+
+<Tabs>
+<Tab title="Browser Check">
+
+```ts
+import { BrowserCheck } from "checkly/constructs"
+
+new BrowserCheck("dashboard-browser", {
+  name: "Authenticated dashboard",
+  code: {
+    entrypoint: "./dashboard.spec.ts",
+  },
+  intent: {
+    goal: "Verify that authenticated users can open the dashboard.",
+    constraints: [
+      {
+        type: "REQUIRED_OUTCOME",
+        statement: "Authentication succeeds for a valid user.",
+      },
+      {
+        type: "MUST_PRESERVE",
+        statement: "Do not remove or weaken the authentication assertion.",
+      },
+    ],
+  },
+})
+```
+
+</Tab>
+<Tab title="Multistep Check">
+
+```ts
+import { MultiStepCheck } from "checkly/constructs"
+
+new MultiStepCheck("authenticated-api", {
+  name: "Authenticated API flow",
+  code: {
+    entrypoint: "./authenticated-api.spec.ts",
+  },
+  intent: {
+    goal: "Verify that authenticated users can retrieve their account through the API.",
+    constraints: [
+      {
+        type: "REQUIRED_OUTCOME",
+        statement: "Authentication succeeds for a valid user.",
+      },
+      {
+        type: "MUST_PRESERVE",
+        statement: "Do not remove or weaken the authentication assertion.",
+      },
+    ],
+  },
+})
+```
+
+</Tab>
+</Tabs>
+
+Defining `intent` does not by itself enable automatic repair or change which check types support Checkly-managed repair.
+
 ## AI invocation usage
 
 Root cause analysis and automatic repair each use one AI invocation from your plan's allowance. Each AI Assistant conversation uses one invocation on its first run. Later messages in that conversation use no more invocations. **Initialize from saved check** does not use an invocation. See [Rocky AI consumption and invocations](../ai/rocky-ai#consumption-and-invocations).

snippets/check-intent.mdx

@@ -0,0 +1,48 @@
+<ResponseField name="intent" type="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.
+
+<Note>
+Intent is used for [automatic repair](/resolve/automatic-check-repair) only for Browser and Multistep Checks.
+</Note>
+
+The object accepts the following fields:
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `goal` | `string` | Yes | The outcome your check should verify. Must contain 1–2,000 characters after trimming. |
+| `constraints` | `CheckIntentConstraint[]` | No | Outcomes and guardrails that refine the goal. Omitted constraints become an empty array. |
+
+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:
+
+```ts
+import { BrowserCheck } from "checkly/constructs"
+
+new BrowserCheck("dashboard-intent", {
+  name: "Authenticated dashboard",
+  code: {
+    entrypoint: "./dashboard.spec.ts",
+  },
+  intent: {
+    goal: "Verify that authenticated users can open the dashboard.",
+    constraints: [
+      {
+        type: "REQUIRED_OUTCOME",
+        statement: "Authentication succeeds for a valid user.",
+      },
+      {
+        type: "MUST_PRESERVE",
+        statement: "Do not remove or weaken the authentication assertion.",
+      },
+    ],
+  },
+})
+```
+
+</ResponseField>