diff --git a/admin/team-management/overview.mdx b/admin/team-management/overview.mdx index a9ed12b7..bdd1d98c 100644 --- a/admin/team-management/overview.mdx +++ b/admin/team-management/overview.mdx @@ -24,7 +24,7 @@ Each account has one Owner. The account creator is the Owner until they [transfe | Access locked variables | ✓ | ✓ | ✓ | ✗ | ✗ | | Manage team members (only below their current role. i.e. Owners can remove Admins, but Admins cannot remove Owners or other Admins.) | ✓ | ✓ | ✗ | ✗ | ✗ | | Manage account settings | ✓ | ✓ | ✗ | ✗ | ✗ | -| Manage Private Locations | ✓ | ✓ | ✗ | ✗ | ✗ | +| Manage private locations | ✓ | ✓ | ✗ | ✗ | ✗ | | Create service API keys | ✓ | ✓ | ✗ | ✗ | ✗ | | Transfer ownership | ✓ | ✗ | ✗ | ✗ | ✗ | diff --git a/ai/ai-assistant.mdx b/ai/ai-assistant.mdx index ce6dec55..698ea03d 100644 --- a/ai/ai-assistant.mdx +++ b/ai/ai-assistant.mdx @@ -5,9 +5,9 @@ description: 'Plan monitoring and create checks and monitors with the Checkly AI canonical: 'https://www.checklyhq.com/docs/ai/ai-assistant/' --- -The AI Assistant helps you turn a monitoring goal into a plan and create the checks you approve. It can create Browser, Multistep, and API Checks, as well as uptime and Heartbeat Monitors. It does not create Playwright Check Suites. +The AI Assistant helps you turn a monitoring goal into a plan and create the checks you approve. It can create Browser, Multistep, and API checks, as well as uptime and Heartbeat monitors. It does not create Playwright Check Suites. -Every check it creates includes an intent: the goal and required outcomes the check should prove. For Browser and Multistep Checks created in Checkly, [automatic repair](../resolve/automatic-check-repair) can use that intent when repairing the check's script. +Every check it creates includes an intent: the goal and required outcomes the check should prove. For Browser and Multistep checks created in Checkly, [automatic repair](../resolve/automatic-check-repair) can use that intent when repairing the check's script. @@ -21,15 +21,15 @@ Every check it creates includes an intent: the goal and required outcomes the ch 1. Open **AI Assistant** in the Checkly app and select **New**. 2. Describe the site, app, or API you want to monitor. Include the starting point, the journey, and the observable outcome that should pass. -3. Review the proposed monitoring plan and linked Test Session results. Ask the assistant to adjust the flow, assertions, frequency, locations, or alerting before you approve it. +3. Review the proposed monitoring plan and linked test session results. Ask the assistant to adjust the flow, assertions, frequency, locations, or alerting before you approve it. 4. Select the checks you want and choose **Create checks**. -5. Open each new check, run it, and review its behavior and settings. For Browser and Multistep Checks, also review the **Check intent** section in the check settings. +5. Open each new check, run it, and review its behavior and settings. For Browser and Multistep checks, also review the **Check intent** section in the check settings. -While preparing your plan, the Assistant tests Browser, Multistep, and API Checks in recorded Test Sessions. URL and Heartbeat Monitors are outside this testing step. +While preparing your plan, the Assistant tests Browser, Multistep, and API checks in recorded test sessions. URL and Heartbeat monitors are outside this testing step. -For a browser journey, ask for a Browser Check. For an API endpoint, ask for an API Check; for several related requests, ask for a Multistep Check. Use a URL Monitor for site availability or a Heartbeat Monitor for a scheduled job. If a journey has important negative cases or guardrails, describe them in your request and confirm they appear in the generated intent. +For a browser journey, ask for a Browser check. For an API endpoint, ask for an API check; for several related requests, ask for a Multistep check. Use a URL monitor for site availability or a Heartbeat monitor for a scheduled job. If a journey has important negative cases or guardrails, describe them in your request and confirm they appear in the generated intent. -The AI Assistant does not change a check's automatic repair setting when it creates the check. A Browser or Multistep Check inherits the account default until you [set automatic repair for that check](../resolve/automatic-check-repair#enable-automatic-repair). Review its intent and choose **On** if you want to enable repair explicitly. +The AI Assistant does not change a check's automatic repair setting when it creates the check. A Browser or Multistep check inherits the account default until you [set automatic repair for that check](../resolve/automatic-check-repair#enable-automatic-repair). Review its intent and choose **On** if you want to enable repair explicitly. ## Checks that need project files diff --git a/ai/mcp-server.mdx b/ai/mcp-server.mdx index 1b563896..9eb1ef72 100644 --- a/ai/mcp-server.mdx +++ b/ai/mcp-server.mdx @@ -16,7 +16,7 @@ https://api.checklyhq.com/mcp Use it when your agent needs live Checkly account context, check status, check results, test sessions, root cause analyses, result assets, status pages, incidents, account environment variables, or when it needs to trigger existing checks. -You can create and update standalone Browser and Multistep Checks through MCP using inline scripts. Use [Checkly Skills](/ai/skills) and the [Checkly CLI](/cli/overview) when your agent needs to work with local project files, bundle code, or deploy a project. The MCP server runs remotely and cannot access your local filesystem. +You can create and update standalone Browser and Multistep checks through MCP using inline scripts. Use [Checkly Skills](/ai/skills) and the [Checkly CLI](/cli/overview) when your agent needs to work with local project files, bundle code, or deploy a project. The MCP server runs remotely and cannot access your local filesystem. OAuth is the recommended way to connect. The OAuth flow only supports Checkly-approved clients listed in setup. User and service API keys are available for clients that can send custom headers when OAuth is unavailable or a workflow needs a stable service identity. diff --git a/ai/mcp-server/tools.mdx b/ai/mcp-server/tools.mdx index 26c25404..fad031de 100644 --- a/ai/mcp-server/tools.mdx +++ b/ai/mcp-server/tools.mdx @@ -66,7 +66,7 @@ The check write tools manage checks from a JSON configuration, without a local p A typical create flow: -1. Call `get-check-type-schema` with the `checkType` to learn the `check` payload. Every check type takes different configuration, for example `request` for API checks and uptime monitors, `script` for browser checks, and `heartbeat` for heartbeat monitors. +1. Call `get-check-type-schema` with the `checkType` to learn the `check` payload. Every check type takes different configuration, for example `request` for API checks and uptime monitors, `script` for Browser checks, and `heartbeat` for Heartbeat monitors. 2. Optionally call `list-alert-channels` to pick specific alert channels, and `list-check-groups` to find a `groupId`. 3. Call `create-check` with `checkType` and the `check` payload. By default the new check is subscribed to all of the account's alert channels. Set `autoAssignAlerts` to `false` or pass `check.alertChannelSubscriptions` to change this. diff --git a/ai/mcp-server/troubleshooting.mdx b/ai/mcp-server/troubleshooting.mdx index 06416344..5af711ad 100644 --- a/ai/mcp-server/troubleshooting.mdx +++ b/ai/mcp-server/troubleshooting.mdx @@ -119,7 +119,7 @@ Views do not refresh automatically. Use **Refresh** to request current data. If ### The MCP server cannot access or deploy my local project -You can create and update standalone Browser and Multistep Checks through MCP using inline scripts. The MCP server runs remotely and cannot access your local project files, bundle code, or deploy a project. +You can create and update standalone Browser and Multistep checks through MCP using inline scripts. The MCP server runs remotely and cannot access your local project files, bundle code, or deploy a project. For local project authoring, use the [Checkly CLI](/cli/overview) in your project. To let your AI agent do this, install [Checkly Skills](/ai/skills). diff --git a/ai/rocky-ai.mdx b/ai/rocky-ai.mdx index 2192519f..b844d208 100644 --- a/ai/rocky-ai.mdx +++ b/ai/rocky-ai.mdx @@ -15,7 +15,7 @@ Use the [AI Assistant](./ai-assistant) to plan monitoring and create checks and ### Automatic Check Repair -Set an intent and enable [automatic repair](../resolve/automatic-check-repair) for a Browser or Multistep Check. +Set an intent and enable [automatic repair](../resolve/automatic-check-repair) for a Browser or Multistep check. ### Root Cause and User Impact Analysis diff --git a/ai/skills.mdx b/ai/skills.mdx index 9bc74484..34f319d0 100644 --- a/ai/skills.mdx +++ b/ai/skills.mdx @@ -73,7 +73,7 @@ Using Checkly, you can now control your monitoring setup with AI agents without **Example prompts:** - "Create a URL monitor for api.example.com that checks every 5 minutes" - - "Set up a browser check that logs into my app and verifies the dashboard loads" + - "Set up a Browser check that logs into my app and verifies the dashboard loads" - "Add a Slack alert channel for my production check group" **CLI usage:** @@ -106,7 +106,7 @@ Using Checkly, you can now control your monitoring setup with AI agents without **Example prompts:** - "Show me which checks are currently failing" - - "Investigate why the login browser check started failing yesterday" + - "Investigate why the login Browser check started failing yesterday" - "Trigger an on-demand run of my API health check" **CLI usage:** diff --git a/api-reference/heartbeats/create-a-heartbeat-check.mdx b/api-reference/heartbeats/create-a-heartbeat-check.mdx index 049fd5ec..d363229e 100644 --- a/api-reference/heartbeats/create-a-heartbeat-check.mdx +++ b/api-reference/heartbeats/create-a-heartbeat-check.mdx @@ -1,5 +1,5 @@ --- openapi: post /v1/checks/heartbeat -title: Create a heartbeat monitor +title: Create a Heartbeat monitor canonical: 'https://www.checklyhq.com/docs/api-reference/heartbeats/create-a-heartbeat-check/' --- \ No newline at end of file diff --git a/api-reference/heartbeats/get-a-list-of-events-for-a-heartbeat.mdx b/api-reference/heartbeats/get-a-list-of-events-for-a-heartbeat.mdx index 6f1a7ed2..2ab1aa2f 100644 --- a/api-reference/heartbeats/get-a-list-of-events-for-a-heartbeat.mdx +++ b/api-reference/heartbeats/get-a-list-of-events-for-a-heartbeat.mdx @@ -1,5 +1,5 @@ --- openapi: get /v1/checks/heartbeats/{checkId}/events -title: List all events for a heartbeat monitor +title: List all events for a Heartbeat monitor canonical: 'https://www.checklyhq.com/docs/api-reference/heartbeats/get-a-list-of-events-for-a-heartbeat/' --- \ No newline at end of file diff --git a/api-reference/heartbeats/get-a-specific-heartbeat-event.mdx b/api-reference/heartbeats/get-a-specific-heartbeat-event.mdx index a6433fe5..1ef901f7 100644 --- a/api-reference/heartbeats/get-a-specific-heartbeat-event.mdx +++ b/api-reference/heartbeats/get-a-specific-heartbeat-event.mdx @@ -1,5 +1,5 @@ --- openapi: get /v1/checks/heartbeats/{checkId}/events/{id} -title: List a specific event for a heartbeat monitor +title: List a specific event for a Heartbeat monitor canonical: 'https://www.checklyhq.com/docs/api-reference/heartbeats/get-a-specific-heartbeat-event/' --- \ No newline at end of file diff --git a/api-reference/heartbeats/get-heartbeat-availability.mdx b/api-reference/heartbeats/get-heartbeat-availability.mdx index 2f8fdc3a..9ce3f446 100644 --- a/api-reference/heartbeats/get-heartbeat-availability.mdx +++ b/api-reference/heartbeats/get-heartbeat-availability.mdx @@ -1,5 +1,5 @@ --- openapi: get /v1/checks/heartbeats/{checkId}/availability -title: Get heartbeat monitor availability +title: Get Heartbeat monitor availability canonical: 'https://www.checklyhq.com/docs/api-reference/heartbeats/get-heartbeat-availability/' --- \ No newline at end of file diff --git a/api-reference/heartbeats/update-a-heartbeat-check.mdx b/api-reference/heartbeats/update-a-heartbeat-check.mdx index fa6ab84e..a984c17d 100644 --- a/api-reference/heartbeats/update-a-heartbeat-check.mdx +++ b/api-reference/heartbeats/update-a-heartbeat-check.mdx @@ -1,5 +1,5 @@ --- openapi: put /v1/checks/heartbeat/{id} -title: Update a heartbeat monitor +title: Update a Heartbeat monitor canonical: 'https://www.checklyhq.com/docs/api-reference/heartbeats/update-a-heartbeat-check/' --- \ No newline at end of file diff --git a/api-reference/monitors/update-an-icmp-monitor.mdx b/api-reference/monitors/update-an-icmp-monitor.mdx index c1dc0290..9f07192b 100644 --- a/api-reference/monitors/update-an-icmp-monitor.mdx +++ b/api-reference/monitors/update-an-icmp-monitor.mdx @@ -1,5 +1,5 @@ --- openapi: put /v1/checks/icmp/{id} -title: Update an ICMP Monitor +title: Update an ICMP monitor canonical: 'https://www.checklyhq.com/docs/api-reference/monitors/update-an-icmp-monitor/' --- diff --git a/api-reference/usage/overview.mdx b/api-reference/usage/overview.mdx index 9a186607..e4b4d00a 100644 --- a/api-reference/usage/overview.mdx +++ b/api-reference/usage/overview.mdx @@ -59,7 +59,7 @@ Summary returns `totals.creditsUsed`, `breakdown`, and `coverage`. Each series r Zero credits means calculated zero consumption. Null credits means the API cannot calculate the charge, for example because of uncovered dates or unavailable or incompatible pricing. A rule absent from an otherwise configured term contributes zero credits while retaining measured quantities. -Pricing quantities depend on the rule. API and browser checks use runs, Multistep checks use requests, and Playwright suites use metered 30-second intervals. V2 also prices recorded trace conditions, uptime, AI invocations, status pages, SMS, and phone alerts. Included allowances and conditional rates can change billable quantities and prices. +Pricing quantities depend on the rule. API and Browser checks use runs, Multistep checks use requests, and Playwright suites use metered 30-second intervals. V2 also prices recorded trace conditions, uptime, AI invocations, status pages, SMS, and phone alerts. Included allowances and conditional rates can change billable quantities and prices. `include=runs` adds physical check-run counts: `totalRuns`, `finalRuns`, `retryRuns`, `cancelledRuns`, `degradedRuns`, `failedRuns`, `errorRuns`, `abortedRuns`, and `overMaxResponseTimeRuns`. Outcome flags can overlap. These counts are independent of billed quantities. diff --git a/cli/checkly-deploy.mdx b/cli/checkly-deploy.mdx index 1710e580..5c891e60 100644 --- a/cli/checkly-deploy.mdx +++ b/cli/checkly-deploy.mdx @@ -66,7 +66,7 @@ With `--no-plan` the overview has the same markers, but no source file column, n Under the overview, every updated resource gets a header line with its type, logical ID and source file, followed by a diff of the construct as it is in your account against the construct in your code. A legend under the header says what the two sides are: `-` lines are what is live in Checkly, replaced or removed by this deploy; `+` lines are what is in your code, added or changed by this deploy. Everything else is context, and `⋯` marks skipped lines. A `-` line with no `+` line after it is a value your code no longer sets, which the deploy removes. Once the deploy is done, the legend reads `was live in Checkly` and `now live in Checkly` instead. Both sides are rendered the way `checkly import` writes a construct, which leaves out a property whose value is its default. The properties your code spells out are the exception: they are shown on both sides whatever their values, so a move to or from a default reads as a change of that one line. Other constructs are referred to by the names your code gives them. Both need the CLI to find the construct's `new …('id', { … })` call in your code; options passed in a variable or spread into the call keep the import rendering. Facts a diff cannot show are printed as `~` notes: -- The property's path, such as `/script:`, followed by a diff of two texts rather than of the construct, for a change that lives outside it: a browser or multi-step check's script, an API check's setup or teardown script. +- The property's path, such as `/script:`, followed by a diff of two texts rather than of the construct, for a change that lives outside it: a Browser or Multistep check's script, an API check's setup or teardown script. - A property Checkly stores encrypted, such as a locked environment variable, is shown inline with its value masked as `'********'`. The side that changed reads `'******** (changed)'`, or `'******** (changed in Checkly)'` on the deployed side. When the change cannot be shown inline, for example a secret that was renamed, the note `secret changed: ` names the property holding it instead. - `changed: `, such as `changed: code bundle` or `changed: dependency cache, playwright version`, naming every cause in one note, for a change the plan reports by its cause rather than as a property: what the resource bundles or depends on, a setup or teardown snippet, its snapshots, its private locations. - `payload format changed (CLI upgrade)` when the only differences come from a newer CLI describing the same construct differently, such as a private location list or retry strategy being sent in a new form. The deploy rewrites the stored form and nothing about the resource changes. @@ -142,7 +142,7 @@ When the plan shows a resource that was edited in the Checkly web app or through Choosing it writes your account's current values into the construct files and ends the run without deploying, so you can review the result with `git diff` and run `checkly deploy` again. Only what can be written without guessing is written, so a reason found once the file is read (listed below) can still leave nothing to write: -- On every check: `name`, `description`, `activated`, `muted`, `shouldFail`, `tags`, `locations`, `frequency` and `alertEscalationPolicy`; `retryStrategy` on every check except agentic and Playwright checks, which do not take one. Also `degradedResponseTime` and `maxResponseTime` on API checks and URL, TCP, DNS, gRPC, SSL and traceroute monitors; the packet-loss thresholds on ICMP monitors; `period` and `grace` on heartbeat monitors, each written together with its unit; `environmentVariables` and `runtimeId` on API, browser, multistep and Playwright checks (a check that relied on the project-wide runtime gets the value pinned, like any other defaulted property); `intent` on API, browser, multistep and Playwright checks and on URL, TCP, DNS, ICMP and gRPC monitors; `sslCheckDomain` and `aiAutoRepairEnabled` on browser checks and `aiAutoRepairEnabled` on multistep checks; `prompt` on agentic checks (a multi-line prompt written as a template literal stays one); the `request` of an API check (`url`, `method`, `headers`, `queryParameters`, `body`, `bodyType`, `basicAuth`, `followRedirects`, `skipSSL`, `ipFamily`), URL monitor (`url`, `followRedirects`, `skipSSL`, `ipFamily`), TCP monitor (`hostname`, `port`, `data`, `ipFamily`), DNS monitor (`query`, `recordType`, `protocol`, and `nameServer` and `port`, written together), ICMP monitor (`hostname`, `pingCount`, `ipFamily`), gRPC monitor (`url`, `port`, `skipSSL`, `timeout`, `ipFamily` and the `grpcConfig` keys, except `metadata`, whose values Checkly never returns), SSL monitor (`hostname`, `port`, `ipFamily` and the `sslConfig` keys) or traceroute monitor (every key); and the `request.assertions` of an API check and of every URL, TCP, DNS, gRPC, SSL, ICMP and traceroute monitor. Agentic checks take no `shouldFail`. +- On every check: `name`, `description`, `activated`, `muted`, `shouldFail`, `tags`, `locations`, `frequency` and `alertEscalationPolicy`; `retryStrategy` on every check except agentic and Playwright checks, which do not take one. Also `degradedResponseTime` and `maxResponseTime` on API checks and URL, TCP, DNS, gRPC, SSL and Traceroute monitors; the packet-loss thresholds on ICMP monitors; `period` and `grace` on Heartbeat monitors, each written together with its unit; `environmentVariables` and `runtimeId` on API, Browser, Multistep and Playwright checks (a check that relied on the project-wide runtime gets the value pinned, like any other defaulted property); `intent` on API, Browser, Multistep and Playwright checks and on URL, TCP, DNS, ICMP and gRPC monitors; `sslCheckDomain` and `aiAutoRepairEnabled` on Browser checks and `aiAutoRepairEnabled` on Multistep checks; `prompt` on agentic checks (a multi-line prompt written as a template literal stays one); the `request` of an API check (`url`, `method`, `headers`, `queryParameters`, `body`, `bodyType`, `basicAuth`, `followRedirects`, `skipSSL`, `ipFamily`), URL monitor (`url`, `followRedirects`, `skipSSL`, `ipFamily`), TCP monitor (`hostname`, `port`, `data`, `ipFamily`), DNS monitor (`query`, `recordType`, `protocol`, and `nameServer` and `port`, written together), ICMP monitor (`hostname`, `pingCount`, `ipFamily`), gRPC monitor (`url`, `port`, `skipSSL`, `timeout`, `ipFamily` and the `grpcConfig` keys, except `metadata`, whose values Checkly never returns), SSL monitor (`hostname`, `port`, `ipFamily` and the `sslConfig` keys) or Traceroute monitor (every key); and the `request.assertions` of an API check and of every URL, TCP, DNS, gRPC, SSL, ICMP and Traceroute monitor. Agentic checks take no `shouldFail`. - On a check group: `name`, `activated`, `muted`, `tags`, `locations`, `concurrency`, `environmentVariables`, `runtimeId`, `retryStrategy`, `alertEscalationPolicy`, and `apiCheckDefaults` (`url`, `headers`, `queryParameters`, `basicAuth`, `assertions`). - On every alert channel: `sendRecovery`, `sendFailure`, `sendDegraded`, `sslExpiry` and `sslExpiryThreshold`, plus the channel's own properties: `address` on an email channel; `channel` on a Slack channel; `slackChannels` on a Slack app channel; `name`, `webhookType`, `template` and `method` on a webhook channel; `name`, `region` and `priority` on an Opsgenie channel; `account` and `serviceName` on a PagerDuty channel; `phoneNumber` and `name` on an SMS or phone call channel; `name` and `payload` on an MS Teams or incident.io channel; `name` on a Telegram channel. A credential (a webhook or Slack URL, an API key, a service key, a webhook secret, the values of `headers` and `queryParameters`) is never written, since Checkly does not return it; a channel's type, and the webhook type and method the MS Teams, Telegram and incident.io constructs fix, cannot change in the code; Telegram's `chatId`, `messageThreadId`, `payload` and `apiKey` are packed into the message template and URL, which the CLI does not unpack. - On a private location: `name`, `slugName` and `icon` (`proxyUrl` is never written). @@ -481,7 +481,7 @@ When Checkly does not schedule the checks of a deploy that asked for it, the CLI After the deploy, schedule only the checks that run every N minutes or less often. More frequent checks are left out and run at their next scheduled time; they gain little from an extra run right after a deploy. -The frequency is the one Checkly resolves for each check, including its defaults: an SSL or traceroute monitor without an explicit frequency runs every minute, so the default minimum leaves it out. Sub-minute checks count as running more often than every minute. Heartbeat monitors are never scheduled. +The frequency is the one Checkly resolves for each check, including its defaults: an SSL or Traceroute monitor without an explicit frequency runs every minute, so the default minimum leaves it out. Sub-minute checks count as running more often than every minute. Heartbeat monitors are never scheduled. With `auto`, Checkly applies its default minimum of 10 minutes. You can set any whole number up to 1440; a higher value fails the deploy. `0` schedules every check. diff --git a/cli/checkly-destroy.mdx b/cli/checkly-destroy.mdx index ac17941d..3b788b4f 100644 --- a/cli/checkly-destroy.mdx +++ b/cli/checkly-destroy.mdx @@ -92,10 +92,10 @@ The `destroy` command removes the all the resources managed by the specified pro - **Checks** (API, Browser, Heartbeat, etc.) - **Monitors** (URL, TCP, DNC, etc.) -- **Check Groups** and their configurations -- **Alert Channels** defined in your project -- **Maintenance Windows** created via CLI -- **Private Locations** (if managed by the project) +- **Check groups** and their configurations +- **Alert channels** defined in your project +- **Maintenance windows** created via CLI +- **Private locations** (if managed by the project) When run with `--preserve-resources`, only the project itself is deleted. All of the above resources remain in your Checkly account as regular account-level resources and are no longer tracked by the CLI. diff --git a/cli/checkly-runtimes.mdx b/cli/checkly-runtimes.mdx index b1c8dade..e97d5d3d 100644 --- a/cli/checkly-runtimes.mdx +++ b/cli/checkly-runtimes.mdx @@ -102,7 +102,7 @@ When selecting a runtime, consider: - **Package versions** your code depends on - **Node.js features** you're using -- **Playwright compatibility** for browser checks +- **Playwright compatibility** for Browser checks - **Long-term support** for production environments Use the latest runtime for new projects to benefit from the newest features and security updates. diff --git a/cli/checkly-sync-playwright.mdx b/cli/checkly-sync-playwright.mdx index da264bd0..540d743b 100644 --- a/cli/checkly-sync-playwright.mdx +++ b/cli/checkly-sync-playwright.mdx @@ -11,7 +11,7 @@ The `checkly sync-playwright` command synchronizes your Playwright configuration Keeping your configuration in sync ensures consistency between local testing and cloud monitoring environments. -The applied [`playwrightConfig` configuration](/constructs/project#param-checks-playwright-config) is applied to all Browser and MultiStep Checks defined in your Checkly project. +The applied [`playwrightConfig` configuration](/constructs/project#param-checks-playwright-config) is applied to all Browser and Multistep checks defined in your Checkly project. Before using `checkly sync-playwright`, ensure you have: diff --git a/cli/checkly-test.mdx b/cli/checkly-test.mdx index 4adb6506..a27ac393 100644 --- a/cli/checkly-test.mdx +++ b/cli/checkly-test.mdx @@ -396,7 +396,7 @@ npx checkly test --update-snapshots npx checkly test -u ``` -Snapshots are essential for [visual regression testing in Browser Checks](/detect/synthetic-monitoring/browser-checks/visual-regressions). +Snapshots are essential for [visual regression testing in Browser checks](/detect/synthetic-monitoring/browser-checks/visual-regressions). diff --git a/cli/dependencies.mdx b/cli/dependencies.mdx index eddd4b0c..d314a8d8 100644 --- a/cli/dependencies.mdx +++ b/cli/dependencies.mdx @@ -11,14 +11,14 @@ How dependencies work depends on the check type: | Check type | Dependency model | Environment field | |------------|------------------|-------------------| -| Browser Checks and Multistep Checks | Run in a Checkly runtime with fixed Checkly-provided dependencies | `runtimeId` | +| Browser checks and Multistep checks | Run in a Checkly runtime with fixed Checkly-provided dependencies | `runtimeId` | | Playwright Check Suites | Install dependencies from your project files, including `package.json` and your lock file | `engine` | -Use `runtimeId` to choose a custom Checkly runtime for Browser Checks and Multistep Checks. Use `engine` only for Playwright Check Suites, where it overrides the JavaScript engine version that runs your own Playwright project. +Use `runtimeId` to choose a custom Checkly runtime for Browser checks and Multistep checks. Use `engine` only for Playwright Check Suites, where it overrides the JavaScript engine version that runs your own Playwright project. ## npm packages -### Browser, Multistep, and API Checks +### Browser, Multistep, and API checks Not all npm packages are available in a Checkly runtime. @@ -53,7 +53,7 @@ This is useful for defining helper functions to be reused across multiple checks The Checkly CLI automatically detects these dependencies and bundles them with the check. No additional configuration is needed. -Here is a [Browser Check](/detect/synthetic-monitoring/browser-checks/overview) example of how this works in practice. +Here is a [Browser check](/detect/synthetic-monitoring/browser-checks/overview) example of how this works in practice. The directory tree looks like the following: @@ -64,7 +64,7 @@ __checks__ └── login-helper.ts ``` -`login-helper.ts` defines a function `gitHubLogin` that can be used by multiple Browser Checks. +`login-helper.ts` defines a function `gitHubLogin` that can be used by multiple Browser checks. ```ts login-helper.ts export async function gitHubLogin (page, username, password) { diff --git a/cli/environment-variables.mdx b/cli/environment-variables.mdx index 7640cb31..4d503d57 100644 --- a/cli/environment-variables.mdx +++ b/cli/environment-variables.mdx @@ -1,7 +1,7 @@ --- -title: 'Environment Variables' +title: 'Environment variables' description: 'Learn how to use environment variables in your Checkly project' -sidebarTitle: 'Environment Variables' +sidebarTitle: 'Environment variables' canonical: 'https://www.checklyhq.com/docs/cli/environment-variables/' --- @@ -16,7 +16,7 @@ To get a quick overview of when to use which, checkout this video 👇 -## Local Environment Variables +## Local environment variables Local environment variables exist on your local machine, your CI environment, or anywhere you run the Checkly CLI. They normally are part of your shell session or stored in a `.env` file in your app's Git repo. Here is what you need to @@ -29,7 +29,7 @@ Use local environment variables to inject or replace values in your `Check`, `Al **build time** when the CLI compiles your constructs for testing and deploying. Here is an example of setting up an `SmsAlertChannel` where we pass in the actual phone number from a local environment -variable. Note the exclamation mark `!` at the end. This is to tell the Typescript compiler the value will be set. +variable. Note the exclamation mark `!` at the end. This is to tell the TypeScript compiler the value will be set. Alternatively you can use a string template. ```ts Alert-Channel.check.ts @@ -51,7 +51,7 @@ PHONE_NUMBER=0987654321 npx checkly deploy The above command will replace `process.env.PHONE_NUMBER` with the actual `PHONE_NUMBER` you prepended and then create that SMS channel in your Checkly account. -## Remote Environment Variables +## Remote environment variables Checkly also stores environment variables in your Checkly account. These can exist at [the Global, Group or Check level](/platform/variables). Here is what you need to remember: @@ -139,7 +139,7 @@ npx checkly test --env-file="./.env" You can also pull in the variables from your account and store them in a file using [the `npx checkly env pull` command](/cli/checkly-env#pull). See the examples below. -### Managing Remote Environment Variables +### Managing remote environment variables Manage your remote environment variables with the CLI using the [`checkly env` command](/cli/checkly-env). You can list, add, update, remove and export your global variables. @@ -166,7 +166,7 @@ Reference that file in your `test` command. [See the full reference documentation for the `checkly env` command](/cli/checkly-env). -## Securing Environment Variables +## Securing environment variables For storing and securing environment variables, we advise the following: diff --git a/cli/importing.mdx b/cli/importing.mdx index b005c3c2..c62325d8 100644 --- a/cli/importing.mdx +++ b/cli/importing.mdx @@ -17,7 +17,7 @@ To ensure that you can go through this process safely, and test your setup along - `npx checkly import commit`: Commits the plan, removing the **pending** state from all imported resources. Imported resources can now be deleted through the CLI by removing their constructs. At this point the `import` is completed and cannot be canceled. -Playwright check suites are never part of an import plan, whether you import everything or [name a single check by id](#importing-individual-resources): a suite is defined by the code bundle the CLI uploaded on deploy, and an import cannot turn that bundle back into source files. Naming one reports that no importable resources were found. To manage a suite from a new project, deploy it again from the Playwright project that holds its source. +Playwright Check Suites are never part of an import plan, whether you import everything or [name a single check by id](#importing-individual-resources): a suite is defined by the code bundle the CLI uploaded on deploy, and an import cannot turn that bundle back into source files. Naming one reports that no importable resources were found. To manage a suite from a new project, deploy it again from the Playwright project that holds its source. ## Importing step-by-step diff --git a/cli/overview.mdx b/cli/overview.mdx index f92bbb19..a413a84a 100644 --- a/cli/overview.mdx +++ b/cli/overview.mdx @@ -54,7 +54,7 @@ Lastly, you deploy your Checks and related alert channels to Checkly, so we run npx checkly deploy ``` -You just created your entire synthetic monitoring setup with API and Playwright-based Browser Checks from your code base! +You just created your entire synthetic monitoring setup with API and Playwright-based Browser checks from your code base! Open up [your Checkly dashboard](https://app.checklyhq.com) and you should see your check, ready to start monitoring around the clock. For a custom installation check out [our installation docs](/cli/installation/). @@ -62,7 +62,7 @@ For a custom installation check out [our installation docs](/cli/installation/). ## Using Agents, AI IDEs and Copilots Checkly is designed to work with Agents, AI IDEs, and Copilots. You can use your preferred provider to generate code for API -Checks, Browser Checks and all other constructs. +checks, Browser checks and all other constructs. diff --git a/communicate/alerts/channels.mdx b/communicate/alerts/channels.mdx index 2a53e247..415a33cb 100644 --- a/communicate/alerts/channels.mdx +++ b/communicate/alerts/channels.mdx @@ -1,5 +1,5 @@ --- -title: 'Alert Channels' +title: 'Alert channels' description: 'Configure notification channels to receive alerts when checks fail, degrade, or recover. Choose from email, Slack, webhooks, PagerDuty, SMS, and custom integrations.' sidebarTitle: 'Channels' canonical: 'https://www.checklyhq.com/docs/communicate/alerts/channels/' @@ -9,7 +9,7 @@ import AlertChannelSecrets from '/snippets/alert-channel-secrets-callout.mdx'; Alert channels determine **how** alert notifications reach your team when checks fail, degrade, or recover. Checkly supports a wide range of notification methods to fit your team's communication preferences and operational workflows. -## Available Alert Channels +## Available alert channels ### Communication Platforms - [Email](/integrations/alerts/email) @@ -35,7 +35,7 @@ Alert channels determine **how** alert notifications reach your team when checks ### Custom Integrations - [Webhooks](/integrations/alerts/webhooks) -## Managing Alert Channels +## Managing alert channels ### Channel Configuration Overview @@ -44,7 +44,7 @@ Configure channels with flexible subscription and filtering options: ![Alert channels management interface](/images/docs/images/alerting/alert-channels.png) - + Choose your notification method and provide connection details diff --git a/communicate/alerts/notification-log.mdx b/communicate/alerts/notification-log.mdx index 4651fe97..2c690904 100644 --- a/communicate/alerts/notification-log.mdx +++ b/communicate/alerts/notification-log.mdx @@ -19,9 +19,9 @@ Here's an example: In the above example, we see: 1. SMS and Email were correctly delivered. -2. The OpsGenie notification failed though. The notification result shows we got a `422` status code back and the error +2. The Opsgenie notification failed though. The notification result shows we got a `422` status code back and the error message states our API key was invalid. -3. We also see the configuration used to instrument our call to the OpsGenie API. +3. We also see the configuration used to instrument our call to the Opsgenie API. 4. We see some extra meta data about the notification: What channel was used, what check triggered the alert, when it was sent etc. diff --git a/communicate/alerts/overview.mdx b/communicate/alerts/overview.mdx index 8df725c7..9737c03a 100644 --- a/communicate/alerts/overview.mdx +++ b/communicate/alerts/overview.mdx @@ -42,7 +42,7 @@ You can select whether group settings will override individual check settings fo ![alert settings check / threshold alerting](/images/docs/images/alerting/alert-settings-check.png) -## Alert Channels +## Alert channels When adding an alert channel, you can select which checks to subscribe to the channel. This way you can create specific routings for specific checks. diff --git a/communicate/alerts/ssl-expiration.mdx b/communicate/alerts/ssl-expiration.mdx index 9e7b7fcf..d726a433 100644 --- a/communicate/alerts/ssl-expiration.mdx +++ b/communicate/alerts/ssl-expiration.mdx @@ -6,10 +6,10 @@ canonical: 'https://www.checklyhq.com/docs/communicate/alerts/ssl-expiration/' --- An expired SSL certificate can cause havoc to sites and APIs. Checkly performs an hourly check on your certificate and can -alert you up to 30 days before your certificate expires. All alert channels (e-mail, SMS, OpsGenie, Webhook etc.) can be used for this alert. +alert you up to 30 days before your certificate expires. All alert channels (e-mail, SMS, Opsgenie, Webhook etc.) can be used for this alert. Simply create or pick an existing alert channel that your check subscribes to and enable *SSL certificate expiration* and -set the day threshold to your preference. If you don't have your alert channels set up yet, see [Alert Channels](/communicate/alerts/channels). +set the day threshold to your preference. If you don't have your alert channels set up yet, see [alert channels](/communicate/alerts/channels). ![Example alert channel form](/images/docs/images/alerting/ssl_check_example.png) @@ -31,12 +31,12 @@ SSL monitoring cannot parse the domain from a URL like `{{BASE_URL}}/test-endpoi ### Getting `Error: unable to verify the first certificate` If prompted with this error, the usual cause is the certificate chain of the given website being incomplete. This will -not happen with a browser check, because the browser will complete the certificate chain on its own. When running an API check, +not happen with a Browser check, because the browser will complete the certificate chain on its own. When running an API check, though, no browser is involved - therefore the error takes place. You can use an online SSL checker (e.g.: [SSL Shopper](https://www.sslshopper.com/ssl-checker.html)) to help you diagnose issues with your certificate. ## Browser checks -Since browser checks can connect to multiple domains, you need to set the SSL certificate domain to receive certificate alerts for them. +Since Browser checks can connect to multiple domains, you need to set the SSL certificate domain to receive certificate alerts for them. When you change this setting or update your SSL cert, allow up to an hour for the SSL expiration date to update on Checkly’s end. diff --git a/communicate/dashboards/configuration.mdx b/communicate/dashboards/configuration.mdx index e8679693..1fd008f0 100644 --- a/communicate/dashboards/configuration.mdx +++ b/communicate/dashboards/configuration.mdx @@ -1,5 +1,5 @@ --- -title: 'Dashboard Configuration' +title: 'Dashboard configuration' description: "Add checks to your dashboard, control who has access, and customize your dashboard's look and feel." sidebarTitle: 'Configuration' canonical: 'https://www.checklyhq.com/docs/communicate/dashboards/configuration/' @@ -18,7 +18,7 @@ canonical: 'https://www.checklyhq.com/docs/communicate/dashboards/configuration/ -## Setting Up Your Dashboard +## Setting up your dashboard @@ -26,7 +26,7 @@ Add relevant tags to all the checks and monitors that you'd like to display on y - + Create a new dashboard and configure basic settings. @@ -146,7 +146,7 @@ To enable authentication on a dashboard: Be careful, **this is the only time you will see this password in plaintext**. We do not store the password in plaintext, so if it is ever lost, you will need to regenerate a new one and inform any users of the new credentials. -### Accessing Private Dashboards +### Accessing private dashboards After enabling password protection for your dashboard, you can continue to visit it via any custom domain you may have enabled, as well as the default `https://[dashboardId].checkly-dashboards.com` domain. The password authentication will work via both channels. @@ -154,7 +154,7 @@ After enabling password protection for your dashboard, you can continue to visit Checkly account login is only available to Enterprise customers. -If visiting via the `https://[dashboardId].checkly-dashboards.com` domain, you can also select "Login with Checkly" and sign in with your existing Checkly account via any of the supported methods (i.e. Google, Github, Username and Password). This is an Enterprise-only feature. +If visiting via the `https://[dashboardId].checkly-dashboards.com` domain, you can also select "Login with Checkly" and sign in with your existing Checkly account via any of the supported methods (i.e. Google, GitHub, Username and Password). This is an Enterprise-only feature. ## Look and Feel diff --git a/communicate/dashboards/custom-css.mdx b/communicate/dashboards/custom-css.mdx index 609429ba..bbab25b4 100644 --- a/communicate/dashboards/custom-css.mdx +++ b/communicate/dashboards/custom-css.mdx @@ -1,5 +1,5 @@ --- -title: 'Customizing Your Dashboard with CSS' +title: 'Customizing your dashboard with CSS' description: "Match a Checkly dashboard to your company branding with custom CSS rules, edited directly in the Look & Feel section of the dashboard settings." sidebarTitle: 'Custom CSS' canonical: 'https://www.checklyhq.com/docs/communicate/dashboards/custom-css/' diff --git a/communicate/dashboards/overview.mdx b/communicate/dashboards/overview.mdx index 6fbd6fd0..3de998db 100644 --- a/communicate/dashboards/overview.mdx +++ b/communicate/dashboards/overview.mdx @@ -1,5 +1,5 @@ --- -title: 'Dashboards Overview' +title: 'Dashboards overview' description: 'Use dashboards to instantly communicate the health and performance of your checks.' sidebarTitle: 'Overview' canonical: 'https://www.checklyhq.com/docs/communicate/dashboards/overview/' diff --git a/communicate/maintenance-windows/overview.mdx b/communicate/maintenance-windows/overview.mdx index 4bc26814..c79d71d2 100644 --- a/communicate/maintenance-windows/overview.mdx +++ b/communicate/maintenance-windows/overview.mdx @@ -1,7 +1,7 @@ --- -title: 'Maintenance Windows' +title: 'Maintenance windows' description: 'Schedule planned maintenance periods to prevent false alerts and control check behavior during downtime.' -sidebarTitle: 'Maintenance Windows' +sidebarTitle: 'Maintenance windows' canonical: 'https://www.checklyhq.com/docs/communicate/maintenance-windows/overview/' --- diff --git a/communicate/overview.mdx b/communicate/overview.mdx index 20afae43..8e4198f1 100644 --- a/communicate/overview.mdx +++ b/communicate/overview.mdx @@ -12,7 +12,7 @@ canonical: 'https://www.checklyhq.com/docs/communicate/overview/' Receive instant notifications when issues are detected across multiple channels - + Keep users informed with public status pages and incident communication @@ -20,7 +20,7 @@ Keep users informed with public status pages and incident communication Create custom views of your monitoring data for teams and stakeholders - + Schedule and communicate planned maintenance to reduce alert noise @@ -28,34 +28,34 @@ Schedule and communicate planned maintenance to reduce alert noise - **Multi-Channel Alerting** — Send notifications through email, SMS, Slack, webhooks, and more to ensure critical issues reach the right people. - **Transparent Status Communication** — Build trust with users through branded status pages that provide real-time system status and incident updates. -- **Customizable Dashboards** — Create tailored views of monitoring data that match your team's workflow and stakeholder needs. +- **Customizable dashboards** — Create tailored views of monitoring data that match your team's workflow and stakeholder needs. - **Intelligent Alert Management** — Reduce alert fatigue with escalation policies, maintenance windows, and smart notification routing. ## How It Works - + Set up notification channels for your team: - Add email, SMS, and phone call recipients - Connect Slack, Microsoft Teams, and other integrations - Configure webhooks for custom notification systems - + Build public-facing status communication: - Design branded status pages for your services - Configure automatic status updates from monitoring - Set up subscriber notifications for incidents - + Create visibility for stakeholders: - Design dashboards for different audiences - Configure custom domains and branding - Share monitoring insights with teams and customers - + Plan and communicate scheduled maintenance: - Schedule maintenance windows to suppress alerts - Automatically update status pages during maintenance @@ -72,15 +72,15 @@ Ready to start communicating monitoring insights? Choose the approach that best Begin with instant notifications for critical issues - + Build transparency with public status communication - + Create custom views for monitoring data - + Plan and communicate scheduled maintenance diff --git a/communicate/status-pages/creating-a-status-page.mdx b/communicate/status-pages/creating-a-status-page.mdx index 45aecfa0..4c427a52 100644 --- a/communicate/status-pages/creating-a-status-page.mdx +++ b/communicate/status-pages/creating-a-status-page.mdx @@ -1,7 +1,7 @@ --- -title: 'Creating a Status Page' -description: 'Create a Status Page.' -sidebarTitle: 'Creating a Status Page' +title: 'Creating a status page' +description: 'Create a status page.' +sidebarTitle: 'Creating a status page' canonical: 'https://www.checklyhq.com/docs/communicate/status-pages/creating-a-status-page/' --- diff --git a/communicate/status-pages/custom-domain.mdx b/communicate/status-pages/custom-domain.mdx index 7456b779..d8a15f21 100644 --- a/communicate/status-pages/custom-domain.mdx +++ b/communicate/status-pages/custom-domain.mdx @@ -13,7 +13,7 @@ You can host your status page on your own domain. To set it up, add the domain i - + ![Custom domain configuration](/images/docs/images/status-pages/status-pages-custom-domain-1.png) @@ -30,10 +30,10 @@ You can host your status page on your own domain. To set it up, add the domain i After you've added your custom domain and saved the page, one or more TXT records will be displayed depending on the domain you're using. ![Example custom domain TXT configuration](/images/docs/images/status-pages/status-pages-custom-domain-3.png) -Update your DNS settings to match the TXT record(s) displayed on your Status Page to prove the ownership of the domain. +Update your DNS settings to match the TXT record(s) displayed on your status page to prove the ownership of the domain. -Search engines require this verification to index and list your Status Page. +Search engines require this verification to index and list your status page. diff --git a/communicate/status-pages/customization.mdx b/communicate/status-pages/customization.mdx index 4066169c..8965c5be 100644 --- a/communicate/status-pages/customization.mdx +++ b/communicate/status-pages/customization.mdx @@ -1,5 +1,5 @@ --- -title: "Status Page Customization" +title: "Status page customization" description: "Change the logo, favicon, theme, and colors of your status page to match your brand." sidebarTitle: "Customization" canonical: 'https://www.checklyhq.com/docs/communicate/status-pages/customization/' diff --git a/communicate/status-pages/incidents.mdx b/communicate/status-pages/incidents.mdx index 023c0b23..aa82e160 100644 --- a/communicate/status-pages/incidents.mdx +++ b/communicate/status-pages/incidents.mdx @@ -7,19 +7,19 @@ canonical: 'https://www.checklyhq.com/docs/communicate/status-pages/incidents/' Incidents communicate downtime on one or more components. You can open incidents manually as part of your incident management process, or automatically with [automation rules](#incident-automation). -When an incident is posted, a notification will be sent to all users subscribed to the Status Page, unless you opt out of notifications when creating the incident update. +When an incident is posted, a notification will be sent to all users subscribed to the status page, unless you opt out of notifications when creating the incident update. ## Creating an incident -Create an incident when you want to communicate downtime or known issues to users via your Status Page. +Create an incident when you want to communicate downtime or known issues to users via your status page. -1. Click ‘Status pages’ in the sidebar and open your Status Page. +1. Click ‘Status pages’ in the sidebar and open your status page. 2. Click ‘Add incident’ at the top right. 3. Enter the name of the incident. 4. Select which components are impacted, and the [impact](/communicate/status-pages/overview#component-status-and-impacts) each one gets: under maintenance, degraded performance, partial outage, or major outage. 5. Write the initial incident update message, and set the status of the incident. 6. If you want to backfill the incident, select `Use custom date`. See [Backfilling incidents for more information](/communicate/status-pages/incidents#backfilling-an-incident). -7. Select if you want to notify subscribers of your Status Page about the incident. +7. Select if you want to notify subscribers of your status page about the incident. 8. Click ‘Create incident’ The incident now appears on your status page, and the impacted components show their new status. If you selected the option to notify subscribers, they receive the update message by email. @@ -52,7 +52,7 @@ You can correct the record after the fact by editing a component's impact timeli ## Incident notifications -Whenever you post an incident update, Checkly can automatically send email notifications to users subscribed to your Status Page. +Whenever you post an incident update, Checkly can automatically send email notifications to users subscribed to your status page. Emails are sent out only when an update is first posted. Notifications are not sent again if the incident update is edited. @@ -65,7 +65,7 @@ Incident notifications contain the incident name and status, and the impacted co ## Subscribing to incident notifications -Subscribing to incident notifications is done on your Status Page. To subscribe, a user needs to enter a valid email address. A verification email will be sent to the registered email, and the user will be ready to receive incident notifications after confirming the subscription. +Subscribing to incident notifications is done on your status page. To subscribe, a user needs to enter a valid email address. A verification email will be sent to the registered email, and the user will be ready to receive incident notifications after confirming the subscription. ## Incident automation @@ -77,7 +77,7 @@ Automation rules open incidents automatically when checks fail. A rule matches c To create an automation rule: -1. Open your Status Page and go to the ‘Automation’ tab. +1. Open your status page and go to the ‘Automation’ tab. 2. Click ‘Add rule’ and name the rule. 3. Add one or more tags. Any check or group carrying one of these tags can trigger the rule. 4. Select the components the incident should impact, and the impact each one gets. diff --git a/communicate/status-pages/maintenance-windows.mdx b/communicate/status-pages/maintenance-windows.mdx index 6cb46122..7d1c1653 100644 --- a/communicate/status-pages/maintenance-windows.mdx +++ b/communicate/status-pages/maintenance-windows.mdx @@ -1,5 +1,5 @@ --- -title: 'Status Page Maintenance' +title: 'Status page maintenance' description: 'Show planned maintenance windows on your status page so visitors and subscribers know what to expect, with automatic updates and subscriber notifications.' sidebarTitle: 'Maintenance' canonical: 'https://www.checklyhq.com/docs/communicate/status-pages/maintenance-windows/' @@ -26,7 +26,7 @@ You configure status page visibility from the maintenance window itself. Go to the **Maintenance Windows** page (the wrench icon in the sidebar) and create a window, or open an existing one. Set its schedule and [check behavior](/communicate/maintenance-windows/overview#check-behavior) as usual. - + In the **Status page visibility** section, turn on the toggle. This is the master switch for everything below it. diff --git a/communicate/status-pages/overview.mdx b/communicate/status-pages/overview.mdx index 9a9a524f..124ffe07 100644 --- a/communicate/status-pages/overview.mdx +++ b/communicate/status-pages/overview.mdx @@ -1,5 +1,5 @@ --- -title: 'Status Pages Overview' +title: 'Status pages overview' description: 'Create status pages to communicate service health, incidents, and maintenance to your customers, with automated incidents and custom branding.' sidebarTitle: 'Overview' canonical: 'https://www.checklyhq.com/docs/communicate/status-pages/overview/' diff --git a/communicate/status-pages/password-protection.mdx b/communicate/status-pages/password-protection.mdx index 87c20ae4..f15e311e 100644 --- a/communicate/status-pages/password-protection.mdx +++ b/communicate/status-pages/password-protection.mdx @@ -13,7 +13,7 @@ Password protection makes your status page private. Visitors must authenticate b ## Enabling password protection -1. Open your status page from the [Status Pages overview](https://app.checklyhq.com/status-pages). +1. Open your status page from the [Status pages overview](https://app.checklyhq.com/status-pages). 2. In the status page settings, enable the **Private** toggle. 3. A password is automatically generated. Copy it and store it somewhere safe — it is only displayed once. 4. Save your status page. diff --git a/communicate/status-pages/subscriber-notifications.mdx b/communicate/status-pages/subscriber-notifications.mdx index c9b809c7..ffaa7e9d 100644 --- a/communicate/status-pages/subscriber-notifications.mdx +++ b/communicate/status-pages/subscriber-notifications.mdx @@ -6,11 +6,11 @@ canonical: 'https://www.checklyhq.com/docs/communicate/status-pages/subscriber-n --- ## Subscribing to incident updates -Users can choose to be notified about any incident impacting your components by subscribing through your Status Page. +Users can choose to be notified about any incident impacting your components by subscribing through your status page. -To subscribe to notifications, users click the "Get updates" button at the top of the Status Page, and then fill out a form to enter their email address. +To subscribe to notifications, users click the "Get updates" button at the top of the status page, and then fill out a form to enter their email address. diff --git a/communicate/status-pages/v2-deprecated.mdx b/communicate/status-pages/v2-deprecated.mdx index 6c5c1feb..ecfea400 100644 --- a/communicate/status-pages/v2-deprecated.mdx +++ b/communicate/status-pages/v2-deprecated.mdx @@ -1,5 +1,5 @@ --- -title: 'Status Pages v2 (deprecated)' +title: 'Status pages v2 (deprecated)' description: 'Documentation for the deprecated cards-and-services status pages.' sidebarTitle: 'v2 (deprecated)' canonical: 'https://www.checklyhq.com/docs/communicate/status-pages/v2-deprecated/' diff --git a/comparisons/frameworks/moving-from-puppeteer-to-playwright.mdx b/comparisons/frameworks/moving-from-puppeteer-to-playwright.mdx index 7141b927..199b345d 100644 --- a/comparisons/frameworks/moving-from-puppeteer-to-playwright.mdx +++ b/comparisons/frameworks/moving-from-puppeteer-to-playwright.mdx @@ -290,9 +290,9 @@ You can use the [Playwright Test Generator](https://playwright.dev/docs/codegen) ![page being inspected with playwright codegen](/images/guides/images/guides-migration-playwright-codegen.png "Script recording with Playwright Inspector") -## Switching to Playwright for richer browser check results +## Switching to Playwright for richer Browser check results -Checkly browser checks run on Playwright, and their results come with [tracing and Web Vitals](/detect/synthetic-monitoring/browser-checks/performance-metrics) and make it easier to isolate the root cause of a failed check and remediate faster. +Checkly Browser checks run on Playwright, and their results come with [tracing and Web Vitals](/detect/synthetic-monitoring/browser-checks/performance-metrics) and make it easier to isolate the root cause of a failed check and remediate faster. ![performance and error tracing check results on checkly](/images/docs/images/browser-checks/tracing_web_vitals.png "A browser check result with performance and error tracing") @@ -312,7 +312,7 @@ This reveals additional information about the check execution, including: - Learn end-to-end monitoring with puppeteer and playwright to test key website flows. + Learn end-to-end monitoring with puppeteer and Playwright to test key website flows. diff --git a/comparisons/frameworks/playwright-vs-cypress.mdx b/comparisons/frameworks/playwright-vs-cypress.mdx index af18ba62..6328a67d 100644 --- a/comparisons/frameworks/playwright-vs-cypress.mdx +++ b/comparisons/frameworks/playwright-vs-cypress.mdx @@ -41,7 +41,7 @@ Playwright is a tool focused on developer productivity with more robust built-in With Cypress, E2E went from the painful world of hard-coded waits and heavy-handed POM approaches to built in actionability and visibility checks with a focus on community building and developer experience. What we’ve seen over the course of the last five years or so is a cultural shift in the testing world from a heavy reliance on Manual QA and non-developer owned testing responsibilities to testing as a more fully incorporated practice. We’ve shifted left. -We’ve also seen testing become the battleground of where your developer velocity goes to die. Since the inception of playwright more and more teams contain dedicated roles for platform engineering, with a focus on making development, testing, and the [deployment process](/concepts/monitoring-as-code) easier for everyone. +We’ve also seen testing become the battleground of where your developer velocity goes to die. Since the inception of Playwright more and more teams contain dedicated roles for platform engineering, with a focus on making development, testing, and the [deployment process](/concepts/monitoring-as-code) easier for everyone. Titles have changed, entire departments have been lost to restructures, responsibilities have adjusted and solutions that were groundbreaking less than a decade ago are now no longer cutting edge. diff --git a/comparisons/status-pages/overview.mdx b/comparisons/status-pages/overview.mdx index 63f27dc7..7ce61e0e 100644 --- a/comparisons/status-pages/overview.mdx +++ b/comparisons/status-pages/overview.mdx @@ -1,10 +1,10 @@ --- -title: "Status Pages Overview" +title: "Status pages overview" description: "Compare Checkly status pages with other status page solutions" canonical: 'https://www.checklyhq.com/docs/comparisons/status-pages/overview/' --- -# Status Pages Overview +# Status pages overview This section provides detailed comparisons between Checkly's status page functionality and dedicated status page providers. Learn how to choose the right status page solution for your needs. @@ -23,7 +23,7 @@ Coming soon - detailed comparisons with popular status page services including: - Incident.io - Instatus -## Why Compare Status Pages? +## Why compare status pages? Understanding different status page solutions helps you: diff --git a/concepts/checks.mdx b/concepts/checks.mdx index 05531562..b1b772eb 100644 --- a/concepts/checks.mdx +++ b/concepts/checks.mdx @@ -15,8 +15,8 @@ This lets you catch issues early, maintain confidence in your deployments, and e Checkly's flexible offering includes several types of Checks, each designed for different levels of complexity and testing scenarios: - -Monitor HTTP/HTTPS endpoints for availability and performance. URL Monitors check if your websites and APIs are responding correctly by making HTTP requests and validating the response. + +Monitor HTTP/HTTPS endpoints for availability and performance. URL monitors check if your websites and APIs are responding correctly by making HTTP requests and validating the response. **Perfect for:** - Website uptime monitoring @@ -24,8 +24,8 @@ Monitor HTTP/HTTPS endpoints for availability and performance. URL Monitors chec - Basic performance tracking - SSL certificate monitoring - -Verify connectivity to any TCP service by establishing connections to specific hosts and ports. TCP Monitors test the availability of non-HTTP services and infrastructure components. + +Verify connectivity to any TCP service by establishing connections to specific hosts and ports. TCP monitors test the availability of non-HTTP services and infrastructure components. **Perfect for:** - Database connectivity @@ -33,8 +33,8 @@ Verify connectivity to any TCP service by establishing connections to specific h - Network service availability - Port accessibility testing - -Monitor scheduled processes, cron jobs, and batch operations that should "check in" at regular intervals. Instead of actively testing your service, Heartbeat Monitors wait to receive a signal from your system. + +Monitor scheduled processes, cron jobs, and batch operations that should "check in" at regular intervals. Instead of actively testing your service, Heartbeat monitors wait to receive a signal from your system. **Perfect for:** - Backup job verification @@ -42,8 +42,8 @@ Monitor scheduled processes, cron jobs, and batch operations that should "check - Batch process oversight - Data pipeline health - -Verify DNS resolution by querying domain records and validating responses. DNS Monitors help ensure your domains resolve correctly and detect issues such as misconfigurations, propagation delays, or resolver failures. + +Verify DNS resolution by querying domain records and validating responses. DNS monitors help ensure your domains resolve correctly and detect issues such as misconfigurations, propagation delays, or resolver failures. **Perfect for:** - Domain resolution monitoring @@ -51,7 +51,7 @@ Verify DNS resolution by querying domain records and validating responses. DNS M - Detecting propagation issues - Troubleshooting resolver performance - + Ping hosts to measure network reachability and latency. ICMP monitors help you verify that a server or device is online and understand network-level performance. **Perfect for:** @@ -61,7 +61,7 @@ Ping hosts to measure network reachability and latency. ICMP monitors help you v - + Advanced API testing that goes beyond uptime monitoring. Use setup and teardown scripts, complex assertions, and custom request handling. Validate that your backend services respond correctly, perform within acceptable timeframes, and return the right data structures. **Perfect for:** @@ -73,7 +73,7 @@ Advanced API testing that goes beyond uptime monitoring. Use setup and teardown - Integration testing between services - + Write Node.js scripts that run multiple API requests in sequence with arbitrary code between requests. Perfect for testing complex workflows involving authentication, data manipulation, and multi-step processes that span multiple endpoints. **Perfect for:** @@ -84,8 +84,8 @@ Write Node.js scripts that run multiple API requests in sequence with arbitrary - Workflow orchestration testing - Cross-service data validation - -Simulate real user interactions in a headless browser using TypeScript/JavaScript with @playwright/test. Navigate, screenshot, and assert your key webapp flows. Browser Checks can handle complex scenarios that simple uptime monitoring cannot. + +Simulate real user interactions in a headless browser using TypeScript/JavaScript with @playwright/test. Navigate, screenshot, and assert your key webapp flows. Browser checks can handle complex scenarios that simple uptime monitoring cannot. **Perfect for:** - Complete user journey testing diff --git a/concepts/locations.mdx b/concepts/locations.mdx index 71c670e5..8a685b5c 100644 --- a/concepts/locations.mdx +++ b/concepts/locations.mdx @@ -1,6 +1,6 @@ --- title: 'Locations' -description: 'Learn about Public and Private locations using Checkly' +description: 'Learn about public and private locations using Checkly' sidebarTitle: 'Locations' canonical: 'https://www.checklyhq.com/docs/concepts/locations/' --- @@ -36,9 +36,9 @@ Current Locations in Checkly are: Bahrain (me-south-1) is no longer available. Checks don't run there, even if it's still selected. -## Private Locations +## Private locations -**Private Locations** extend this concept to your own infrastructure. A **Private Location** is a monitoring location that you manage by simply deploying a lightweight Checkly Agent. Running a check from a **Private Location** allows you to monitor internal systems and test the performance and reliability of applications and APIs that are only accessible from within your network. +**Private locations** extend this concept to your own infrastructure. A **private location** is a monitoring location that you manage by simply deploying a lightweight Checkly Agent. Running a check from a **private location** allows you to monitor internal systems and test the performance and reliability of applications and APIs that are only accessible from within your network. > Learn more about [private locations](/platform/private-locations/overview) to monitor your private and segregated applications and APIs. ## Locations as User Experience Proxies diff --git a/constructs/alert-channel.mdx b/constructs/alert-channel.mdx index 1a1ae890..cfafcbae 100644 --- a/constructs/alert-channel.mdx +++ b/constructs/alert-channel.mdx @@ -1,5 +1,5 @@ --- -title: 'Alert Channel Overview' +title: 'Alert channel overview' description: 'Learn how to configure alert channels with the Checkly CLI.' sidebarTitle: 'Overview' canonical: 'https://www.checklyhq.com/docs/constructs/alert-channel/' diff --git a/constructs/api-check.mdx b/constructs/api-check.mdx index 18ac4fa2..beb95dd7 100644 --- a/constructs/api-check.mdx +++ b/constructs/api-check.mdx @@ -1,20 +1,20 @@ --- -title: 'API Check Construct' -description: 'Learn how to configure API Checks with the Checkly CLI.' -sidebarTitle: 'API Check' +title: 'API check construct' +description: 'Learn how to configure API checks with the Checkly CLI.' +sidebarTitle: 'API check' canonical: 'https://www.checklyhq.com/docs/constructs/api-check/' --- import CheckIntent from '/snippets/check-intent.mdx'; -Learn more about API Checks in [the API Checks overview](/detect/synthetic-monitoring/api-checks/overview). +Learn more about API checks in [the API checks overview](/detect/synthetic-monitoring/api-checks/overview). -Use API Checks to monitor HTTP endpoints, REST APIs, GraphQL APIs, and other HTTP-based services. The examples below show how to configure monitoring for different types of API endpoints. +Use API checks to monitor HTTP endpoints, REST APIs, GraphQL APIs, and other HTTP-based services. The examples below show how to configure monitoring for different types of API endpoints. -Before creating API Checks, ensure you have: +Before creating API checks, ensure you have: - An initialized Checkly CLI project - URLs or HTTP endpoints you want to monitor @@ -75,10 +75,10 @@ new ApiCheck("advanced-api-check", { ## Configuration -The API Check configuration consists of specific API Check options and inherited general check options. +The API check configuration consists of specific API check options and inherited general check options. - + | Parameter | Type | Required | Default | Description | |-----------|------|----------|---------|-------------| @@ -86,8 +86,8 @@ The API Check configuration consists of specific API Check options and inherited | `degradedResponseTime` | `number` | ❌ | `10000` | Response time threshold in milliseconds for degraded status | | `maxResponseTime` | `number` | ❌ | `20000` | Maximum response time in milliseconds before marking as failed | | `shouldFail` | `boolean` | ❌ | `false` | Whether a failure should count as a pass (status 400+ reported as passed) | -| `setupScript` | `object` | ❌ | - | Script to run before the API Check execution | -| `tearDownScript` | `object` | ❌ | - | Script to run after the API Check execution | +| `setupScript` | `object` | ❌ | - | Script to run before the API check execution | +| `tearDownScript` | `object` | ❌ | - | Script to run after the API check execution | @@ -105,7 +105,7 @@ The API Check configuration consists of specific API Check options and inherited | `group` | `CheckGroup` | ❌ | - | The CheckGroup this check belongs to | | `locations` | `string[]` | ❌ | `[]` | Array of public location codes | | `muted` | `boolean` | ❌ | `false` | Whether alert notifications are muted | -| `privateLocations` | `string[]` | ❌ | `[]` | Array of Private Location slugs | +| `privateLocations` | `string[]` | ❌ | `[]` | Array of private location slugs | | `retryStrategy` | `RetryStrategy` | ❌ | [`singleRetry()`](/constructs/retry-strategy#default-retry-strategy) | Strategy for configuring retries | | `runtimeId` | `string` | ❌ | - | The ID of the runtime to use | | `runParallel` | `boolean` | ❌ | `false` | Run checks in parallel or round-robin | @@ -119,7 +119,7 @@ The API Check configuration consists of specific API Check options and inherited ### `ApiCheck` Options -The HTTP request configuration that defines the API endpoint to monitor. This is the core component of any API Check. +The HTTP request configuration that defines the API endpoint to monitor. This is the core component of any API check. **Usage:** @@ -318,7 +318,7 @@ new ApiCheck("rate-limit-test", { -Script to run before the API Check execution. Useful for setting up test data or authentication tokens. +Script to run before the API check execution. Useful for setting up test data or authentication tokens. **Usage:** @@ -371,7 +371,7 @@ You must provide either `entrypoint` or `content`, but not both. -Script to run after the API Check execution. Useful for cleaning up test data or resources. +Script to run after the API check execution. Useful for cleaning up test data or resources. **Usage:** diff --git a/constructs/browser-check.mdx b/constructs/browser-check.mdx index 4af95d93..8aa7af1a 100644 --- a/constructs/browser-check.mdx +++ b/constructs/browser-check.mdx @@ -1,20 +1,20 @@ --- -title: 'Browser Check Construct' -description: 'Learn how to configure browser checks with the Checkly CLI.' -sidebarTitle: 'Browser Check' +title: 'Browser check construct' +description: 'Learn how to configure Browser checks with the Checkly CLI.' +sidebarTitle: 'Browser check' canonical: 'https://www.checklyhq.com/docs/constructs/browser-check/' --- import CheckIntent from '/snippets/check-intent.mdx'; -Learn more about Browser Checks in [the Browser Checks overview](/detect/synthetic-monitoring/browser-checks/overview). +Learn more about Browser checks in [the Browser checks overview](/detect/synthetic-monitoring/browser-checks/overview). -Use Browser Checks to run end-to-end tests with Playwright. The examples below show how to configure browser checks for different testing scenarios. +Use Browser checks to run end-to-end tests with Playwright. The examples below show how to configure Browser checks for different testing scenarios. -Before creating Browser Checks, ensure you have: +Before creating Browser checks, ensure you have: - An initialized Checkly CLI project - A public website you want to monitor @@ -67,10 +67,10 @@ new BrowserCheck("advanced-browser-check", { ## Configuration -The Browser Check configuration consists of specific Browser Check options and inherited general check options. +The Browser check configuration consists of specific Browser check options and inherited general check options. - + | Parameter | Type | Required | Default | Description | |-----------|------|----------|---------|-------------| @@ -93,7 +93,7 @@ The Browser Check configuration consists of specific Browser Check options and i | `group` | `CheckGroup` | ❌ | - | The CheckGroup this check belongs to | | `locations` | `string[]` | ❌ | `[]` | Public locations for this monitor/check | | `muted` | `boolean` | ❌ | `false` | Whether alert notifications are muted | -| `privateLocations` | `string[]` | ❌ | `[]` | Private Location slugs | +| `privateLocations` | `string[]` | ❌ | `[]` | Private location slugs | | `retryStrategy` | `RetryStrategy` | ❌ | [`singleRetry()`](/constructs/retry-strategy#default-retry-strategy) | Strategy for configured retries | | `runtimeId` | `string` | ❌ | - | The ID of the runtime to use | | `runParallel` | `boolean` | ❌ | `false` | Whether to run checks in parallel across locations | @@ -104,10 +104,10 @@ The Browser Check configuration consists of specific Browser Check options and i -### Browser Check Options +### Browser check options -The Playwright test code that defines how to execute your end-to-end browser monitor. This is the core component of any browser check. +The Playwright test code that defines how to execute your end-to-end browser monitor. This is the core component of any Browser check. **Usage:** @@ -194,7 +194,7 @@ new BrowserCheck("e2e-purchase", { ### General Check Options -Friendly name for your Browser Check that will be displayed in the Checkly dashboard and used in notifications. +Friendly name for your Browser check that will be displayed in the Checkly dashboard and used in notifications. **Usage:** @@ -208,7 +208,7 @@ new BrowserCheck("my-check", { -How often the Browser Check should run. Use the `Frequency` enum to set the check interval. +How often the Browser check should run. Use the `Frequency` enum to set the check interval. **Usage:** @@ -253,9 +253,9 @@ new BrowserCheck("standard-check", { -The Checkly runtime version used to execute the Browser Check. Runtimes are managed execution environments for Browser and Multistep Checks. They include fixed Checkly-provided dependencies, such as Playwright, browser binaries, and runtime libraries. +The Checkly runtime version used to execute the Browser check. Runtimes are managed execution environments for Browser and Multistep checks. They include fixed Checkly-provided dependencies, such as Playwright, browser binaries, and runtime libraries. -Use `runtimeId` for Browser Checks and Multistep Checks. For Playwright Check Suites, use [`engine`](/constructs/playwright-check#engine) instead to select the JavaScript engine version that runs your own Playwright project. +Use `runtimeId` for Browser checks and Multistep checks. For Playwright Check Suites, use [`engine`](/constructs/playwright-check#engine) instead to select the JavaScript engine version that runs your own Playwright project. **Usage:** @@ -272,7 +272,7 @@ new BrowserCheck("my-check", { -Array of public location codes where the Browser Check should run. Multiple locations provide geographic coverage and redundancy. +Array of public location codes where the Browser check should run. Multiple locations provide geographic coverage and redundancy. **Usage:** @@ -318,7 +318,7 @@ new BrowserCheck("europe-check", { -Whether the browser check is enabled and will run according to its schedule. +Whether the Browser check is enabled and will run according to its schedule. **Usage:** @@ -334,7 +334,7 @@ new BrowserCheck("my-check", { -Array of tags to organize and categorize your Browser Checks in the Checkly infrastructure. +Array of tags to organize and categorize your Browser checks in the Checkly infrastructure. **Usage:** diff --git a/constructs/check-group-v2.mdx b/constructs/check-group-v2.mdx index 9eb56e5f..59c7fc57 100644 --- a/constructs/check-group-v2.mdx +++ b/constructs/check-group-v2.mdx @@ -1,12 +1,12 @@ --- title: 'CheckGroupV2 Construct' description: 'Learn how to configure check groups with the Checkly CLI.' -sidebarTitle: 'Check Group V2' +sidebarTitle: 'Check group V2' canonical: 'https://www.checklyhq.com/docs/constructs/check-group-v2/' --- -Learn more about Check Groups in [the Groups overview](/platform/groups). +Learn more about check groups in [the Groups overview](/platform/groups). Use `CheckGroupV2` to organize your checks into logical groups. This provides better organization, shared configuration, and group-level controls for your monitoring setup. @@ -92,13 +92,13 @@ new ApiCheck("api-check-1", { | `localTearDownScript` (deprecated) | `string` | ❌ | - | Code to run after each check/monitor in this group | | `locations` | `string[]` | ❌ | - | Public locations for all checks in the group | | `muted` | `boolean` | ❌ | `false` | Whether alert notifications are muted | -| `privateLocations` | `string[]` | ❌ | - | Private Location slugs | +| `privateLocations` | `string[]` | ❌ | - | Private location slugs | | `retryStrategy` | `RetryStrategy` | ❌ | - | Strategy for configured retries. Without one, each check uses its own. | | `runtimeId` | `string` | ❌ | - | Runtime ID for all checks in the group | | `runParallel` | `boolean` | ❌ | - | Whether to run checks in parallel across locations | | `tags` | `string[]` | ❌ | `[]` | Tags to organize all checks in the group | -| `browserChecks` | `object` | ❌ | - | Settings for Browser Checks in the group | -| `multiStepChecks` | `object` | ❌ | - | Settings for Multistep Checks in the group | +| `browserChecks` | `object` | ❌ | - | Settings for Browser checks in the group | +| `multiStepChecks` | `object` | ❌ | - | Settings for Multistep checks in the group | If you want the group's alert settings to override check-level alert settings, you must set the [`alertEscalationPolicy`](/constructs/check-group-v2#param-alert-escalation-policy). Otherwise, the alert settings of individual checks will be used, even if `alertChannels` is defined in your group. @@ -153,7 +153,7 @@ const group = new CheckGroupV2("api-monitoring-group", { -How often to run checks within the group. Checks in your project that don't set their own frequency use this value. For Browser and Multistep Checks, the group's `browserChecks.frequency` or `multiStepChecks.frequency`, and then the same settings under `checks` in your project config, take precedence. It isn't stored on the group, so checks added to the group outside your project don't use it. +How often to run checks within the group. Checks in your project that don't set their own frequency use this value. For Browser and Multistep checks, the group's `browserChecks.frequency` or `multiStepChecks.frequency`, and then the same settings under `checks` in your project config, take precedence. It isn't stored on the group, so checks added to the group outside your project don't use it. **Usage:** @@ -168,7 +168,7 @@ const group = new CheckGroupV2('api-monitoring-group', { **Available frequencies**: `EVERY_10S`, `EVERY_20S`, `EVERY_30S`, `EVERY_1M`, `EVERY_2M`, `EVERY_5M`, `EVERY_10M`, `EVERY_15M`, `EVERY_30M`, `EVERY_1H`, `EVERY_2H`, `EVERY_3H`, `EVERY_6H`, `EVERY_12H`, `EVERY_24H` -Generally, Check Groups support all available frequencies, but if a group includes a check type that doesn't support high frequencies, `npx checkly deploy` will fail. We recommend separating high-frequency ones into their own groups. +Generally, check groups support all available frequencies, but if a group includes a check type that doesn't support high frequencies, `npx checkly deploy` will fail. We recommend separating high-frequency ones into their own groups. @@ -188,7 +188,7 @@ const group = new CheckGroupV2("api-monitoring-group", { -Setting to automatically create and apply Browser Checks to a group. +Setting to automatically create and apply Browser checks to a group. **Usage:** @@ -206,7 +206,7 @@ const group = new CheckGroupV2("api-monitoring-group", { -Setting to automatically create and apply MultiStep Checks to a group. +Setting to automatically create and apply Multistep checks to a group. **Usage:** diff --git a/constructs/check-group.mdx b/constructs/check-group.mdx index 8dc2a81d..fb7463c8 100644 --- a/constructs/check-group.mdx +++ b/constructs/check-group.mdx @@ -1,12 +1,12 @@ --- title: 'CheckGroup Construct' description: 'Learn how to configure check groups with the Checkly CLI.' -sidebarTitle: 'Check Group (deprecated)' +sidebarTitle: 'Check group (deprecated)' canonical: 'https://www.checklyhq.com/docs/constructs/check-group/' --- -Learn more about Check Groups in [the Groups overview](/platform/groups). +Learn more about check groups in [the Groups overview](/platform/groups). `CheckGroup` is deprecated. Please use `CheckGroupV2` instead. See [CheckGroupV2 documentation](/constructs/check-group-v2) for details. @@ -97,13 +97,13 @@ new ApiCheck("api-check-1", { | `localTearDownScript` (deprecated) | `string` | ❌ | - | Code to run after each check/monitor in this group | | `locations` | `string[]` | ❌ | - | Public locations for all checks in the group | | `muted` | `boolean` | ❌ | `false` | Whether alert notifications are muted | -| `privateLocations` | `string[]` | ❌ | - | Private Location slugs | +| `privateLocations` | `string[]` | ❌ | - | Private location slugs | | `retryStrategy` | `RetryStrategy` | ❌ | [`singleRetry()`](/constructs/retry-strategy#default-retry-strategy) | Strategy for configured retries | | `runtimeId` | `string` | ❌ | - | Runtime ID for all checks in the group | | `runParallel` | `boolean` | ❌ | - | Whether to run checks in parallel across locations | | `tags` | `string[]` | ❌ | `[]` | Tags to organize all checks in the group | -| `browserChecks` | `object` | ❌ | - | Settings for Browser Checks in the group | -| `multistepChecks` | `object` | ❌ | - | Settings for Multistep Checks in the group | +| `browserChecks` | `object` | ❌ | - | Settings for Browser checks in the group | +| `multistepChecks` | `object` | ❌ | - | Settings for Multistep checks in the group | ### Group Options @@ -169,7 +169,7 @@ const group = new CheckGroup("api-monitoring-group", { **Available frequencies**: `EVERY_10S`, `EVERY_20S`, `EVERY_30S`, `EVERY_1M`, `EVERY_2M`, `EVERY_5M`, `EVERY_10M`, `EVERY_15M`, `EVERY_30M`, `EVERY_1H`, `EVERY_2H`, `EVERY_6H`, `EVERY_12H`, `EVERY_24H` -Generally, Check Groups support all available frequencies, but if a group includes a check type that doesn't support high frequencies, `npx checkly deploy` will fail. We recommend separating high-frequency ones into their own groups. +Generally, check groups support all available frequencies, but if a group includes a check type that doesn't support high frequencies, `npx checkly deploy` will fail. We recommend separating high-frequency ones into their own groups. @@ -189,7 +189,7 @@ const group = new CheckGroup("api-monitoring-group", { -Setting to automatically create and apply Browser Checks to a group. +Setting to automatically create and apply Browser checks to a group. **Usage:** @@ -207,7 +207,7 @@ const group = new CheckGroup("api-monitoring-group", { -Setting to automatically create and apply MultiStep Checks to a group. +Setting to automatically create and apply Multistep checks to a group. **Usage:** diff --git a/constructs/dashboard.mdx b/constructs/dashboard.mdx index 2642f1bb..e5e6e0ca 100644 --- a/constructs/dashboard.mdx +++ b/constructs/dashboard.mdx @@ -6,7 +6,7 @@ canonical: 'https://www.checklyhq.com/docs/constructs/dashboard/' --- -Learn more about Dashboards in [the Dashboards overview](/communicate/dashboards/overview). +Learn more about dashboards in [the dashboards overview](/communicate/dashboards/overview). Use Dashboard to create public or private dashboards that display checks and their related metrics on a single page. Dashboards provide a centralized view of your monitoring data. @@ -253,7 +253,7 @@ You must provide either `entrypoint` or `content`, but not both. ``` - + ```ts new Dashboard("api-dashboard", { header: "API Endpoints Status", @@ -269,7 +269,7 @@ You must provide either `entrypoint` or `content`, but not both. ``` - + ```ts new Dashboard("us-east-dashboard", { header: "US East Region Status", @@ -285,7 +285,7 @@ You must provide either `entrypoint` or `content`, but not both. ``` - + ```ts new Dashboard("platform-team-dashboard", { header: "Platform Team Services", @@ -302,7 +302,7 @@ You must provide either `entrypoint` or `content`, but not both. ``` - + ```ts new Dashboard("branded-dashboard", { header: "ACME Corporation Status", diff --git a/constructs/dns-monitor.mdx b/constructs/dns-monitor.mdx index 375c7d56..bb789cb8 100644 --- a/constructs/dns-monitor.mdx +++ b/constructs/dns-monitor.mdx @@ -1,7 +1,7 @@ --- title: 'DnsMonitor Construct' description: 'Learn how to configure DNS monitors with the Checkly CLI.' -sidebarTitle: 'DNS Monitor' +sidebarTitle: 'DNS monitor' canonical: 'https://www.checklyhq.com/docs/constructs/dns-monitor/' --- @@ -10,13 +10,13 @@ import CheckIntent from '/snippets/check-intent.mdx'; import GeneralMonitorOptionsTable from '/snippets/general-monitor-options-table.mdx'; -Learn more about DNS Monitors in [the DNS monitor overview](/detect/uptime-monitoring/dns-monitors/overview). +Learn more about DNS monitors in [the DNS monitor overview](/detect/uptime-monitoring/dns-monitors/overview). -Use DNS Monitors to verify that DNS records resolve correctly and to track lookup performance over time. +Use DNS monitors to verify that DNS records resolve correctly and to track lookup performance over time. -Before creating DNS Monitors, ensure you have: +Before creating DNS monitors, ensure you have: - An initialized Checkly CLI project - A domain or hostname you want to monitor @@ -79,10 +79,10 @@ new DnsMonitor("advanced-dns-monitor", { ## Configuration -A DNS Monitor has its own DNS-specific settings, plus the standard monitor options shared across all check types. +A DNS monitor has its own DNS-specific settings, plus the standard monitor options shared across all check types. - + | Parameter | Type | Required | Default | Description | |-----------|------|----------|---------|-------------| @@ -134,7 +134,7 @@ new DnsMonitor("dns-monitor", { -Response time threshold in milliseconds for marking the DNS Monitor as degraded (warning state). +Response time threshold in milliseconds for marking the DNS monitor as degraded (warning state). **Usage:** @@ -154,7 +154,7 @@ new DnsMonitor("dns-performance-tiers", { -Maximum response time in milliseconds before the DNS Monitor is marked as failed. +Maximum response time in milliseconds before the DNS monitor is marked as failed. **Usage:** @@ -210,7 +210,7 @@ Learn more in our docs on [Assertions](/detect/assertions). ### General Monitor Options -Friendly name for your DNS Monitor that will be displayed in the Checkly dashboard and used in notifications. +Friendly name for your DNS monitor that will be displayed in the Checkly dashboard and used in notifications. **Usage:** @@ -224,7 +224,7 @@ new DnsMonitor("my-monitor", { -How often the DNS Monitor should run. Use the `Frequency` enum to set the check interval. +How often the DNS monitor should run. Use the `Frequency` enum to set the check interval. **Usage:** @@ -239,7 +239,7 @@ new DnsMonitor("my-monitor", { -Array of [public location codes](/concepts/locations/#public-locations) where the DNS Monitor should run from. Multiple locations provide geographic coverage and help detect regional DNS issues. +Array of [public location codes](/concepts/locations/#public-locations) where the DNS monitor should run from. Multiple locations provide geographic coverage and help detect regional DNS issues. **Usage:** @@ -251,7 +251,7 @@ new DnsMonitor("global-dns-monitor", { -Whether the DNS Monitor is enabled and will run according to its schedule. +Whether the DNS monitor is enabled and will run according to its schedule. **Usage:** diff --git a/constructs/email-alert-channel.mdx b/constructs/email-alert-channel.mdx index 64c5a0d1..3a1d1ba0 100644 --- a/constructs/email-alert-channel.mdx +++ b/constructs/email-alert-channel.mdx @@ -11,7 +11,7 @@ import AlertChannelOptionsText from '/snippets/alert-channel-options-text.mdx'; For general information about alerting, see our docs on [email alerts](/integrations/alerts/email) and [alerting with Checkly](/communicate/alerts/overview/). -Use Email Alert Channels to send email notifications when checks fail or recover. +Use Email alert channels to send email notifications when checks fail or recover. @@ -44,12 +44,12 @@ const emailChannel = new EmailAlertChannel("ops-email-channel", { ## Configuration -### Email Alert Channel Options +### Email alert channel options Email address to send notifications to. To notify multiple recipients from one `EmailAlertChannel`, pass a comma-separated list of email addresses. -### General Alert Channel Options +### General alert channel options diff --git a/constructs/grpc-monitor.mdx b/constructs/grpc-monitor.mdx index c1c18b28..4a160f27 100644 --- a/constructs/grpc-monitor.mdx +++ b/constructs/grpc-monitor.mdx @@ -1,7 +1,7 @@ --- title: 'GrpcMonitor Construct' description: 'Learn how to configure gRPC monitors with the Checkly CLI.' -sidebarTitle: 'gRPC Monitor' +sidebarTitle: 'gRPC monitor' canonical: 'https://www.checklyhq.com/docs/constructs/grpc-monitor/' --- @@ -10,16 +10,16 @@ import CheckIntent from '/snippets/check-intent.mdx'; import GeneralMonitorOptionsTable from '/snippets/general-monitor-options-table.mdx'; -Learn more about gRPC Monitors in [the gRPC monitor overview](/detect/uptime-monitoring/grpc-monitors/overview). +Learn more about gRPC monitors in [the gRPC monitor overview](/detect/uptime-monitoring/grpc-monitors/overview). -Use gRPC Monitors to verify that your gRPC services are reachable, responding correctly, and meeting performance expectations. Monitors run in two modes: +Use gRPC monitors to verify that your gRPC services are reachable, responding correctly, and meeting performance expectations. Monitors run in two modes: - **BEHAVIOR** — Invokes a unary gRPC method and asserts on the response - **HEALTH** — Queries the standard `grpc.health.v1.Health/Check` endpoint -Before creating gRPC Monitors, ensure you have: +Before creating gRPC monitors, ensure you have: - An initialized Checkly CLI project - The hostname and port of the gRPC service you want to monitor @@ -91,7 +91,7 @@ new GrpcMonitor('grpc-behavior-1', { gRPC monitors have their own gRPC-specific settings, plus the standard monitor options shared across all check types. - + | Parameter | Type | Required | Default | Description | |-----------|------|----------|---------|-------------| @@ -263,7 +263,7 @@ Learn more in our docs on [Assertions](/detect/assertions). ### General Monitor Options -Friendly name for your gRPC Monitor displayed in the Checkly dashboard and used in notifications. +Friendly name for your gRPC monitor displayed in the Checkly dashboard and used in notifications. **Usage:** @@ -277,7 +277,7 @@ new GrpcMonitor('my-grpc-monitor', { -How often the gRPC Monitor should run. Use the `Frequency` enum to set the check interval. +How often the gRPC monitor should run. Use the `Frequency` enum to set the check interval. **Usage:** @@ -293,7 +293,7 @@ new GrpcMonitor('my-grpc-monitor', { -Array of [public location codes](/concepts/locations/#public-locations) where the gRPC Monitor runs from. Multiple locations provide geographic coverage. +Array of [public location codes](/concepts/locations/#public-locations) where the gRPC monitor runs from. Multiple locations provide geographic coverage. **Usage:** @@ -308,7 +308,7 @@ new GrpcMonitor('global-grpc-monitor', { -Whether the gRPC Monitor is enabled and will run according to its schedule. +Whether the gRPC monitor is enabled and will run according to its schedule. **Usage:** diff --git a/constructs/heartbeat-monitor.mdx b/constructs/heartbeat-monitor.mdx index 8d380d0a..9f689d61 100644 --- a/constructs/heartbeat-monitor.mdx +++ b/constructs/heartbeat-monitor.mdx @@ -1,7 +1,7 @@ --- -title: 'Heartbeat Monitor Construct' -description: 'Learn how to configure heartbeat monitors with the Checkly CLI.' -sidebarTitle: 'Heartbeat Monitor' +title: 'Heartbeat monitor construct' +description: 'Learn how to configure Heartbeat monitors with the Checkly CLI.' +sidebarTitle: 'Heartbeat monitor' canonical: 'https://www.checklyhq.com/docs/constructs/heartbeat-monitor/' --- @@ -9,10 +9,10 @@ canonical: 'https://www.checklyhq.com/docs/constructs/heartbeat-monitor/' Learn more about Heartbeat monitors in [the Heartbeat monitor overview](/detect/uptime-monitoring/heartbeat-monitors/overview). -Use Heartbeat Monitors to track passive monitoring scenarios where external services ping Checkly at regular intervals. The examples below show how to configure monitoring for different types of scheduled jobs and services. +Use Heartbeat monitors to track passive monitoring scenarios where external services ping Checkly at regular intervals. The examples below show how to configure monitoring for different types of scheduled jobs and services. -Before creating heartbeat monitors, ensure you have: +Before creating Heartbeat monitors, ensure you have: - An initialized Checkly CLI project - External services, cron jobs, or scripts that can send HTTP POST requests @@ -69,7 +69,7 @@ new HeartbeatMonitor("newsletter-heartbeat", { The Heartbeat Monitoring configuration consists of specific heartbeat monitoring options and inherited general monitoring options. - + | Parameter | Type | Required | Default | Description | |-----------|------|----------|---------|-------------| @@ -260,7 +260,7 @@ new HeartbeatMonitor('my-heartbeat', { ### General Monitor Options -Friendly name for your heartbeat monitor that will be displayed in the Checkly dashboard and used in notifications. +Friendly name for your Heartbeat monitor that will be displayed in the Checkly dashboard and used in notifications. **Usage:** @@ -391,7 +391,7 @@ new HeartbeatMonitor('my-heartbeat', { ## Getting the heartbeat Ping URL -After deploying your heartbeat monitor, you can obtain the ping URL in several ways: +After deploying your Heartbeat monitor, you can obtain the ping URL in several ways: @@ -404,12 +404,12 @@ After deploying your heartbeat monitor, you can obtain the ping URL in several w - Navigate to your heartbeat monitor in the [Checkly web UI](https://app.checklyhq.com/heartbeats) to copy the ping URL. + Navigate to your Heartbeat monitor in the [Checkly web UI](https://app.checklyhq.com/heartbeats) to copy the ping URL. -The ping URL is unique for each heartbeat monitor and should be kept secure. Anyone with access to this URL can send pings to your monitor. +The ping URL is unique for each Heartbeat monitor and should be kept secure. Anyone with access to this URL can send pings to your monitor. diff --git a/constructs/icmp-monitor.mdx b/constructs/icmp-monitor.mdx index 1936b2de..c168d495 100644 --- a/constructs/icmp-monitor.mdx +++ b/constructs/icmp-monitor.mdx @@ -1,7 +1,7 @@ --- title: 'IcmpMonitor Construct' description: 'Learn how to configure ICMP monitors with the Checkly CLI.' -sidebarTitle: 'ICMP Monitor' +sidebarTitle: 'ICMP monitor' canonical: 'https://www.checklyhq.com/docs/constructs/icmp-monitor/' --- @@ -10,13 +10,13 @@ import CheckIntent from '/snippets/check-intent.mdx'; import GeneralMonitorOptionsTable from '/snippets/general-monitor-options-table.mdx'; -Learn more about ICMP Monitors in [the ICMP monitor overview](/detect/uptime-monitoring/icmp-monitors/overview). +Learn more about ICMP monitors in [the ICMP monitor overview](/detect/uptime-monitoring/icmp-monitors/overview). ICMP monitors check if a host is reachable by sending ICMP Echo Requests (pings). Use them to monitor network connectivity and latency. -Before creating ICMP Monitors, ensure you have: +Before creating ICMP monitors, ensure you have: - An initialized Checkly CLI project - A hostname or IP address you want to ping @@ -70,7 +70,7 @@ new IcmpMonitor('cloudflare-dns-icmp', { ICMP monitors have their own ICMP-specific settings, plus the standard monitor options shared across all check types. - + | Parameter | Type | Required | Default | Description | |-----------|------|----------|---------|-------------| @@ -184,7 +184,7 @@ Learn more in our docs on [Assertions](/detect/assertions). ### General Monitor Options -Friendly name for your ICMP Monitor that will be displayed in the Checkly dashboard and used in notifications. +Friendly name for your ICMP monitor that will be displayed in the Checkly dashboard and used in notifications. **Usage:** @@ -198,7 +198,7 @@ new IcmpMonitor("my-monitor", { -How often the ICMP Monitor should run. Use the `Frequency` enum to set the check interval. +How often the ICMP monitor should run. Use the `Frequency` enum to set the check interval. **Usage:** @@ -214,7 +214,7 @@ new IcmpMonitor("my-monitor", { -Array of [public location codes](/concepts/locations/#public-locations) where the ICMP Monitor should run from. Multiple locations provide geographic coverage and help detect regional network issues. +Array of [public location codes](/concepts/locations/#public-locations) where the ICMP monitor should run from. Multiple locations provide geographic coverage and help detect regional network issues. **Usage:** @@ -227,7 +227,7 @@ new IcmpMonitor("global-icmp-monitor", { -Whether the ICMP Monitor is enabled and will run according to its schedule. +Whether the ICMP monitor is enabled and will run according to its schedule. **Usage:** diff --git a/constructs/incident-trigger.mdx b/constructs/incident-trigger.mdx index f84d9df6..32ff6cac 100644 --- a/constructs/incident-trigger.mdx +++ b/constructs/incident-trigger.mdx @@ -9,7 +9,7 @@ canonical: 'https://www.checklyhq.com/docs/constructs/incident-trigger/' **Deprecated.** Incident triggers automate incidents on v2 (services-based) status pages. On v3 pages, use [`StatusPageV3AutomationRule`](/constructs/status-page-v3-automation-rule) instead. -Learn more about Status Pages in [the Status Pages overview](/communicate/status-pages/overview). +Learn more about status pages in [the status pages overview](/communicate/status-pages/overview). Use incident triggers to automatically create and resolve an incident and notify subscribers based on the alert configuration of a monitor or check. This allows you to link synthetic monitoring failures directly to incidents on your status pages. diff --git a/constructs/incidentio-alert-channel.mdx b/constructs/incidentio-alert-channel.mdx index fe66ac5e..912288d5 100644 --- a/constructs/incidentio-alert-channel.mdx +++ b/constructs/incidentio-alert-channel.mdx @@ -49,7 +49,7 @@ const incidentioChannel = new IncidentioAlertChannel('incidentio-channel-1', { ## Configuration -### Incident.io Alert Channel Options +### Incident.io alert channel options Friendly name to recognise the integration. @@ -101,7 +101,7 @@ new IncidentioAlertChannel('incidentio-channel-1', { ``` -### General Alert Channel Options +### General alert channel options diff --git a/constructs/including-checks.mdx b/constructs/including-checks.mdx index c082dafa..e80c88ee 100644 --- a/constructs/including-checks.mdx +++ b/constructs/including-checks.mdx @@ -38,14 +38,14 @@ const config = defineConfig({ 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. +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` +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 diff --git a/constructs/maintenance-window.mdx b/constructs/maintenance-window.mdx index 510cfe60..942712fd 100644 --- a/constructs/maintenance-window.mdx +++ b/constructs/maintenance-window.mdx @@ -1,15 +1,15 @@ --- title: 'MaintenanceWindow Construct' description: 'Learn how to configure maintenance windows with the Checkly CLI.' -sidebarTitle: 'Maintenance Window' +sidebarTitle: 'Maintenance window' canonical: 'https://www.checklyhq.com/docs/constructs/maintenance-window/' --- -Learn more about Maintenance Windows in [the Maintenance Windows documentation](/communicate/maintenance-windows/overview). +Learn more about maintenance windows in [the maintenance windows documentation](/communicate/maintenance-windows/overview). -Use Maintenance Windows to schedule planned maintenance periods that prevent your checks from running and triggering alerts during expected downtime. +Use maintenance windows to schedule planned maintenance periods that prevent your checks from running and triggering alerts during expected downtime. diff --git a/constructs/msteams-alert-channel.mdx b/constructs/msteams-alert-channel.mdx index 484b96d3..fd56547d 100644 --- a/constructs/msteams-alert-channel.mdx +++ b/constructs/msteams-alert-channel.mdx @@ -161,7 +161,7 @@ const msTeamsAlertChannel = new MSTeamsAlertChannel('msteams-channel-01', { ## Configuration -### Microsoft Teams Alert Channel Options +### Microsoft Teams alert channel options The target URL created by [creating a Workflow in Microsoft Teams](/integrations/alerts/msteams). @@ -303,6 +303,6 @@ new MSTeamsAlertChannel('msteams-channel-01', { ``` -### General Alert Channel Options +### General alert channel options diff --git a/constructs/multistep-check.mdx b/constructs/multistep-check.mdx index 42f3896c..1b78def2 100644 --- a/constructs/multistep-check.mdx +++ b/constructs/multistep-check.mdx @@ -1,24 +1,24 @@ --- -title: 'Multistep Check Construct' -description: 'Learn how to configure multistep checks with the Checkly CLI.' -sidebarTitle: 'Multistep Check' +title: 'Multistep check construct' +description: 'Learn how to configure Multistep checks with the Checkly CLI.' +sidebarTitle: 'Multistep check' canonical: 'https://www.checklyhq.com/docs/constructs/multistep-check/' --- import CheckIntent from '/snippets/check-intent.mdx'; -Learn more about Multistep Checks in [the Multistep Checks overview](/detect/synthetic-monitoring/multistep-checks/overview). +Learn more about Multistep checks in [the Multistep checks overview](/detect/synthetic-monitoring/multistep-checks/overview). -Use Multistep Checks to run complex end-to-end workflows with Playwright that span multiple endpoints. The examples below show how to configure Multistep Checks for different testing scenarios. +Use Multistep checks to run complex end-to-end workflows with Playwright that span multiple endpoints. The examples below show how to configure Multistep checks for different testing scenarios. -Before creating Multistep Checks, ensure you have: +Before creating Multistep checks, ensure you have: - An initialized Checkly CLI project - Public endpoints you want to monitor -- Runtime `2023.09` or later (Multistep Checks require [newer runtimes](/platform/runtimes/runtime-specification)) +- Runtime `2023.09` or later (Multistep checks require [newer runtimes](/platform/runtimes/runtime-specification)) For additional setup information, see [CLI overview](/cli/overview). @@ -68,7 +68,7 @@ new MultiStepCheck("complex-multistep-check", { ## Configuration - + | Parameter | Type | Required | Default | Description | |-----------|------|----------|---------|-------------| @@ -92,7 +92,7 @@ new MultiStepCheck("complex-multistep-check", { | `locations` | `string[]` | ❌ | `[]` | Array of public location codes | | `muted` | `boolean` | ❌ | `false` | Whether alert notifications are muted | | `runtimeId` | `string` | ❌ | - | The ID of the runtime to use (2023.09 or later required) | -| `privateLocations` | `string[]` | ❌ | `[]` | Array of Private Location slugs | +| `privateLocations` | `string[]` | ❌ | `[]` | Array of private location slugs | | `retryStrategy` | `RetryStrategy` | ❌ | [`singleRetry()`](/constructs/retry-strategy#default-retry-strategy) | Strategy for configuring retries | | `runParallel` | `boolean` | ❌ | `false` | Run checks in parallel or round-robin | | `tags` | `string[]` | ❌ | `[]` | Array of tags to organize checks | @@ -102,10 +102,10 @@ new MultiStepCheck("complex-multistep-check", { -### Multistep Check Options +### Multistep check options -The Playwright test code that defines your Multistep Check monitor. +The Playwright test code that defines your Multistep check monitor. **Usage:** @@ -265,7 +265,7 @@ test("SpaceX-API Dragon Capsules & Next Launch", async ({ request }) => { ### General Check Options -Friendly name for your multistep check that will be displayed in the Checkly dashboard and used in notifications. +Friendly name for your Multistep check that will be displayed in the Checkly dashboard and used in notifications. **Usage:** @@ -278,7 +278,7 @@ new MultiStepCheck("my-multistep", { -The Checkly runtime version used to execute the Multistep Check. Runtimes are managed execution environments for Browser and Multistep Checks. They include fixed Checkly-provided dependencies, such as Playwright, browser binaries, and runtime libraries. +The Checkly runtime version used to execute the Multistep check. Runtimes are managed execution environments for Browser and Multistep checks. They include fixed Checkly-provided dependencies, such as Playwright, browser binaries, and runtime libraries. Multistep checks require runtime `2023.09` or later. @@ -297,7 +297,7 @@ Multistep checks require runtime `2023.09` or later. Earlier runtimes do not sup -How often the multistep check should run. Use the `Frequency` enum to set the check interval. +How often the Multistep check should run. Use the `Frequency` enum to set the check interval. Usage: ```ts highlight={5} @@ -314,7 +314,7 @@ new MultiStepCheck("my-multistep", { -Array of public location codes where the multistep check should run. Multiple locations provide geographic coverage and user experience insights. +Array of public location codes where the Multistep check should run. Multiple locations provide geographic coverage and user experience insights. Usage: ```ts highlight={3} diff --git a/constructs/opsgenie-alert-channel.mdx b/constructs/opsgenie-alert-channel.mdx index 3ab0fa8c..dd13f2b1 100644 --- a/constructs/opsgenie-alert-channel.mdx +++ b/constructs/opsgenie-alert-channel.mdx @@ -51,7 +51,7 @@ const opsGenieChannel = new OpsgenieAlertChannel('opsgenie-channel-1', { ## Configuration -### Opsgenie Alert Channel Options +### Opsgenie alert channel options Friendly name to recognise the integration. @@ -69,6 +69,6 @@ A string representing the severity level, `P1` to `P5`. An API key for your Opsgenie account. -### General Alert Channel Options +### General alert channel options diff --git a/constructs/pagerduty-alert-channel.mdx b/constructs/pagerduty-alert-channel.mdx index 8c3328fb..47150f42 100644 --- a/constructs/pagerduty-alert-channel.mdx +++ b/constructs/pagerduty-alert-channel.mdx @@ -1,7 +1,7 @@ --- title: 'PagerdutyAlertChannel Construct' -description: 'Learn how to configure Pagerduty alert channels with the Checkly CLI.' -sidebarTitle: 'Pagerduty' +description: 'Learn how to configure PagerDuty alert channels with the Checkly CLI.' +sidebarTitle: 'PagerDuty' canonical: 'https://www.checklyhq.com/docs/constructs/pagerduty-alert-channel/' --- @@ -9,10 +9,10 @@ import AlertChannelOptionsText from '/snippets/alert-channel-options-text.mdx'; -For general information about alerting, see our docs on [the Pagerduty integration](/integrations/incident-management/pagerduty) and [alerting with Checkly](/communicate/alerts/overview/). +For general information about alerting, see our docs on [the PagerDuty integration](/integrations/incident-management/pagerduty) and [alerting with Checkly](/communicate/alerts/overview/). -Sends an alert notification to a specific service in your Pagerduty account. +Sends an alert notification to a specific service in your PagerDuty account. @@ -49,20 +49,20 @@ const pagerdutyChannel = new PagerdutyAlertChannel('pagerduty-channel-1', { ## Configuration -### Pagerduty Alert Channel Options +### PagerDuty alert channel options -The name of your Pagerduty account. +The name of your PagerDuty account. -The name of your service defined in Pagerduty under which the alerts should be nested. +The name of your service defined in PagerDuty under which the alerts should be nested. -The API key created by installing the Checkly integration in Pagerduty. We advise you to [install the Pagerduty alert channel first from the UI](https://app.checklyhq.com/alerts/settings/channels/new/pagerduty/) to grab the `serviceKey`. +The API key created by installing the Checkly integration in PagerDuty. We advise you to [install the PagerDuty alert channel first from the UI](https://app.checklyhq.com/alerts/settings/channels/new/pagerduty/) to grab the `serviceKey`. -### General Alert Channel Options +### General alert channel options diff --git a/constructs/phone-call-alert-channel.mdx b/constructs/phone-call-alert-channel.mdx index ea39cdc3..0bc747ba 100644 --- a/constructs/phone-call-alert-channel.mdx +++ b/constructs/phone-call-alert-channel.mdx @@ -45,7 +45,7 @@ const callChannel = new PhoneCallAlertChannel('call-channel-1', { ## Configuration -### Phone Call Alert Channel Options +### Phone call alert channel options Phone number to call. @@ -65,6 +65,6 @@ new PhoneCallAlertChannel('call-channel-1', { Friendly name for the phone call alert channel. -### General Alert Channel Options +### General alert channel options diff --git a/constructs/playwright-check.mdx b/constructs/playwright-check.mdx index 332ccc78..98ce9d7d 100644 --- a/constructs/playwright-check.mdx +++ b/constructs/playwright-check.mdx @@ -1,6 +1,6 @@ --- title: 'Playwright Check Suite' -description: 'Learn how to configure Playwright check suites with the Checkly CLI.' +description: 'Learn how to configure Playwright Check Suites with the Checkly CLI.' sidebarTitle: 'Playwright Check Suites' canonical: 'https://www.checklyhq.com/docs/constructs/playwright-check/' --- @@ -89,7 +89,7 @@ The Playwright Check Suite configuration consists of specific Playwright Check S | `group` | `CheckGroup` | ❌ | - | The CheckGroup this check belongs to | | `locations` | `string[]` | ❌ | `[]` | Array of public location codes | | `muted` | `boolean` | ❌ | `false` | Whether alert notifications are muted | -| `privateLocations` | `string[]` | ❌ | `[]` | Array of Private Location slugs | +| `privateLocations` | `string[]` | ❌ | `[]` | Array of private location slugs | | `runParallel` | `boolean` | ❌ | `false` | Run checks in parallel or round-robin | | `tags` | `string[]` | ❌ | `[]` | Array of tags to organize checks | | `testOnly` | `boolean` | ❌ | `false` | Only run with test, not during deploy | @@ -219,7 +219,7 @@ new PlaywrightCheck("critical-e2e-monitor", { -Defines the glob patterns for files and directories that should be included when bundling the Playwright Check Suite. Use this option to manually include additional test files, helper utilities, or other resources that might be outside of the tests directory that your playwright config file points to. +Defines the glob patterns for files and directories that should be included when bundling the Playwright Check Suite. Use this option to manually include additional test files, helper utilities, or other resources that might be outside of the tests directory that your Playwright config file points to. **Usage:** diff --git a/constructs/private-location.mdx b/constructs/private-location.mdx index 253a2039..c3284a19 100644 --- a/constructs/private-location.mdx +++ b/constructs/private-location.mdx @@ -1,15 +1,15 @@ --- title: 'PrivateLocation Construct' description: 'Learn how to configure private locations with the Checkly CLI.' -sidebarTitle: 'Private Locations' +sidebarTitle: 'Private locations' canonical: 'https://www.checklyhq.com/docs/constructs/private-location/' --- -Learn more about Private Locations in [the Private Locations overview](/platform/private-locations/overview). +Learn more about private locations in [the private locations overview](/platform/private-locations/overview). -Use Private Locations to run checks from your own infrastructure, VPCs, or isolated networks. With a Private Location, you can monitor internal services and applications not accessible from the public internet. +Use private locations to run checks from your own infrastructure, VPCs, or isolated networks. With a private location, you can monitor internal services and applications not accessible from the public internet. Before creating private locations, ensure you have: @@ -67,7 +67,7 @@ new ApiCheck("internal-api-check", { | `icon` | `string` | ❌ | `location` | [Octicon name](https://primer.style/octicons/) to distinguish the location in the UI | | `proxyUrl` | `string` | ❌ | - | Proxy URL for outgoing HTTP calls from this location | -## Private Location Options +## Private location options Friendly name for your private location that will be displayed in the Checkly dashboard and used for identification. diff --git a/constructs/project.mdx b/constructs/project.mdx index c57ca462..1f7ca6aa 100644 --- a/constructs/project.mdx +++ b/constructs/project.mdx @@ -201,8 +201,8 @@ export default defineConfig({ | `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. Only applies to API checks, URL monitors and TCP monitors. | | `tags` | `string[]` | ❌ | `[]` | Default tags applied to all checks | -| `browserChecks` | `object` | ❌ | - | Default settings for browser checks | -| `multiStepChecks` | `object` | ❌ | - | Default settings for multi-step checks | +| `browserChecks` | `object` | ❌ | - | Default settings for Browser checks | +| `multiStepChecks` | `object` | ❌ | - | Default settings for Multistep checks | | `playwrightChecks` | `object` | ❌ | - | Default settings for Playwright Check Suites | @@ -374,7 +374,7 @@ export default defineConfig({ -Global configuration options for the Playwright Test Runner use in [Browser Checks](/detect/synthetic-monitoring/browser-checks/overview) and [MultiStep Checks](/detect/synthetic-monitoring/multistep-checks/overview). 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. +Global configuration options for the Playwright Test Runner use in [Browser checks](/detect/synthetic-monitoring/browser-checks/overview) and [Multistep checks](/detect/synthetic-monitoring/multistep-checks/overview). 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:** @@ -399,9 +399,9 @@ export default defineConfig({ }) ``` -Learn more about the supported Playwright configuration options in [the Browser Check Playwright documentation](/detect/synthetic-monitoring/browser-checks/playwright-support). +Learn more about the supported Playwright configuration options in [the Browser check Playwright documentation](/detect/synthetic-monitoring/browser-checks/playwright-support). -Browser Checks don't support the `projects`, `globalSetup`, `globalTeardown` and `storageState` options. Check [Playwright Check Suites](/detect/synthetic-monitoring/playwright-checks/overview) for full Playwright support. +Browser checks don't support the `projects`, `globalSetup`, `globalTeardown` and `storageState` options. Check [Playwright Check Suites](/detect/synthetic-monitoring/playwright-checks/overview) for full Playwright support. @@ -425,7 +425,7 @@ export default defineConfig({ -Private Locations to run your monitors and checks from. +Private locations to run your monitors and checks from. **Usage:** @@ -446,7 +446,7 @@ export default defineConfig({ }) ``` -Learn more about [Private Locations in the general documentation](/platform/private-locations/overview). +Learn more about [private locations in the general documentation](/platform/private-locations/overview). @@ -516,13 +516,13 @@ export default defineConfig({ -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 `browserChecks.testMatch` property. +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 `browserChecks.testMatch` property. **Properties:** | Parameter | Type | Required | Default | Description | |-----------|------|----------|---------|-------------| -| `testMatch` | `string` | `string[]` | ❌ | - | Glob pattern for Playwright tests uses as Browser Checks | +| `testMatch` | `string` | `string[]` | ❌ | - | Glob pattern for Playwright tests uses as Browser checks | **Example:** @@ -544,13 +544,13 @@ export default defineConfig({ -If your project doesn't require specific configuration and you want to quickly transform your Playwright API tests into Multistep Checks, use the `multiStepChecks.testMatch` property. +If your project doesn't require specific configuration and you want to quickly transform your Playwright API tests into Multistep checks, use the `multiStepChecks.testMatch` property. **Properties:** | Parameter | Type | Required | Default | Description | |-----------|------|----------|---------|-------------| -| `testMatch` | `string` | `string[]` | ❌ | - | Glob pattern for Playwright tests uses as Browser Checks | +| `testMatch` | `string` | `string[]` | ❌ | - | Glob pattern for Playwright tests uses as Browser checks | **Example:** @@ -624,7 +624,7 @@ export default defineConfig({ | `frequency` | `Frequency` | ❌ | - | How often to run your check suite | | `locations` | `string[]` | ❌ | `[]` | Array of public location codes | | `muted` | `boolean` | ❌ | `false` | Whether alert notifications are muted | -| `privateLocations` | `string[]` | ❌ | `[]` | Array of Private Location slugs | +| `privateLocations` | `string[]` | ❌ | `[]` | Array of private location slugs | | `retryStrategy` | `RetryStrategy` | ❌ | - | Strategy for configuring retries | | `runParallel` | `boolean` | ❌ | `false` | Run check suites in parallel or round-robin | | `tags` | `string[]` | ❌ | `[]` | Array of tags to organize check suites | diff --git a/constructs/slack-alert-channel.mdx b/constructs/slack-alert-channel.mdx index 5158ecfd..c87cf061 100644 --- a/constructs/slack-alert-channel.mdx +++ b/constructs/slack-alert-channel.mdx @@ -47,7 +47,7 @@ const slackChannel = new SlackAlertChannel('slack-channel-1', { ## Configuration -### Slack Alert Channel Options +### Slack alert channel options The Slack incoming webhook URL where Checkly will send alert notifications. @@ -64,6 +64,6 @@ new SlackAlertChannel('slack-channel-1', { Target Slack channel or user for notifications. You can specify the target channel to override the default channel configured in the webhook. -### General Alert Channel Options +### General alert channel options diff --git a/constructs/slack-app-alert-channel.mdx b/constructs/slack-app-alert-channel.mdx index b18b7135..b5b58300 100644 --- a/constructs/slack-app-alert-channel.mdx +++ b/constructs/slack-app-alert-channel.mdx @@ -45,7 +45,7 @@ const slackAppChannel = new SlackAppAlertChannel('slack-channel-1', { ## Configuration -### Slack Alert Channel Options +### Slack alert channel options The Slack channels to alert. Can also include DM handles, e.g. "@John Doe" @@ -57,6 +57,6 @@ new SlackAppAlertChannel('slack-channel-1', { ``` -### General Alert Channel Options +### General alert channel options diff --git a/constructs/sms-alert-channel.mdx b/constructs/sms-alert-channel.mdx index 692fd770..3d3ba8ad 100644 --- a/constructs/sms-alert-channel.mdx +++ b/constructs/sms-alert-channel.mdx @@ -11,7 +11,7 @@ import AlertChannelOptionsText from '/snippets/alert-channel-options-text.mdx'; For general information about alerting, see our docs on [SMS alerts](/integrations/alerts/sms) and [alerting with Checkly](/communicate/alerts/overview/). -Use SMS Alert Channels to send SMS notifications to phone numbers when checks fail or recover. +Use SMS alert channels to send SMS notifications to phone numbers when checks fail or recover. @@ -46,7 +46,7 @@ const smsChannel = new SmsAlertChannel('sms-channel-1', { ## Configuration -### SMS Alert Channel Options +### SMS alert channel options Phone number to send SMS notifications to. @@ -67,6 +67,6 @@ new SmsAlertChannel('sms-channel-1', { Friendly name for the SMS alert channel. -### General Alert Channel Options +### General alert channel options diff --git a/constructs/ssl-monitor.mdx b/constructs/ssl-monitor.mdx index 324aa296..84b62167 100644 --- a/constructs/ssl-monitor.mdx +++ b/constructs/ssl-monitor.mdx @@ -1,20 +1,20 @@ --- title: 'SslMonitor Construct' description: 'Learn how to configure SSL monitors with the Checkly CLI.' -sidebarTitle: 'SSL Monitor' +sidebarTitle: 'SSL monitor' canonical: 'https://www.checklyhq.com/docs/constructs/ssl-monitor/' --- import GeneralMonitorOptionsTable from '/snippets/general-monitor-options-table.mdx'; -Learn more about SSL Monitors in [the SSL monitor overview](/detect/uptime-monitoring/ssl-monitors/overview). +Learn more about SSL monitors in [the SSL monitor overview](/detect/uptime-monitoring/ssl-monitors/overview). -Use SSL Monitors to verify the health and security posture of your TLS certificates. The examples below show how to configure monitoring for common scenarios. +Use SSL monitors to verify the health and security posture of your TLS certificates. The examples below show how to configure monitoring for common scenarios. -Before creating SSL Monitors, ensure you have: +Before creating SSL monitors, ensure you have: - An initialized Checkly CLI project - Network access to the HTTPS endpoint you want to monitor @@ -88,7 +88,7 @@ new SslMonitor("api-ssl-advanced", { SSL monitors have SSL-specific settings and inherit the standard monitor options shared across all check types. - + | Parameter | Type | Required | Default | Description | |-----------|------|----------|---------|-------------| @@ -343,7 +343,7 @@ Learn more in our docs on [Assertions](/detect/assertions). ### General Monitor Options -Friendly name for your SSL Monitor, displayed in the Checkly dashboard and used in notifications. +Friendly name for your SSL monitor, displayed in the Checkly dashboard and used in notifications. ```ts highlight={2} new SslMonitor("my-ssl-monitor", { @@ -354,7 +354,7 @@ new SslMonitor("my-ssl-monitor", { -How often the SSL Monitor should run. Use the `Frequency` enum to set the check interval. +How often the SSL monitor should run. Use the `Frequency` enum to set the check interval. ```ts highlight={3} new SslMonitor("my-ssl-monitor", { @@ -380,7 +380,7 @@ new SslMonitor("global-ssl", { -Whether the SSL Monitor is enabled and will run according to its schedule. +Whether the SSL monitor is enabled and will run according to its schedule. ```ts highlight={3} new SslMonitor("my-ssl-monitor", { diff --git a/constructs/status-page-service.mdx b/constructs/status-page-service.mdx index cfc6aafd..cfd3a1b4 100644 --- a/constructs/status-page-service.mdx +++ b/constructs/status-page-service.mdx @@ -1,7 +1,7 @@ --- title: 'StatusPageService Construct' description: 'Learn how to configure status page services with the Checkly CLI.' -sidebarTitle: 'Status Page Service (deprecated)' +sidebarTitle: 'Status page service (deprecated)' canonical: 'https://www.checklyhq.com/docs/constructs/status-page-service/' --- @@ -9,10 +9,10 @@ canonical: 'https://www.checklyhq.com/docs/constructs/status-page-service/' **Deprecated.** Services belong to v2 status pages. On v3 pages, use [`StatusPageV3Component`](/constructs/status-page-v3-component) instead. -Learn more about Status Pages in [the Status Pages overview](/communicate/status-pages/overview). +Learn more about status pages in [the status pages overview](/communicate/status-pages/overview). -Use Status Page Services to allow monitors and checks to trigger incidents and to be displayed on status pages. Services represent individual components or systems that you want to show uptime information for. +Use status page services to allow monitors and checks to trigger incidents and to be displayed on status pages. Services represent individual components or systems that you want to show uptime information for. @@ -80,7 +80,7 @@ new StatusPage("acme-status", { ## Configuration - + | Parameter | Type | Required | Default | Description | |-----------|------|----------|---------|-------------| @@ -266,7 +266,7 @@ new StatusPage("internal-status", { ## Integration with Checks and Monitors -Status Page Services represent logical groupings of functionality. You'll typically have multiple checks monitoring different aspects of each service, but the service itself provides a high-level view for your status page visitors. Enable checks and monitors to trigger incidents by using the `triggerIncident` property. +Status page services represent logical groupings of functionality. You'll typically have multiple checks monitoring different aspects of each service, but the service itself provides a high-level view for your status page visitors. Enable checks and monitors to trigger incidents by using the `triggerIncident` property. ```ts highlight=12,27 import { ApiCheck, StatusPageService, UrlMonitor } from "checkly/constructs" diff --git a/constructs/status-page-v3-automation-rule.mdx b/constructs/status-page-v3-automation-rule.mdx index 8965d73e..6ffe78cd 100644 --- a/constructs/status-page-v3-automation-rule.mdx +++ b/constructs/status-page-v3-automation-rule.mdx @@ -1,7 +1,7 @@ --- title: 'StatusPageV3AutomationRule Construct' description: 'Learn how to automate status page incidents with the Checkly CLI.' -sidebarTitle: 'Status Page Automation Rule' +sidebarTitle: 'Status page automation rule' canonical: 'https://www.checklyhq.com/docs/constructs/status-page-v3-automation-rule/' --- diff --git a/constructs/status-page-v3-component.mdx b/constructs/status-page-v3-component.mdx index 0652a9f1..e441c605 100644 --- a/constructs/status-page-v3-component.mdx +++ b/constructs/status-page-v3-component.mdx @@ -1,7 +1,7 @@ --- title: 'StatusPageV3Component Construct' description: 'Learn how to configure status page components with the Checkly CLI.' -sidebarTitle: 'Status Page Component' +sidebarTitle: 'Status page component' canonical: 'https://www.checklyhq.com/docs/constructs/status-page-v3-component/' --- diff --git a/constructs/status-page-v3.mdx b/constructs/status-page-v3.mdx index 0a01b712..31800144 100644 --- a/constructs/status-page-v3.mdx +++ b/constructs/status-page-v3.mdx @@ -1,7 +1,7 @@ --- title: 'StatusPageV3 Construct' description: 'Learn how to configure status pages with the Checkly CLI.' -sidebarTitle: 'Status Page' +sidebarTitle: 'Status page' canonical: 'https://www.checklyhq.com/docs/constructs/status-page-v3/' --- diff --git a/constructs/status-page.mdx b/constructs/status-page.mdx index 917decd1..26d42560 100644 --- a/constructs/status-page.mdx +++ b/constructs/status-page.mdx @@ -1,7 +1,7 @@ --- title: 'StatusPage Construct' description: 'Learn how to configure status pages with the Checkly CLI.' -sidebarTitle: 'Status Page (deprecated)' +sidebarTitle: 'Status page (deprecated)' canonical: 'https://www.checklyhq.com/docs/constructs/status-page/' --- @@ -9,10 +9,10 @@ canonical: 'https://www.checklyhq.com/docs/constructs/status-page/' **Deprecated.** This construct creates a v2 (cards and services) status page. New status pages should use [`StatusPageV3`](/constructs/status-page-v3). Existing v2 pages keep working and can be migrated to v3 with the migration wizard in the Checkly app. -Learn more about Status Pages in [the Status Pages overview](/communicate/status-pages/overview). +Learn more about status pages in [the status pages overview](/communicate/status-pages/overview). -Use public Status Pages to show the uptime of your services through organized cards. Status pages help communicate service availability to your users and stakeholders. +Use public status pages to show the uptime of your services through organized cards. Status pages help communicate service availability to your users and stakeholders. @@ -80,7 +80,7 @@ new StatusPage("acme-status", { ## Configuration - + | Parameter | Type | Required | Default | Description | |-----------|------|----------|---------|-------------| diff --git a/constructs/tcp-monitor.mdx b/constructs/tcp-monitor.mdx index 03572834..a6ffc666 100644 --- a/constructs/tcp-monitor.mdx +++ b/constructs/tcp-monitor.mdx @@ -1,7 +1,7 @@ --- title: 'TcpMonitor Construct' description: 'Learn how to configure TCP monitors with the Checkly CLI.' -sidebarTitle: 'TCP Monitor' +sidebarTitle: 'TCP monitor' canonical: 'https://www.checklyhq.com/docs/constructs/tcp-monitor/' --- @@ -10,13 +10,13 @@ import CheckIntent from '/snippets/check-intent.mdx'; import GeneralMonitorOptionsTable from '/snippets/general-monitor-options-table.mdx'; -Learn more about TCP Monitors in [the TCP monitor overview](/detect/uptime-monitoring/tcp-monitors/overview). +Learn more about TCP monitors in [the TCP monitor overview](/detect/uptime-monitoring/tcp-monitors/overview). -Use TCP Monitors to verify connectivity and response times of your TCP services. The examples below show how to configure monitoring for different types of services. +Use TCP monitors to verify connectivity and response times of your TCP services. The examples below show how to configure monitoring for different types of services. -Before creating TCP Monitors, ensure you have: +Before creating TCP monitors, ensure you have: - An initialized Checkly CLI project - Network access to the TCP services you want to monitor @@ -78,7 +78,7 @@ new TcpMonitor("redis-tcp-1", { The TCP Monitoring configuration consists of specific TCP monitoring options and inherited general monitoring options. - + | Parameter | Type | Required | Default | Description | |-----------|------|----------|---------|-------------| diff --git a/constructs/telegram-alert-channel.mdx b/constructs/telegram-alert-channel.mdx index 39e17022..53fd349b 100644 --- a/constructs/telegram-alert-channel.mdx +++ b/constructs/telegram-alert-channel.mdx @@ -54,7 +54,7 @@ const telegramChannel = new TelegramAlertChannel('my-telegramchannel-1', { ## Configuration -### Telegram Alert Channel Options +### Telegram alert channel options Friendly name to recognise the integration. @@ -98,6 +98,6 @@ new TelegramAlertChannel('my-telegramchannel-1', { ``` -### General Alert Channel Options +### General alert channel options diff --git a/constructs/traceroute-monitor.mdx b/constructs/traceroute-monitor.mdx index a9ea303b..d7150963 100644 --- a/constructs/traceroute-monitor.mdx +++ b/constructs/traceroute-monitor.mdx @@ -1,20 +1,20 @@ --- title: 'TracerouteMonitor Construct' description: 'Learn how to configure Traceroute monitors with the Checkly CLI.' -sidebarTitle: 'Traceroute Monitor' +sidebarTitle: 'Traceroute monitor' canonical: 'https://www.checklyhq.com/docs/constructs/traceroute-monitor/' --- import GeneralMonitorOptionsTable from '/snippets/general-monitor-options-table.mdx'; -Learn more about Traceroute Monitors in [the Traceroute monitor overview](/detect/uptime-monitoring/traceroute-monitors/overview). +Learn more about Traceroute monitors in [the Traceroute monitor overview](/detect/uptime-monitoring/traceroute-monitors/overview). Traceroute monitors map the network path to a host hop-by-hop, measuring per-hop latency and packet loss, and detecting whether the destination is reached. Use them to monitor path stability and catch routing issues before they affect your users. -Before creating Traceroute Monitors, ensure you have: +Before creating Traceroute monitors, ensure you have: - An initialized Checkly CLI project - A hostname or IP address you want to trace @@ -74,7 +74,7 @@ new TracerouteMonitor('traceroute-db', { Traceroute monitors have their own probe-specific settings, plus the standard monitor options shared across all check types. - + | Parameter | Type | Required | Default | Description | |-----------|------|----------|---------|-------------| @@ -207,7 +207,7 @@ Learn more in our docs on [Assertions](/detect/assertions). ### General Monitor Options -Friendly name for your Traceroute Monitor that will be displayed in the Checkly dashboard and used in notifications. +Friendly name for your Traceroute monitor that will be displayed in the Checkly dashboard and used in notifications. **Usage:** @@ -220,7 +220,7 @@ new TracerouteMonitor("my-traceroute", { -How often the Traceroute Monitor should run. Use the `Frequency` enum to set the check interval. +How often the Traceroute monitor should run. Use the `Frequency` enum to set the check interval. **Usage:** @@ -236,7 +236,7 @@ new TracerouteMonitor("my-traceroute", { -Array of [public location codes](/concepts/locations/#public-locations) where the Traceroute Monitor should run from. Use `privateLocations` for [private locations](/platform/private-locations/overview). Multiple locations help detect regional routing differences. +Array of [public location codes](/concepts/locations/#public-locations) where the Traceroute monitor should run from. Use `privateLocations` for [private locations](/platform/private-locations/overview). Multiple locations help detect regional routing differences. **Usage:** @@ -252,7 +252,7 @@ new TracerouteMonitor("global-path-monitor", { -Whether the Traceroute Monitor is enabled and will run according to its schedule. +Whether the Traceroute monitor is enabled and will run according to its schedule. **Usage:** diff --git a/constructs/url-monitor.mdx b/constructs/url-monitor.mdx index 68b1c780..aed7cd81 100644 --- a/constructs/url-monitor.mdx +++ b/constructs/url-monitor.mdx @@ -1,7 +1,7 @@ --- title: 'UrlMonitor Construct' description: 'Learn how to configure URL monitors with the Checkly CLI.' -sidebarTitle: 'URL Monitor' +sidebarTitle: 'URL monitor' canonical: 'https://www.checklyhq.com/docs/constructs/url-monitor/' --- @@ -10,13 +10,13 @@ import CheckIntent from '/snippets/check-intent.mdx'; import GeneralMonitorOptionsTable from '/snippets/general-monitor-options-table.mdx'; -Learn more about URL Monitors in [the URL monitor overview](/detect/uptime-monitoring/url-monitors/overview). +Learn more about URL monitors in [the URL monitor overview](/detect/uptime-monitoring/url-monitors/overview). -Use URL Monitors to track basic availability and HTTP status codes of your services and websites. The examples below show how to configure monitoring for different types of HTTP endpoints. +Use URL monitors to track basic availability and HTTP status codes of your services and websites. The examples below show how to configure monitoring for different types of HTTP endpoints. -Before creating URL Monitors, ensure you have: +Before creating URL monitors, ensure you have: - An initialized Checkly CLI project - URLs or HTTP endpoints you want to monitor @@ -73,7 +73,7 @@ new UrlMonitor("advanced-url-monitor", { The URL Monitoring configuration consists of specific URL monitoring options and inherited general monitoring options. - + | Parameter | Type | Required | Default | Description | |-----------|------|----------|---------|-------------| diff --git a/constructs/webhook-alert-channel.mdx b/constructs/webhook-alert-channel.mdx index b125c920..a62f4142 100644 --- a/constructs/webhook-alert-channel.mdx +++ b/constructs/webhook-alert-channel.mdx @@ -66,7 +66,7 @@ const webhookChannel = new WebhookAlertChannel('webhook-channel-1', { ## Configuration -### Webhook Alert Channel Options +### Webhook alert channel options Target URL for the webhook request. @@ -140,6 +140,6 @@ new WebhookAlertChannel('webhook-channel-1', { Secret token that you can use to validate the authenticity of the webhook and its payload. [Learn more about webhook secrets.](/integrations/alerts/webhooks#webhook-secrets) -### General Alert Channel Options +### General alert channel options diff --git a/detect/overview.mdx b/detect/overview.mdx index e747ed1b..067c5987 100644 --- a/detect/overview.mdx +++ b/detect/overview.mdx @@ -13,7 +13,7 @@ Monitor availability and response times across your website and infrastructure -Proactively validate real user interactions with API, browser, and multistep checks +Proactively validate real user interactions with API, Browser, and Multistep checks diff --git a/detect/synthetic-monitoring/agentic-checks/migrate.mdx b/detect/synthetic-monitoring/agentic-checks/migrate.mdx index 2cda536e..0d330c98 100644 --- a/detect/synthetic-monitoring/agentic-checks/migrate.mdx +++ b/detect/synthetic-monitoring/agentic-checks/migrate.mdx @@ -1,7 +1,7 @@ --- title: 'Migrate from Agentic Checks' sidebarTitle: 'Migrate Agentic Checks' -description: 'Replace Agentic Checks with Browser or Multistep Checks and enable automatic repair before December 1, 2026.' +description: 'Replace Agentic Checks with Browser or Multistep checks and enable automatic repair before December 1, 2026.' canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/agentic-checks/migrate/' hidden: true --- @@ -10,7 +10,7 @@ hidden: true Agentic Checks are deprecated and will stop running on **December 1, 2026**. Replace each active Agentic Check before that date to keep monitoring its journey. -Create a Browser or Multistep Check for the same journey, verify the replacement, then deactivate the Agentic Check. This guide uses Browser and Multistep Checks because automatic repair can edit their scripts in Checkly. The replacement has its own results and history. +Create a Browser or Multistep check for the same journey, verify the replacement, then deactivate the Agentic Check. This guide uses Browser and Multistep checks because automatic repair can edit their scripts in Checkly. The replacement has its own results and history. You can create the replacement in two ways: @@ -65,7 +65,7 @@ Migrate one journey at a time. If the original prompt covered several unrelated ## Add automatic repair to other checks -You can enable automatic repair on Browser and Multistep Checks you already use. Open a check's **Check intent** settings and select **Initialize from saved check** to get an editable intent suggestion, or enter the intent manually. Review and save the intent, then expand **Automatic Repair** and set **Automatic repair behavior** to **On** and save the check. See [Add intent to an existing check](../../../resolve/automatic-check-repair#add-intent-to-an-existing-check). +You can enable automatic repair on Browser and Multistep checks you already use. Open a check's **Check intent** settings and select **Initialize from saved check** to get an editable intent suggestion, or enter the intent manually. Review and save the intent, then expand **Automatic Repair** and set **Automatic repair behavior** to **On** and save the check. See [Add intent to an existing check](../../../resolve/automatic-check-repair#add-intent-to-an-existing-check). ## AI invocation usage diff --git a/detect/synthetic-monitoring/agentic-checks/overview.mdx b/detect/synthetic-monitoring/agentic-checks/overview.mdx index 5725a2dc..536811ee 100644 --- a/detect/synthetic-monitoring/agentic-checks/overview.mdx +++ b/detect/synthetic-monitoring/agentic-checks/overview.mdx @@ -43,7 +43,7 @@ Agentic Checks were designed for flows where the expected behavior is clear, but - Authentication or onboarding flows that need contextual checks - AI-powered product flows where the monitor should evaluate whether the user goal was completed, not whether the output matched exact text - Pages where you want the monitor to adapt when implementation details change -- Early monitoring coverage before you invest in a hand-written Browser Check or Playwright Check Suite +- Early monitoring coverage before you invest in a hand-written Browser check or Playwright Check Suite ## Prompt best practices @@ -79,7 +79,7 @@ Each run can produce: - User-facing artifacts collected during the run -For new monitoring, use [API Checks](/detect/synthetic-monitoring/api-checks/overview), [Browser Checks](/detect/synthetic-monitoring/browser-checks/overview), or [Playwright Check Suites](/detect/synthetic-monitoring/playwright-checks/overview). [Automatic repair](../../../resolve/automatic-check-repair) can maintain supported checks with a saved intent. +For new monitoring, use [API checks](/detect/synthetic-monitoring/api-checks/overview), [Browser checks](/detect/synthetic-monitoring/browser-checks/overview), or [Playwright Check Suites](/detect/synthetic-monitoring/playwright-checks/overview). [Automatic repair](../../../resolve/automatic-check-repair) can maintain supported checks with a saved intent. ## Variables, secrets, and skills diff --git a/detect/synthetic-monitoring/api-checks/api-structure.mdx b/detect/synthetic-monitoring/api-checks/api-structure.mdx index 19f89e0a..99fac6f4 100644 --- a/detect/synthetic-monitoring/api-checks/api-structure.mdx +++ b/detect/synthetic-monitoring/api-checks/api-structure.mdx @@ -1,15 +1,15 @@ --- -title: 'API Check Structure' +title: 'API check structure' description: 'Learn how to structure your API checks with the ApiCheck construct.' sidebarTitle: MaC Structure canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/api-checks/api-structure/' --- -**Monitoring as Code**: Learn more about the [API Check Construct](/constructs/api-check). +**Monitoring as Code**: Learn more about the [API check construct](/constructs/api-check). -## API Check Test Structure +## API check test structure ```typescript import { ApiCheck, AssertionBuilder, Frequency } from 'checkly/constructs' @@ -87,7 +87,7 @@ assertions: [ ## Advanced Features -### Environment Variables +### Environment variables Use variables for dynamic content: ```javascript // Reference environment variables diff --git a/detect/synthetic-monitoring/api-checks/overview.mdx b/detect/synthetic-monitoring/api-checks/overview.mdx index 572fe038..498ed7d4 100644 --- a/detect/synthetic-monitoring/api-checks/overview.mdx +++ b/detect/synthetic-monitoring/api-checks/overview.mdx @@ -1,11 +1,11 @@ --- -title: 'API Checks Overview' +title: 'API checks overview' description: 'Monitor API endpoints with comprehensive HTTP request validation, performance testing, and detailed response analysis.' sidebarTitle: 'Overview' canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/api-checks/overview/' --- -**Monitoring as Code**: Learn more about the [API Check Construct](/constructs/api-check). +**Monitoring as Code**: Learn more about the [API check construct](/constructs/api-check). @@ -23,9 +23,9 @@ canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/api-check /> -## What are API Checks? +## What are API checks? -API checks are automated HTTP requests that validate API endpoint functionality by checking status codes, response content, headers, and performance metrics. They simulate real API usage patterns and help catch issues before they impact your users. You can create API checks in the UI, via the [API Check Construct](/constructs/api-check) or by importing your existing Swagger/OpenAPI spec. +API checks are automated HTTP requests that validate API endpoint functionality by checking status codes, response content, headers, and performance metrics. They simulate real API usage patterns and help catch issues before they impact your users. You can create API checks in the UI, via the [API check construct](/constructs/api-check) or by importing your existing Swagger/OpenAPI spec. **API checks are perfect for:** - REST API endpoint monitoring @@ -44,11 +44,11 @@ API checks are automated HTTP requests that validate API endpoint functionality -If you are looking to monitor complex API flows or data processing, you might want to consider using [Multistep Checks](/detect/synthetic-monitoring/multistep-checks/overview). +If you are looking to monitor complex API flows or data processing, you might want to consider using [Multistep checks](/detect/synthetic-monitoring/multistep-checks/overview). -## How API Checks Work +## How API checks work API checks perform comprehensive endpoint validation: @@ -62,7 +62,7 @@ API checks perform comprehensive endpoint validation: API checks are ideal for testing both internal services and external API dependencies your application relies on. -## API Check Results +## API check results API check results will expose key performance and correctness data about the HTTP response received from the target endpoint. diff --git a/detect/synthetic-monitoring/api-checks/quickstart.mdx b/detect/synthetic-monitoring/api-checks/quickstart.mdx index 36feced6..521b551a 100644 --- a/detect/synthetic-monitoring/api-checks/quickstart.mdx +++ b/detect/synthetic-monitoring/api-checks/quickstart.mdx @@ -1,12 +1,12 @@ --- -title: 'Creating An API Check' +title: 'Creating an API check' description: 'Step-by-step guide to creating your first API check in Checkly using the web UI and CLI.' sidebarTitle: 'Quickstart' canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/api-checks/quickstart/' --- -Learn more about all the [API Check capabilities](/detect/synthetic-monitoring/api-checks/overview) in the general overview. +Learn more about all the [API check capabilities](/detect/synthetic-monitoring/api-checks/overview) in the general overview. ![Screenshot of the create API check page](/images/docs/images/api-checks/overview-create-check.png) diff --git a/detect/synthetic-monitoring/api-checks/troubleshooting.mdx b/detect/synthetic-monitoring/api-checks/troubleshooting.mdx index c0ff55f2..7c10379a 100644 --- a/detect/synthetic-monitoring/api-checks/troubleshooting.mdx +++ b/detect/synthetic-monitoring/api-checks/troubleshooting.mdx @@ -1,5 +1,5 @@ --- -title: 'API Check Troubleshooting' +title: 'API check troubleshooting' description: 'Learn how to troubleshoot API checks with Checkly.' sidebarTitle: Troubleshooting canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/api-checks/troubleshooting/' diff --git a/detect/synthetic-monitoring/browser-checks/examples.mdx b/detect/synthetic-monitoring/browser-checks/examples.mdx index 3d343878..6a762f0c 100644 --- a/detect/synthetic-monitoring/browser-checks/examples.mdx +++ b/detect/synthetic-monitoring/browser-checks/examples.mdx @@ -1,6 +1,6 @@ --- -title: 'Browser Check Examples' -description: 'Real-world examples and implementation patterns for monitoring user workflows with Checkly browser checks across different industries and scenarios.' +title: 'Browser check examples' +description: 'Real-world examples and implementation patterns for monitoring user workflows with Checkly Browser checks across different industries and scenarios.' sidebarTitle: 'Examples' canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/browser-checks/examples/' --- @@ -651,9 +651,9 @@ test('Accessibility compliance validation', async ({ page }) => { ``` -Browser checks provide comprehensive validation of user experiences. Combine them with API checks and multistep checks for complete application monitoring coverage across all user touchpoints. +Browser checks provide comprehensive validation of user experiences. Combine them with API checks and Multistep checks for complete application monitoring coverage across all user touchpoints. -Use realistic test data and user scenarios in your browser checks to ensure they accurately represent actual user behavior and catch real-world issues. +Use realistic test data and user scenarios in your Browser checks to ensure they accurately represent actual user behavior and catch real-world issues. \ No newline at end of file diff --git a/detect/synthetic-monitoring/browser-checks/file-system.mdx b/detect/synthetic-monitoring/browser-checks/file-system.mdx index 8d3f4466..b12e1ea3 100644 --- a/detect/synthetic-monitoring/browser-checks/file-system.mdx +++ b/detect/synthetic-monitoring/browser-checks/file-system.mdx @@ -1,12 +1,12 @@ --- title: File uploads, downloads and the file system -description: "Handle file uploads and downloads in browser checks using Playwright's download event, the Download object, and setInputFiles to validate files end to end." +description: "Handle file uploads and downloads in Browser checks using Playwright's download event, the Download object, and setInputFiles to validate files end to end." sidebarTitle: File system canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/browser-checks/file-system/' --- -You might want to use (binary) files in your browser checks. For example, you might want to upload a file to an upload +You might want to use (binary) files in your Browser checks. For example, you might want to upload a file to an upload form in your webapp. Or, you might want to validate some aspect of a file that is available for download on your app. @@ -201,14 +201,14 @@ test('Save file in directory', async ({ page }) => { Due to this sandbox, certain Node.js variables are adapted to our platform and have values we set for them. The behaviour -is slightly different when creating a browser check in the Web UI or using the Checkly CLI. +is slightly different when creating a Browser check in the Web UI or using the Checkly CLI. -When creating a browser check in the Web UI, the variables are: +When creating a Browser check in the Web UI, the variables are: * `__dirname` will have the value of `/` * `__filename` will have the value of `/script.js` -When creating a browser check using the Checkly CLI, each run uses a temporary directory that mirrors your project structure: +When creating a Browser check using the Checkly CLI, each run uses a temporary directory that mirrors your project structure: * `__dirname` is the directory of your spec file in that temporary directory, for example `/tmp//__checks__`. * `__filename` is the full path of your spec file in that temporary directory, for example `/tmp//__checks__/my.spec.ts`. diff --git a/detect/synthetic-monitoring/browser-checks/mac-structure.mdx b/detect/synthetic-monitoring/browser-checks/mac-structure.mdx index dbb52809..45a84c33 100644 --- a/detect/synthetic-monitoring/browser-checks/mac-structure.mdx +++ b/detect/synthetic-monitoring/browser-checks/mac-structure.mdx @@ -1,16 +1,16 @@ --- -title: 'Browser Check Structure' -description: 'Learn how to structure your Browser Checks with Monitoring as Code.' +title: 'Browser check structure' +description: 'Learn how to structure your Browser checks with Monitoring as Code.' sidebarTitle: MaC Structure canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/browser-checks/mac-structure/' --- import GenericRuntimeVariablesTable from '/snippets/generic-runtime-variables-table.mdx'; -Monitoring as Code works by connecting Playwrighttest files with Checkly constructs to handle the end-to-endconfiguration of your Browser Check. +Monitoring as Code works by connecting Playwrighttest files with Checkly constructs to handle the end-to-endconfiguration of your Browser check. -## Browser Check Construct -The Browser Check construct is used to configure your monitoring settings, such as frequency, locations, and tags. Learn more about the [Browser Check Construct](/constructs/browser-check) +## Browser check construct +The Browser check construct is used to configure your monitoring settings, such as frequency, locations, and tags. Learn more about the [Browser check construct](/constructs/browser-check) ```ts browser-check.ts import { BrowserCheck, Frequency } from 'checkly/constructs' @@ -28,7 +28,7 @@ new BrowserCheck('browser-check-1', { ## Test Script Structure -Checkly uses Playwright to power Browser Checks. [Playwright](https://playwright.dev/docs/intro) is a robust, open-source framework for browser automation and end-to-end web application testing. It enables you to write atomic, reliable tests and easily control interactions within a web page. Browser checks execute automated test scripts in real browsers. +Checkly uses Playwright to power Browser checks. [Playwright](https://playwright.dev/docs/intro) is a robust, open-source framework for browser automation and end-to-end web application testing. It enables you to write atomic, reliable tests and easily control interactions within a web page. Browser checks execute automated test scripts in real browsers. ```typescript login.spec.ts // Use environment-specific URLs and credentials diff --git a/detect/synthetic-monitoring/browser-checks/overview.mdx b/detect/synthetic-monitoring/browser-checks/overview.mdx index 9d571ce6..1af354f7 100644 --- a/detect/synthetic-monitoring/browser-checks/overview.mdx +++ b/detect/synthetic-monitoring/browser-checks/overview.mdx @@ -1,12 +1,12 @@ --- -title: 'Browser Checks Overview' +title: 'Browser checks overview' description: 'Monitor end-to-end user flows and realistic interactions with automated browser testing using Playwright.' sidebarTitle: 'Overview' canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/browser-checks/overview/' --- -**Monitoring as Code**: Learn more about the [Browser Check Construct](/constructs/browser-check). +**Monitoring as Code**: Learn more about the [Browser check construct](/constructs/browser-check). @@ -24,7 +24,7 @@ canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/browser-c /> -## What are Browser Checks? +## What are Browser checks? Browser checks are automated tests that use real browsers to interact with your web applications. They simulate user journeys like logging in, filling out forms, making purchases, or navigating through complex workflows, ensuring your critical user paths work and perform correctly. @@ -41,7 +41,7 @@ Supported Browsers: - **Mobile Simulation**: Test responsive designs and mobile workflows -## How Browser Checks Work +## How Browser checks work Checkly uses Playwright to power your Browser checks. [Playwright](https://playwright.dev/docs/intro) is a robust, open-source framework for browser automation and end-to-end web application testing. It enables you to write idiomatic, reliable tests and easily control interactions within a web page. Browser checks execute automated test scripts in real browsers: @@ -66,7 +66,7 @@ Create your Playwright test file in the Checkly IDE, then configure the check se Browser checks use Playwright's test framework with a familiar structure. -It works by connecting constructs to handle the configuration of your Browser Check, and then referencing the test file in your repository. +It works by connecting constructs to handle the configuration of your Browser check, and then referencing the test file in your repository. ```ts browser-check.ts import { BrowserCheck, Frequency } from 'checkly/constructs' @@ -108,9 +108,9 @@ test('User login workflow', async ({ page }) => { To learn more about Playwright, see the our [Playwright documentation](/learn/playwright/overview). -## Browser Check Results +## Browser check results -Individual browser check results contain: +Individual Browser check results contain: * A short check summary, including errors broken down by category ![check results browser summary](/images/docs/images/monitoring/check-results-browser-summary.png) diff --git a/detect/synthetic-monitoring/browser-checks/performance-metrics.mdx b/detect/synthetic-monitoring/browser-checks/performance-metrics.mdx index 879e7f84..10ff6467 100644 --- a/detect/synthetic-monitoring/browser-checks/performance-metrics.mdx +++ b/detect/synthetic-monitoring/browser-checks/performance-metrics.mdx @@ -1,6 +1,6 @@ --- title: Performance & Web Vitals -description: 'Web Vitals for browser checks' +description: 'Web Vitals for Browser checks' sidebarTitle: 'Performance Metrics' canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/browser-checks/performance-metrics/' --- @@ -22,7 +22,7 @@ Checkly automatically collect Network Waterfalls & Performance signals (**Web Vi -Checkly only collects tracing and web vitals data if your browser check meets the following criteria: +Checkly only collects tracing and web vitals data if your Browser check meets the following criteria: - It is based on **Playwright**. - It runs on any **runtime above [2021.06](/cli/checkly-runtimes)** diff --git a/detect/synthetic-monitoring/browser-checks/playwright-support.mdx b/detect/synthetic-monitoring/browser-checks/playwright-support.mdx index fd85cf98..398adc77 100644 --- a/detect/synthetic-monitoring/browser-checks/playwright-support.mdx +++ b/detect/synthetic-monitoring/browser-checks/playwright-support.mdx @@ -1,12 +1,12 @@ --- title: Playwright Support in Checkly -description: "See which Playwright features Checkly's browser checks support, from trace files and video recordings to auto-waiting, locators, and visual regression testing." +description: "See which Playwright features Checkly's Browser checks support, from trace files and video recordings to auto-waiting, locators, and visual regression testing." sidebarTitle: 'Playwright Support' canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/browser-checks/playwright-support/' --- -Checkly natively supports running complex browser checks that mimic real user actions using Playwright, the best automation framework. Playwright and Checkly together elevate your monitoring and debugging experience by providing: +Checkly natively supports running complex Browser checks that mimic real user actions using Playwright, the best automation framework. Playwright and Checkly together elevate your monitoring and debugging experience by providing: - Detailed trace files with step-by-step information on your test cases - Video recordings of browser sessions @@ -27,8 +27,8 @@ This is the list of Playwright features that are currently supported. We will up | API testing | Yes | | Custom fixtures | Yes | | Reporters | JSON | -| Typescript | Yes | -| Global configuration | Yes, a subset of playwright config options. | +| TypeScript | Yes | +| Global configuration | Yes, a subset of Playwright config options. | | Visual comparisons | Yes | | Test retry | No, configure a [retry strategy](/communicate/alerts/retries) in the check settings to retry a check. | | Parallelism and sharding | No | @@ -62,7 +62,7 @@ We currently support the following configuration options. We will update this li | `projects` | ❌ | | `webServer` | ❌ | - For more information about the `global` options you can check playwright official documentation [Test configuration](https://playwright.dev/docs/test-configuration) + For more information about the `global` options you can check Playwright official documentation [Test configuration](https://playwright.dev/docs/test-configuration) | Option | Supported | @@ -98,7 +98,7 @@ We currently support the following configuration options. We will update this li | `trace` | ❌ | | `video` | ❌ | - For more information about the `use` options you can check playwright official documentation [Test use options](https://playwright.dev/docs/test-use-options) + For more information about the `use` options you can check Playwright official documentation [Test use options](https://playwright.dev/docs/test-use-options) | Option | Supported | @@ -107,7 +107,7 @@ We currently support the following configuration options. We will update this li | `toHaveScreenshot ` | ✅ | | `toMatchSnapshot ` | ✅ | - For more information about the `expect` options you can check playwright official documentation [Test Expect options](https://playwright.dev/docs/test-configuration#expect-options) + For more information about the `expect` options you can check Playwright official documentation [Test Expect options](https://playwright.dev/docs/test-configuration#expect-options) @@ -288,7 +288,7 @@ test.describe('two tests', () => { - An executed browser check that includes multiple Playwright test cases still counts as a single check run towards your pricing plan's defined limits. + An executed Browser check that includes multiple Playwright test cases still counts as a single check run towards your pricing plan's defined limits. ## Interactions & Navigations diff --git a/detect/synthetic-monitoring/browser-checks/quickstart.mdx b/detect/synthetic-monitoring/browser-checks/quickstart.mdx index 231991df..e0ec968a 100644 --- a/detect/synthetic-monitoring/browser-checks/quickstart.mdx +++ b/detect/synthetic-monitoring/browser-checks/quickstart.mdx @@ -1,6 +1,6 @@ --- -title: 'Creating A Browser Check' -description: 'Get started with Checkly by creating your first Browser Check' +title: 'Creating a Browser check' +description: 'Get started with Checkly by creating your first Browser check' sidebarTitle: 'Quickstart' canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/browser-checks/quickstart/' --- @@ -9,12 +9,12 @@ import CliAuth from '/snippets/cli-auth.mdx'; import CliProjectInit from '/snippets/cli-project-init.mdx'; -Learn more about all the [Browser Check capabilities](/detect/synthetic-monitoring/browser-checks/overview) in the general overview. +Learn more about all the [Browser check capabilities](/detect/synthetic-monitoring/browser-checks/overview) in the general overview. -This guide will walk you through creating your first Browser Check with Checkly. +This guide will walk you through creating your first Browser check with Checkly. -Browser Checks are perfect for monitoring realistic user flows within your application or services. If you are looking for monitoring general availability, check out the [Uptime Monitor Quickstart](/detect/uptime-monitoring/url-monitors/quickstart). +Browser checks are perfect for monitoring realistic user flows within your application or services. If you are looking for monitoring general availability, check out the [Uptime Monitor Quickstart](/detect/uptime-monitoring/url-monitors/quickstart). - A Checkly account (sign up at [checklyhq.com](https://checklyhq.com)) @@ -23,7 +23,7 @@ Browser Checks are perfect for monitoring realistic user flows within your appli - + 1. **Head to [Create a Check](https://app.checklyhq.com/accounts/create)** - 2. **Choose from one of the Browser Check templates** to start from a working example + 2. **Choose from one of the Browser check templates** to start from a working example @@ -145,9 +145,9 @@ Once your check is active: Now that you have your first check running: -- **Add API Checks**: Monitor your backend services and APIs -- **Create Check Groups**: Organize related checks together -- **Set up Status Pages**: Share uptime information with users +- **Add API checks**: Monitor your backend services and APIs +- **Create check groups**: Organize related checks together +- **Set up status pages**: Share uptime information with users - **Explore Integrations**: Connect with Slack, PagerDuty, or other tools ## Upgrading to Monitoring as Code diff --git a/detect/synthetic-monitoring/browser-checks/timeouts.mdx b/detect/synthetic-monitoring/browser-checks/timeouts.mdx index cbe2e4d6..f0023cfd 100644 --- a/detect/synthetic-monitoring/browser-checks/timeouts.mdx +++ b/detect/synthetic-monitoring/browser-checks/timeouts.mdx @@ -1,5 +1,5 @@ --- -title: 'Browser Check Timeouts' +title: 'Browser check timeouts' description: 'Browser check timeouts.' sidebarTitle: 'Timeouts' canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/browser-checks/timeouts/' @@ -17,7 +17,7 @@ There are different kinds of timeouts you will encounter while working with Brow Checkly runs your Browser check code for a maximum of **240 seconds**. Tests that exceed this time will be capped and -time out. Everything in your Browser Check needs to happen within those 240 seconds, no matter what. +time out. Everything in your Browser check needs to happen within those 240 seconds, no matter what. Playwright does offer multiple [configurable timeouts](https://playwright.dev/docs/test-timeouts). Make sure you configure these in a way that prevents your check from hitting the general 240 seconds timeout. @@ -64,7 +64,7 @@ test('add item to wishlist', async ({ page }) => { ### Your check run has reached the maximum run time of 240000 ms. In this case, your script is hitting Checkly's 240s total Browser check timeout. This can't be configured and is in -place to prevent checks from running way longer than acceptable. No assets will be available for review after the check has gone over the maximum run time. If you encounter this, try to make your check shorter by following [best practices](/learn/playwright/writing-tests/). Additionally, to ensure your assets are saved, please set a test timeout lower than the browser check execution timeout. +place to prevent checks from running way longer than acceptable. No assets will be available for review after the check has gone over the maximum run time. If you encounter this, try to make your check shorter by following [best practices](/learn/playwright/writing-tests/). Additionally, to ensure your assets are saved, please set a test timeout lower than the Browser check execution timeout. ### Timeout 20000ms exceeded diff --git a/detect/synthetic-monitoring/browser-checks/troubleshooting.mdx b/detect/synthetic-monitoring/browser-checks/troubleshooting.mdx index 3e77530a..6d33f46a 100644 --- a/detect/synthetic-monitoring/browser-checks/troubleshooting.mdx +++ b/detect/synthetic-monitoring/browser-checks/troubleshooting.mdx @@ -1,6 +1,6 @@ --- title: 'Trouble Shotting and Debugging' -description: 'Learn how to troubleshoot browser checks.' +description: 'Learn how to troubleshoot Browser checks.' sidebarTitle: Troubleshooting canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/browser-checks/troubleshooting/' --- diff --git a/detect/synthetic-monitoring/browser-checks/visual-regressions.mdx b/detect/synthetic-monitoring/browser-checks/visual-regressions.mdx index b95dd387..6ce67a0f 100644 --- a/detect/synthetic-monitoring/browser-checks/visual-regressions.mdx +++ b/detect/synthetic-monitoring/browser-checks/visual-regressions.mdx @@ -31,7 +31,7 @@ The TL;DR is that you can: Starting with visual regression testing takes just three easy steps: 1. Add a single `expect(page).toHaveScreenshot()` line of code to - your browser check script, like the example below. + your Browser check script, like the example below. @@ -55,7 +55,7 @@ Starting with visual regression testing takes just three easy steps: -2. Run your browser check. The first time you run it, you will get an error indicating that no golden image / reference +2. Run your Browser check. The first time you run it, you will get an error indicating that no golden image / reference snapshot exists yet. ``` @@ -242,13 +242,13 @@ and deploy any changes either directly from your local machine or from your CI/C In a typical scenario, you would follow the steps below: -1. Create or update a browser check with visual regression or snapshot testing on your local machine. +1. Create or update a Browser check with visual regression or snapshot testing on your local machine. 2. Generate the golden image / reference snapshot(s). ```bash npx checkly test --update-snapshots ``` - 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. + 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, test your checks before deploying. Test results will be uploaded to Checkly's test sessions for review. ```bash diff --git a/detect/synthetic-monitoring/multistep-checks/degraded-states.mdx b/detect/synthetic-monitoring/multistep-checks/degraded-states.mdx index 93d0df5d..5c93399c 100644 --- a/detect/synthetic-monitoring/multistep-checks/degraded-states.mdx +++ b/detect/synthetic-monitoring/multistep-checks/degraded-states.mdx @@ -1,5 +1,5 @@ --- -title: Degraded States In Multistep Checks +title: Degraded states in Multistep checks description: "Signal non-critical slowdowns in Multistep checks with the degraded state, using soft assertions and the @checkly/playwright-helpers markCheckAsDegraded helper." sidebarTitle: Degraded States diff --git a/detect/synthetic-monitoring/multistep-checks/examples.mdx b/detect/synthetic-monitoring/multistep-checks/examples.mdx index e2f40529..8ee16fe9 100644 --- a/detect/synthetic-monitoring/multistep-checks/examples.mdx +++ b/detect/synthetic-monitoring/multistep-checks/examples.mdx @@ -1,6 +1,6 @@ --- -title: 'Multistep Check Examples' +title: 'Multistep check examples' description: 'Learn how to use Multistep checks with Playwright.' sidebarTitle: Examples canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/multistep-checks/examples/' diff --git a/detect/synthetic-monitoring/multistep-checks/file-system.mdx b/detect/synthetic-monitoring/multistep-checks/file-system.mdx index d104827e..1b458021 100644 --- a/detect/synthetic-monitoring/multistep-checks/file-system.mdx +++ b/detect/synthetic-monitoring/multistep-checks/file-system.mdx @@ -1,6 +1,6 @@ --- title: Uploading & Downloading Files To The File System -description: "Upload and download binary files in multistep checks with Playwright's request object, hosting files externally and validating them with HTTP requests." +description: "Upload and download binary files in Multistep checks with Playwright's request object, hosting files externally and validating them with HTTP requests." sidebarTitle: File System canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/multistep-checks/file-system/' diff --git a/detect/synthetic-monitoring/multistep-checks/multistep-structure.mdx b/detect/synthetic-monitoring/multistep-checks/multistep-structure.mdx index d8292921..de155735 100644 --- a/detect/synthetic-monitoring/multistep-checks/multistep-structure.mdx +++ b/detect/synthetic-monitoring/multistep-checks/multistep-structure.mdx @@ -1,15 +1,15 @@ --- -title: 'Multistep Check Structure' -description: 'Learn how to structure your multistep checks with Playwright.' +title: 'Multistep check structure' +description: 'Learn how to structure your Multistep checks with Playwright.' sidebarTitle: MaC Structure canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/multistep-checks/multistep-structure/' --- -**Monitoring as Code**: Learn more about the [Multistep Check Construct](/constructs/multistep-check). +**Monitoring as Code**: Learn more about the [Multistep check construct](/constructs/multistep-check). -## Multistep Check Construct +## Multistep check construct ```ts multistep-check.ts import { MultiStepCheck, Frequency } from 'checkly/constructs' diff --git a/detect/synthetic-monitoring/multistep-checks/overview.mdx b/detect/synthetic-monitoring/multistep-checks/overview.mdx index e642ef74..3024c698 100644 --- a/detect/synthetic-monitoring/multistep-checks/overview.mdx +++ b/detect/synthetic-monitoring/multistep-checks/overview.mdx @@ -1,5 +1,5 @@ --- -title: 'Multistep Checks Overview' +title: 'Multistep checks overview' description: 'Monitor complex API workflows with sequential requests using Playwright API testing mode for comprehensive end-to-end validation.' sidebarTitle: 'Overview' canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/multistep-checks/overview/' @@ -8,7 +8,7 @@ canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/multistep import GenericRuntimeVariablesTable from '/snippets/generic-runtime-variables-table.mdx'; -**Monitoring as Code**: Learn more about the [Multistep Check Construct](/constructs/multistep-check). +**Monitoring as Code**: Learn more about the [Multistep check construct](/constructs/multistep-check). @@ -26,7 +26,7 @@ import GenericRuntimeVariablesTable from '/snippets/generic-runtime-variables-ta /> -## What are Multistep Checks? +## What are Multistep checks? Multistep checks are API-focused tests that perform multiple sequential HTTP requests within a single check. They're designed to test complete user workflows that span multiple API endpoints, ensuring that complex business processes work correctly from start to finish. Multistep checks use Playwright's `request` fixture. @@ -38,7 +38,7 @@ Multistep checks are API-focused tests that perform multiple sequential HTTP req - Complex business transaction testing - API dependency chain validation -## How Multistep Checks Work +## How Multistep checks work Multistep checks execute a series of API requests in sequence, with the ability to pass data between steps: @@ -81,13 +81,13 @@ As with Browser checks, Checkly runs Multistep checks for a maximum of 240s. Scr ## Built-in Runtime Variables -The Multistep Check [runtime](/platform/runtimes/overview) exposes a set of environment variables (e.g. `process.env.CHECK_NAME`) that indicate what check, check type etc. you are running. +The Multistep check [runtime](/platform/runtimes/overview) exposes a set of environment variables (e.g. `process.env.CHECK_NAME`) that indicate what check, check type etc. you are running. [Learn more about environment variables.](/platform/variables) -## Multistep Check Results +## Multistep check results Multistep check results are navigated using the tree on the left side of the screen. If you are running checks in parallel, first select the location you are interested in. diff --git a/detect/synthetic-monitoring/multistep-checks/quickstart.mdx b/detect/synthetic-monitoring/multistep-checks/quickstart.mdx index e94de372..26c37211 100644 --- a/detect/synthetic-monitoring/multistep-checks/quickstart.mdx +++ b/detect/synthetic-monitoring/multistep-checks/quickstart.mdx @@ -1,15 +1,15 @@ --- -title: 'Creating A Multistep Check' -description: 'Step-by-step guide to creating your first multistep check in Checkly for monitoring complex API workflows and business processes.' +title: 'Creating a Multistep check' +description: 'Step-by-step guide to creating your first Multistep check in Checkly for monitoring complex API workflows and business processes.' sidebarTitle: 'Quickstart' canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/multistep-checks/quickstart/' --- -Learn more about all the [Multistep Check capabilities](/detect/synthetic-monitoring/multistep-checks/overview) in the general overview. +Learn more about all the [Multistep check capabilities](/detect/synthetic-monitoring/multistep-checks/overview) in the general overview. -Multistep checks allow you to monitor complex API workflows that span multiple endpoints and validate complete business processes. In this comprehensive guide, you'll create your first multistep check to ensure your critical API workflows function correctly end-to-end. +Multistep checks allow you to monitor complex API workflows that span multiple endpoints and validate complete business processes. In this comprehensive guide, you'll create your first Multistep check to ensure your critical API workflows function correctly end-to-end. You'll need a series of API endpoints that work together to complete a business process. Multistep checks excel at testing workflows that require data to flow from one API call to the next. diff --git a/detect/synthetic-monitoring/multistep-checks/troubleshooting.mdx b/detect/synthetic-monitoring/multistep-checks/troubleshooting.mdx index 54079978..bcdf1bf6 100644 --- a/detect/synthetic-monitoring/multistep-checks/troubleshooting.mdx +++ b/detect/synthetic-monitoring/multistep-checks/troubleshooting.mdx @@ -1,7 +1,7 @@ --- -title: 'Troubleshooting Multistep Checks' -description: 'Learn how to troubleshoot multistep checks.' +title: 'Troubleshooting Multistep checks' +description: 'Learn how to troubleshoot Multistep checks.' sidebarTitle: Troubleshooting canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/multistep-checks/troubleshooting/' --- diff --git a/detect/synthetic-monitoring/multistep-checks/websockets.mdx b/detect/synthetic-monitoring/multistep-checks/websockets.mdx index acad3124..00643930 100644 --- a/detect/synthetic-monitoring/multistep-checks/websockets.mdx +++ b/detect/synthetic-monitoring/multistep-checks/websockets.mdx @@ -1,6 +1,6 @@ --- title: WebSockets on Multistep checks -description: "Monitor a WebSocket endpoint from a multistep check by scripting a connection, sending messages, and validating the responses you get back." +description: "Monitor a WebSocket endpoint from a Multistep check by scripting a connection, sending messages, and validating the responses you get back." sidebarTitle: WebSockets canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/multistep-checks/websockets/' diff --git a/detect/synthetic-monitoring/overview.mdx b/detect/synthetic-monitoring/overview.mdx index bcacaed6..c6193d98 100644 --- a/detect/synthetic-monitoring/overview.mdx +++ b/detect/synthetic-monitoring/overview.mdx @@ -15,19 +15,19 @@ Synthetic monitoring goes beyond simple uptime checks by proactively validating Checkly provides four check types to comprehensively monitor your applications: - + Monitor individual API endpoints with detailed request/response validation. - + Test complex API workflows with sequential requests and data flow validation. - + Simulate real user interactions with automated browser testing using Playwright. @@ -45,15 +45,15 @@ Migrate your existing Playwright projects and tests to Checkly. Ready to implement comprehensive synthetic monitoring? Choose your starting point based on your monitoring needs: - + Start with backend API monitoring and validation - + Monitor user experiences with automated browser testing - + Test complex workflows with sequential API requests diff --git a/detect/synthetic-monitoring/playwright-checks/custom-dependencies.mdx b/detect/synthetic-monitoring/playwright-checks/custom-dependencies.mdx index 31c61aff..e22cce96 100644 --- a/detect/synthetic-monitoring/playwright-checks/custom-dependencies.mdx +++ b/detect/synthetic-monitoring/playwright-checks/custom-dependencies.mdx @@ -8,7 +8,7 @@ canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/playwrigh Use the [Checkly CLI](/cli/overview) to turn your Playwright tests into globally distributed monitors. Checkly uses your existing `package.json` dependencies and Playwright configuration. -Playwright Check Suites do not use Checkly runtimes. Browser Checks and Multistep Checks use `runtimeId` to select a managed runtime with fixed Checkly-provided dependencies. Playwright Check Suites install your project dependencies and use `engine` to select the JavaScript engine version. +Playwright Check Suites do not use Checkly runtimes. Browser checks and Multistep checks use `runtimeId` to select a managed runtime with fixed Checkly-provided dependencies. Playwright Check Suites install your project dependencies and use `engine` to select the JavaScript engine version. ## Using JavaScript/Node.js dependencies @@ -209,7 +209,7 @@ Checkly automatically retries transient failures during setup steps. Cache downl **Public Locations**: Dependency caching is **Always ON**. -**Private Locations**: Dependency caching is **OFF by default**. To enable caching and speed up check runs, set `DEPENDENCY_CACHE=CHECKLY_S3` in your [agent configuration](/platform/private-locations/agent-configuration). +**Private locations**: Dependency caching is **OFF by default**. To enable caching and speed up check runs, set `DEPENDENCY_CACHE=CHECKLY_S3` in your [agent configuration](/platform/private-locations/agent-configuration). ## Playwright browser caching @@ -219,12 +219,12 @@ Checkly caches Playwright browsers so that runs don't download them every time. Checkly caches Playwright browsers across all public regions to reduce startup time. When a new Playwright version is available, runs download browsers until Checkly updates the shared cache. -### Browser caching on Private Locations -Checkly caches Playwright browsers on each Private Location agent, grouped by Playwright version. +### Browser caching on private locations +Checkly caches Playwright browsers on each private location agent, grouped by Playwright version. When a matching version exists in cache, Checkly skips the download — reducing startup time and making runs more reliable. -Browser caching requires Private Location agent v8.2.0 or later. +Browser caching requires private location agent v8.2.0 or later. diff --git a/detect/synthetic-monitoring/playwright-checks/environment-variables.mdx b/detect/synthetic-monitoring/playwright-checks/environment-variables.mdx index 5d54efab..d8ad81fd 100644 --- a/detect/synthetic-monitoring/playwright-checks/environment-variables.mdx +++ b/detect/synthetic-monitoring/playwright-checks/environment-variables.mdx @@ -1,13 +1,13 @@ --- -title: Playwright Check Suite Environment Variables -sidebarTitle: Environment Variables +title: Playwright Check Suite environment variables +sidebarTitle: Environment variables description: "Customize your Playwright Check Suite runs based on the execution environment." tags: ["synthetic-monitoring", "playwright-checks", "environment-variables"] canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/playwright-checks/environment-variables/' --- - To create and manage environment variables and secrets, including inheritance and where to set them, see the [Environment Variables documentation](/platform/variables). + To create and manage environment variables and secrets, including inheritance and where to set them, see the [environment variables documentation](/platform/variables). ## Built-in variables in Playwright Check Suites diff --git a/detect/synthetic-monitoring/playwright-checks/overview.mdx b/detect/synthetic-monitoring/playwright-checks/overview.mdx index 23e2638d..1da4e625 100644 --- a/detect/synthetic-monitoring/playwright-checks/overview.mdx +++ b/detect/synthetic-monitoring/playwright-checks/overview.mdx @@ -65,7 +65,7 @@ Control which tests run as monitors using: - **Projects**: Select browser and project configurations from your Playwright config with `pwProjects` - **Tags**: Choose tests marked with specific tags (e.g., `@critical`, `@smoke`) with `pwTags` - **Combinations**: Mix tags and projects for precise control -- **testCommand**: Use `npx playwright test ...` to select the tests you want to create a monitor for, using playwright flags like `--grep-invert` or `--projects` +- **testCommand**: Use `npx playwright test ...` to select the tests you want to create a monitor for, using Playwright flags like `--grep-invert` or `--projects` Configure test selection in your `checkly.config.ts` file: diff --git a/detect/synthetic-monitoring/playwright-checks/performance-metrics.mdx b/detect/synthetic-monitoring/playwright-checks/performance-metrics.mdx index de784303..b9184f2f 100644 --- a/detect/synthetic-monitoring/playwright-checks/performance-metrics.mdx +++ b/detect/synthetic-monitoring/playwright-checks/performance-metrics.mdx @@ -117,6 +117,6 @@ Checkly reports these visits honestly rather than showing stale or misleading nu A soft-nav row with mostly empty cells is intentional, not a failure to collect data. Read its INP, and the INP breakdown, for that route's responsiveness. -## Web Vitals for browser checks +## Web Vitals for Browser checks Classic [Browser checks](/detect/synthetic-monitoring/browser-checks/performance-metrics) collect the same Web Vitals with the same scoring. Playwright Check Suites report them per page visit across a whole suite, and add the LCP and INP attribution above. diff --git a/detect/synthetic-monitoring/playwright-monitoring-comparison.mdx b/detect/synthetic-monitoring/playwright-monitoring-comparison.mdx index d0eca292..83414003 100644 --- a/detect/synthetic-monitoring/playwright-monitoring-comparison.mdx +++ b/detect/synthetic-monitoring/playwright-monitoring-comparison.mdx @@ -8,7 +8,7 @@ canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/playwrigh import { checkDurations } from '/snippets/check-comparison.mdx' -[MultiStep Checks](/detect/synthetic-monitoring/multistep-checks/overview), [Browser Checks](/detect/synthetic-monitoring/browser-checks/overview), and [Playwright Check Suites](/detect/synthetic-monitoring/playwright-checks/overview) use Playwright for synthetic monitoring. The different check types vary in capabilities, flexibility, and use cases. +[Multistep checks](/detect/synthetic-monitoring/multistep-checks/overview), [Browser checks](/detect/synthetic-monitoring/browser-checks/overview), and [Playwright Check Suites](/detect/synthetic-monitoring/playwright-checks/overview) use Playwright for synthetic monitoring. The different check types vary in capabilities, flexibility, and use cases. After logging into the Checkly web application, you can use the built-in editor to write Playwright code to monitor your APIs and sites. **Use MultiStep and Browser checks to get started quickly via the user interface**. Checkly handles code storage, configuration of advanced settings, and dependency updates with [runtimes](/platform/runtimes/overview/). @@ -16,13 +16,13 @@ However, when your monitoring setup needs to scale with your growing project req All Playwright-based checks can be created, updated and configured as code. But, when should you use which? -## When to use MultiStep Checks +## When to use Multistep checks -Choose [MultiStep Checks](/detect/synthetic-monitoring/multistep-checks/overview) when you need to monitor complex API workflows with sequential requests using the familiar Playwright API. MultiStep Check runs are based on a single `spec.ts` file, limited to making HTTP requests (there's no browser available) and **the max check run duration is capped at { checkDurations.multiStep }**. +Choose [Multistep checks](/detect/synthetic-monitoring/multistep-checks/overview) when you need to monitor complex API workflows with sequential requests using the familiar Playwright API. Multistep check runs are based on a single `spec.ts` file, limited to making HTTP requests (there's no browser available) and **the max check run duration is capped at { checkDurations.multiStep }**. -## When to use Browser Checks +## When to use Browser checks -Choose [Browser Checks](/detect/synthetic-monitoring/browser-checks/overview) when you need to monitor end-to-end user flows and realistic interactions with automated browser testing using Playwright. Browser Check runs are based on a single `spec.ts` file, support the headless Chromium/Chrome browser and **the max check run duration is capped at { checkDurations.browser }**. +Choose [Browser checks](/detect/synthetic-monitoring/browser-checks/overview) when you need to monitor end-to-end user flows and realistic interactions with automated browser testing using Playwright. Browser check runs are based on a single `spec.ts` file, support the headless Chromium/Chrome browser and **the max check run duration is capped at { checkDurations.browser }**. ## When to use Playwright Check Suites @@ -36,7 +36,7 @@ Playwright Check Suites are the native way to run your Playwright project in pro ## Feature comparison -| Feature | Playwright Check Suites | Browser Check | MultiStep Check | +| Feature | Playwright Check Suites | Browser check | Multistep check | |-------------------------------------------------------------|--------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------| | Supports *Monitoring as Code* | Yes | Yes | Yes | | [Test fixtures](https://playwright.dev/docs/test-fixtures) | `page`, `context`, `browser`, `browserName`, `request` | `page`, `context`, `browser`, `browserName`, `request` | `request` | diff --git a/detect/testing/creating-your-first-test.mdx b/detect/testing/creating-your-first-test.mdx index dc1b05ae..113db93c 100644 --- a/detect/testing/creating-your-first-test.mdx +++ b/detect/testing/creating-your-first-test.mdx @@ -148,7 +148,7 @@ After deployment, you can: ## Advanced Check Configuration -For more control over your browser checks: +For more control over your Browser checks: ```ts __checks__/advanced-browser.check.ts import { BrowserCheck, Frequency, RetryStrategyBuilder } from 'checkly/constructs' @@ -175,7 +175,7 @@ new BrowserCheck('advanced-check', { 2. **Use Page Object Model**: Organize your tests with reusable page objects 3. **Test Critical User Journeys**: Focus on the most important user flows 4. **Set Appropriate Frequencies**: Don't over-monitor; balance coverage with costs -5. **Use Environment Variables**: Keep sensitive data and URLs configurable +5. **Use environment variables**: Keep sensitive data and URLs configurable 6. **Add Meaningful Assertions**: Test both functionality and performance 7. **Take Screenshots**: Helpful for debugging when tests fail 8. **Monitor APIs and UI**: Combine browser and API checks for comprehensive coverage diff --git a/detect/testing/overview.mdx b/detect/testing/overview.mdx index 24791c5b..c923313f 100644 --- a/detect/testing/overview.mdx +++ b/detect/testing/overview.mdx @@ -52,12 +52,12 @@ Create a single test and use it for both pre-production validation and productio Create a [Playwright test](/detect/synthetic-monitoring/playwright-checks/overview) - + Verify that non-HTTP services are reachable by checking connectivity to a host and port. Create a [TCP monitor](/detect/uptime-monitoring/tcp-monitors/overview) - + Check that your DNS records resolve as expected and catch misconfigurations or propagation issues. Create a [DNS monitor](/detect/uptime-monitoring/dns-monitors/overview) diff --git a/detect/testing/playwright-reporter-changelog.mdx b/detect/testing/playwright-reporter-changelog.mdx index e39a868c..979cd845 100644 --- a/detect/testing/playwright-reporter-changelog.mdx +++ b/detect/testing/playwright-reporter-changelog.mdx @@ -218,7 +218,7 @@ Learn more about: **Credentials now required** - Reporter requires Checkly credentials (`apiKey` + `accountId`) or explicit `dryRun: true`. Missing credentials now show clear error messages instead of silently skipping upload. - If you're not using Checkly Test Sessions, add `dryRun: true` to your config: + If you're not using Checkly test sessions, add `dryRun: true` to your config: ```typescript reporter: [['@checkly/playwright-reporter', { dryRun: true }]] @@ -300,7 +300,7 @@ Learn more about: - **Broad Playwright support** - Compatible with Playwright versions 1.40 through 1.57+ - **Drop-in JSON replacement** - Fully compatible with Playwright's native JSON reporter output format - **Trace extraction** - Automatically extracts console messages and network requests from Playwright trace files - - **Checkly integration** - Automatic upload to Checkly Test Sessions when credentials are configured + - **Checkly integration** - Automatic upload to Checkly test sessions when credentials are configured - **New `createChecklyReporter()` function** - Better IntelliSense support in `playwright.config.ts` - **Unified `outputDir` option** - Single option for all output files (JSON report, ZIP assets) - **Verbose logging** - Debug mode for troubleshooting report generation diff --git a/detect/testing/playwright-reporter.mdx b/detect/testing/playwright-reporter.mdx index a39f70b1..c8d1d4ae 100644 --- a/detect/testing/playwright-reporter.mdx +++ b/detect/testing/playwright-reporter.mdx @@ -159,7 +159,7 @@ export default defineConfig({ - `checkly-report.json` - JSON test report - `checkly-report.zip` - ZIP archive with report and assets -### Environment Variables +### Environment variables | Variable | Description | |----------|-------------| @@ -268,7 +268,7 @@ If your Checkly reports don't include traces or videos, ensure that your `playwr **Using UI mode?** The reporter uploads results from UI mode runs, too. Enable [`dryRun`](#dry-run-mode) to skip uploads during local development. -## Understanding Test Sessions +## Understanding test sessions The reporter creates **suite-level test sessions**, not individual test file results. diff --git a/detect/testing/using-env-variables.mdx b/detect/testing/using-env-variables.mdx index 789020e9..6758d674 100644 --- a/detect/testing/using-env-variables.mdx +++ b/detect/testing/using-env-variables.mdx @@ -1,7 +1,7 @@ --- -title: Using Environment Variables +title: Using environment variables description: "Pass environment variables to your Checkly tests so a single check can run against staging, preview, or production URLs using the --env flag." -sidebarTitle: Environment Variables +sidebarTitle: Environment variables canonical: 'https://www.checklyhq.com/docs/detect/testing/using-env-variables/' --- diff --git a/detect/uptime-monitoring/dns-monitors/configuration.mdx b/detect/uptime-monitoring/dns-monitors/configuration.mdx index 4907374c..f03dc531 100644 --- a/detect/uptime-monitoring/dns-monitors/configuration.mdx +++ b/detect/uptime-monitoring/dns-monitors/configuration.mdx @@ -1,12 +1,12 @@ --- -title: 'DNS Monitor Configuration' +title: 'DNS monitor configuration' description: 'Configure your DNS monitor to verify record resolution.' sidebarTitle: 'Configuration' canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/dns-monitors/configuration/' --- {/* -To configure a DNS monitor using code, learn more about the [DNS Monitor Construct](/constructs/dns-monitor). +To configure a DNS monitor using code, learn more about the [DNS monitor construct](/constructs/dns-monitor). */} ### Basic Setup diff --git a/detect/uptime-monitoring/dns-monitors/overview.mdx b/detect/uptime-monitoring/dns-monitors/overview.mdx index 81564e9e..486de393 100644 --- a/detect/uptime-monitoring/dns-monitors/overview.mdx +++ b/detect/uptime-monitoring/dns-monitors/overview.mdx @@ -1,5 +1,5 @@ --- -title: 'DNS Monitors Overview' +title: 'DNS monitors overview' description: 'Monitor the resolution and lookup times of DNS records' sidebarTitle: Overview canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/dns-monitors/overview/' @@ -21,7 +21,7 @@ canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/dns-monitors /> -## What are DNS Monitors? +## What are DNS monitors? DNS monitors check that your DNS records resolve as expected. They help you catch misconfigurations, expired records, or propagation issues before they impact your users. @@ -77,7 +77,7 @@ DNS monitors support the following DNS record types: - **TXT**: Text records (SPF, DKIM, DMARC, etc.) - **HTTPS**: HTTPS service binding records ([RFC 9460](https://www.rfc-editor.org/rfc/rfc9460)) — advertise HTTP/3 (`alpn`), address hints (`ipv4hint`/`ipv6hint`), and Encrypted Client Hello (`ech`) -## DNS Monitor Results +## DNS monitor results Select a specific check run to inspect its results: diff --git a/detect/uptime-monitoring/grpc-monitors/configuration.mdx b/detect/uptime-monitoring/grpc-monitors/configuration.mdx index a1a61955..9cc405b8 100644 --- a/detect/uptime-monitoring/grpc-monitors/configuration.mdx +++ b/detect/uptime-monitoring/grpc-monitors/configuration.mdx @@ -1,12 +1,12 @@ --- -title: 'gRPC Monitor Configuration' +title: 'gRPC monitor configuration' description: 'Configure your gRPC monitor to verify service availability, health, and response correctness.' sidebarTitle: 'Configuration' canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/grpc-monitors/configuration/' --- -To configure a gRPC monitor using code, learn more about the [gRPC Monitor Construct](/constructs/grpc-monitor). +To configure a gRPC monitor using code, learn more about the [gRPC monitor construct](/constructs/grpc-monitor). ### Basic Setup diff --git a/detect/uptime-monitoring/grpc-monitors/overview.mdx b/detect/uptime-monitoring/grpc-monitors/overview.mdx index b01453bd..73c8090c 100644 --- a/detect/uptime-monitoring/grpc-monitors/overview.mdx +++ b/detect/uptime-monitoring/grpc-monitors/overview.mdx @@ -1,15 +1,15 @@ --- -title: 'gRPC Monitors Overview' +title: 'gRPC monitors overview' description: 'Monitor gRPC service availability, health, and response times.' sidebarTitle: Overview canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/grpc-monitors/overview/' --- -**Monitoring as Code**: Learn more about the [gRPC Monitor Construct](/constructs/grpc-monitor). +**Monitoring as Code**: Learn more about the [gRPC monitor construct](/constructs/grpc-monitor). -## What are gRPC Monitors? +## What are gRPC monitors? gRPC monitors verify that your gRPC services are reachable, healthy, and responding correctly. They support two monitoring modes: @@ -23,7 +23,7 @@ Typical use cases include: * Checking that a service starts serving requests after a deployment * Asserting that gRPC status codes and response payloads meet expectations -## How gRPC Monitors Work +## How gRPC monitors work On each run, Checkly: @@ -35,7 +35,7 @@ On each run, Checkly: * **HEALTH mode**: Calls `Check` on `grpc.health.v1.Health`, optionally scoped to a specific service name 5. Evaluates your configured assertions against the response (status code, health status, response message, metadata, or response time) -## gRPC Monitor Results +## gRPC monitor results Select a specific check run to inspect its results: diff --git a/detect/uptime-monitoring/heartbeat-monitors/examples.mdx b/detect/uptime-monitoring/heartbeat-monitors/examples.mdx index 40dc1aaf..4fae5ca4 100644 --- a/detect/uptime-monitoring/heartbeat-monitors/examples.mdx +++ b/detect/uptime-monitoring/heartbeat-monitors/examples.mdx @@ -21,7 +21,7 @@ Checkly records that a ping arrived, plus its `User-Agent` and `Origin` or `Refe ### Basic cURL Examples -The most common way to ping heartbeat monitors from shell scripts: +The most common way to ping Heartbeat monitors from shell scripts: ```bash GET Request diff --git a/detect/uptime-monitoring/heartbeat-monitors/overview.mdx b/detect/uptime-monitoring/heartbeat-monitors/overview.mdx index f91f71f2..e4609549 100644 --- a/detect/uptime-monitoring/heartbeat-monitors/overview.mdx +++ b/detect/uptime-monitoring/heartbeat-monitors/overview.mdx @@ -1,15 +1,15 @@ --- -title: Heartbeat Monitors +title: Heartbeat monitors description: Ensure your automated processes are running as expected. sidebarTitle: Overview canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/heartbeat-monitors/overview/' --- -**Monitoring as Code**: Learn more about the [Heartbeat Monitor Construct](/constructs/heartbeat-monitor). +**Monitoring as Code**: Learn more about the [Heartbeat monitor construct](/constructs/heartbeat-monitor). -Monitor your scheduled jobs, background tasks, and automated processes with Checkly's heartbeat monitoring. Unlike traditional active monitoring, heartbeat monitors work passively—they listen for regular "pings" from your tasks to ensure they're running as expected. +Monitor your scheduled jobs, background tasks, and automated processes with Checkly's heartbeat monitoring. Unlike traditional active monitoring, Heartbeat monitors work passively—they listen for regular "pings" from your tasks to ensure they're running as expected. -## What are Heartbeat Monitors? +## What are Heartbeat monitors? Heartbeat monitors are passive monitoring checks that wait for your automated tasks to report their successful completion. When your scheduled job, backup script, or cron job finishes successfully, it sends a simple HTTP request (a "ping") to Checkly to confirm it ran. @@ -40,11 +40,11 @@ Heartbeat monitors are perfect for: - Database cleanup tasks - File processing workflows -## How Heartbeat Monitoring Works +## How heartbeat monitoring works -The heartbeat monitoring process is straightforward. Once created, your heartbeat monitor provides a unique ping URL. Your tasks should make an HTTP GET or POST request to this URL when they complete successfully. +The heartbeat monitoring process is straightforward. Once created, your Heartbeat monitor provides a unique ping URL. Your tasks should make an HTTP GET or POST request to this URL when they complete successfully. -1. **Create a monitor** - Set up a heartbeat monitor with your expected ping frequency +1. **Create a monitor** - Set up a Heartbeat monitor with your expected ping frequency 2. **Get your ping URL** - Checkly provides a unique URL for your task to ping 3. **Add the ping** - Include a simple HTTP request in your task's success path 4. **Monitor results** - Checkly tracks pings and alerts you if a ping is missed or delayed @@ -97,7 +97,7 @@ You can manually send pings via the Checkly UI. Use this to start the check time ![Manually send a ping via the Checkly UI in the quick menu](/images/docs/images/heartbeat-checks/heartbeat-ping-quick-menu.png) -## Heartbeat Monitor Results +## Heartbeat monitor results Heartbeat monitor results show information about the ping request, like when it was recieved and its source. diff --git a/detect/uptime-monitoring/heartbeat-monitors/quickstart.mdx b/detect/uptime-monitoring/heartbeat-monitors/quickstart.mdx index 3fbdb5e7..5de0cf0a 100644 --- a/detect/uptime-monitoring/heartbeat-monitors/quickstart.mdx +++ b/detect/uptime-monitoring/heartbeat-monitors/quickstart.mdx @@ -1,15 +1,15 @@ --- -title: 'Creating A Heartbeat Monitor' -description: 'Step-by-step guide to set up your first heartbeat monitor in Checkly. Learn about configuration, timing, alerts, and best practices.' +title: 'Creating a Heartbeat monitor' +description: 'Step-by-step guide to set up your first Heartbeat monitor in Checkly. Learn about configuration, timing, alerts, and best practices.' sidebarTitle: 'Quickstart' canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/heartbeat-monitors/quickstart/' --- -Learn more about all the [Heartbeat Monitor capabilities](/detect/uptime-monitoring/heartbeat-monitors/overview) in the general overview. +Learn more about all the [Heartbeat monitor capabilities](/detect/uptime-monitoring/heartbeat-monitors/overview) in the general overview. -Follow this comprehensive guide to create your first heartbeat monitor in Checkly. We'll walk through each configuration step and explain the best practices to ensure your monitoring is effective. +Follow this comprehensive guide to create your first Heartbeat monitor in Checkly. We'll walk through each configuration step and explain the best practices to ensure your monitoring is effective. -Before creating your heartbeat monitor, make sure you have: +Before creating your Heartbeat monitor, make sure you have: - A Checkly account. Heartbeat monitors are available on all plans; see [pricing](https://www.checklyhq.com/pricing/) for limits - A scheduled job, script, or automated process you want to monitor @@ -41,7 +41,7 @@ Use tags to group related monitors and make them easier to find and manage. ## Step 2: Timing Configuration -The timing configuration is the heart of your heartbeat monitor. You need to specify when you expect pings and how much flexibility to allow. +The timing configuration is the heart of your Heartbeat monitor. You need to specify when you expect pings and how much flexibility to allow. ### Period Setting @@ -51,7 +51,7 @@ The **period** defines how often your task should ping Checkly: - **Weekly jobs**: Set to 7 days - **Hourly jobs**: Set to 1 hour -![Configure period and grace settings for your heartbeat monitor](/images/heartbeat-monitors/getting-started-period-and-grace.png) +![Configure period and grace settings for your Heartbeat monitor](/images/heartbeat-monitors/getting-started-period-and-grace.png) ### Grace Period @@ -106,9 +106,9 @@ This means if your job is supposed to run every 6 hours but runs late at hour 7, ## Step 3: Alert Configuration -Connect your heartbeat monitor to [alert channels](/communicate/alerts/overview) to be notified when pings are missing. +Connect your Heartbeat monitor to [alert channels](/communicate/alerts/overview) to be notified when pings are missing. -### Choosing Alert Channels +### Choosing alert channels **For immediate awareness:** - **Email notifications** - Good for individual monitoring @@ -135,12 +135,12 @@ All alert channels subscribed to the monitor are notified at the same time. ## Step 4: Ping URL and Implementation -Once created, your heartbeat monitor provides a unique ping URL. Your tasks should make an HTTP `GET` or `POST` request to this URL when they complete successfully. +Once created, your Heartbeat monitor provides a unique ping URL. Your tasks should make an HTTP `GET` or `POST` request to this URL when they complete successfully. ## Step 5: Testing Your Setup -Before deploying to production, test your heartbeat monitor: +Before deploying to production, test your Heartbeat monitor: ### Manual Testing diff --git a/detect/uptime-monitoring/icmp-monitors/configuration.mdx b/detect/uptime-monitoring/icmp-monitors/configuration.mdx index 8bff33e7..514b4203 100644 --- a/detect/uptime-monitoring/icmp-monitors/configuration.mdx +++ b/detect/uptime-monitoring/icmp-monitors/configuration.mdx @@ -1,5 +1,5 @@ --- -title: 'ICMP Monitor Configuration' +title: 'ICMP monitor configuration' description: 'Configure your ICMP monitor to verify host reachability and measure network latency.' sidebarTitle: 'Configuration' canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/icmp-monitors/configuration/' diff --git a/detect/uptime-monitoring/icmp-monitors/overview.mdx b/detect/uptime-monitoring/icmp-monitors/overview.mdx index a6b5b4fe..eaf2869e 100644 --- a/detect/uptime-monitoring/icmp-monitors/overview.mdx +++ b/detect/uptime-monitoring/icmp-monitors/overview.mdx @@ -1,11 +1,11 @@ --- -title: 'ICMP Monitors Overview' +title: 'ICMP monitors overview' description: 'Monitor host reachability and network latency using ICMP ping.' sidebarTitle: Overview canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/icmp-monitors/overview/' --- -**Monitoring as Code**: Learn more about the [ICMP Monitor Construct](/constructs/icmp-monitor). +**Monitoring as Code**: Learn more about the [ICMP monitor construct](/constructs/icmp-monitor). @@ -23,7 +23,7 @@ canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/icmp-monitor /> -## What are ICMP Monitors? +## What are ICMP monitors? ICMP monitors check if a host is reachable by sending ICMP Echo Requests (pings). Typical use cases include: @@ -55,7 +55,7 @@ round-trip min/avg/max/stddev = 6.573/20.993/49.812/24.958 ms The response appears on the results page as both raw output and parsed JSON. You can use it as a reference to define [assertions](/detect/uptime-monitoring/icmp-monitors/configuration#assertions) for expected values. -## ICMP Monitor Results +## ICMP monitor results Select a specific check run to inspect its results: diff --git a/detect/uptime-monitoring/overview.mdx b/detect/uptime-monitoring/overview.mdx index b08cd10f..d55bb1d9 100644 --- a/detect/uptime-monitoring/overview.mdx +++ b/detect/uptime-monitoring/overview.mdx @@ -22,32 +22,32 @@ Uptime monitoring is essential for ensuring your applications are always availab ## Types of Uptime Monitors Choose the Uptime Monitor that best fits your monitoring needs: - + Monitor the availability and performance of a specific URL or public endpoint. - + Monitor the availability and performance of TCP connections. - + Verify that DNS records resolve successfully and return the expected values. - + Verify host reachability and measure packet loss. - + Monitor gRPC service availability, health, and response correctness. - + Detect when cron jobs or scheduled tasks fail to run. diff --git a/detect/uptime-monitoring/ssl-monitors/configuration.mdx b/detect/uptime-monitoring/ssl-monitors/configuration.mdx index 978f1142..490e5449 100644 --- a/detect/uptime-monitoring/ssl-monitors/configuration.mdx +++ b/detect/uptime-monitoring/ssl-monitors/configuration.mdx @@ -1,12 +1,12 @@ --- -title: 'SSL Monitor Configuration' +title: 'SSL monitor configuration' description: 'Configure your SSL monitor to track certificate health, expiry, and TLS security posture.' sidebarTitle: 'Configuration' canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/ssl-monitors/configuration/' --- -To configure an SSL monitor using code, learn more about the [SSL Monitor Construct](/constructs/ssl-monitor). +To configure an SSL monitor using code, learn more about the [SSL monitor construct](/constructs/ssl-monitor). ### Basic Setup diff --git a/detect/uptime-monitoring/ssl-monitors/overview.mdx b/detect/uptime-monitoring/ssl-monitors/overview.mdx index 00ad370b..e6e41071 100644 --- a/detect/uptime-monitoring/ssl-monitors/overview.mdx +++ b/detect/uptime-monitoring/ssl-monitors/overview.mdx @@ -1,15 +1,15 @@ --- -title: 'SSL Monitor Overview' +title: 'SSL monitor overview' description: 'Monitor TLS certificate health, expiry, and security posture of your HTTPS endpoints.' sidebarTitle: Overview canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/ssl-monitors/overview/' --- -**Monitoring as Code**: Learn more about the [SSL Monitor Construct](/constructs/ssl-monitor). +**Monitoring as Code**: Learn more about the [SSL monitor construct](/constructs/ssl-monitor). -## What are SSL Monitors? +## What are SSL monitors? SSL monitors verify the health of a TLS certificate by connecting to a hostname, completing a full TLS handshake, and inspecting the resulting certificate and negotiated protocol parameters. Typical use cases include: @@ -19,7 +19,7 @@ SSL monitors verify the health of a TLS certificate by connecting to a hostname, * Catching chain trust failures caused by missing intermediate certificates * Alerting on weak or compromised certificate authority usage -## How do SSL Monitors work? +## How do SSL monitors work? Each SSL monitor run performs the following steps: @@ -30,7 +30,7 @@ Each SSL monitor run performs the following steps: 5. **Security baseline evaluation** — On a successful handshake and certificate verification, a configurable rule set evaluates the negotiated protocol (TLS version, cipher suite, CA trust) and produces a per-rule verdict plus an overall **grade** and **verdict** (`pass` / `warn` / `fail`). The baseline is skipped when an earlier step fails (e.g. hostname mismatch or chain untrusted). 6. **Assertions** — Optional assertions are evaluated against the certificate and handshake data -## SSL Monitor Results +## SSL monitor results Select a specific check run to inspect its results: diff --git a/detect/uptime-monitoring/tcp-monitors/configuration.mdx b/detect/uptime-monitoring/tcp-monitors/configuration.mdx index 0a9c2945..5925e19e 100644 --- a/detect/uptime-monitoring/tcp-monitors/configuration.mdx +++ b/detect/uptime-monitoring/tcp-monitors/configuration.mdx @@ -1,12 +1,12 @@ --- -title: 'TCP Monitor Configuration' +title: 'TCP monitor configuration' description: 'Configure your TCP monitor to ensure TCP services are reachable and responding as expected.' sidebarTitle: 'Configuration' canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/tcp-monitors/configuration/' --- -To configure a TCP monitor using code, learn more about the [TCP Monitor Construct](/constructs/tcp-monitor). +To configure a TCP monitor using code, learn more about the [TCP monitor construct](/constructs/tcp-monitor). ### Basic Setup diff --git a/detect/uptime-monitoring/tcp-monitors/overview.mdx b/detect/uptime-monitoring/tcp-monitors/overview.mdx index 815c6711..db8c63a2 100644 --- a/detect/uptime-monitoring/tcp-monitors/overview.mdx +++ b/detect/uptime-monitoring/tcp-monitors/overview.mdx @@ -1,15 +1,15 @@ --- -title: 'TCP Monitors Overview' +title: 'TCP monitors overview' description: 'Monitor the availability and performance of your TCP services.' sidebarTitle: Overview canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/tcp-monitors/overview/' --- -**Monitoring as Code**: Learn more about the [TCP Monitor Construct](/constructs/tcp-monitor). +**Monitoring as Code**: Learn more about the [TCP monitor construct](/constructs/tcp-monitor). -## What are TCP Monitors? +## What are TCP monitors? Use TCP monitors to verify that your non-HTTP services are working as expected. TCP monitors work by establishing a connection to a host and port, then checking the speed and validity of the response. @@ -34,7 +34,7 @@ For example, use these checks to verify that: /> -## How TCP Monitoring Works +## How TCP monitoring works TCP monitors perform connection-level checks: @@ -42,7 +42,7 @@ TCP monitors perform connection-level checks: 2. **Port Verification** - Confirms the service is listening on the specified port 3. **Response Validation** - Optionally validates service responses based on your configured assertions -## TCP Monitor Results +## TCP monitor results Select a specific check run to review its results: @@ -72,7 +72,7 @@ This happens because [AWS blocks outbound traffic on port 25 by default to preve **Workarounds:** -* Run the check from a [Private Location](/platform/private-locations/overview) where port 25 is allowed +* Run the check from a [private location](/platform/private-locations/overview) where port 25 is allowed * Use an alternative SMTP port such as 587 or 465 if supported diff --git a/detect/uptime-monitoring/tcp-monitors/quickstart.mdx b/detect/uptime-monitoring/tcp-monitors/quickstart.mdx index 28312ca7..1d4700c6 100644 --- a/detect/uptime-monitoring/tcp-monitors/quickstart.mdx +++ b/detect/uptime-monitoring/tcp-monitors/quickstart.mdx @@ -1,12 +1,12 @@ --- -title: 'Creating A TCP Monitor' +title: 'Creating a TCP monitor' description: 'Step-by-step guide to set up your first TCP monitor and ensure your network services are always available.' sidebarTitle: 'Quickstart' canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/tcp-monitors/quickstart/' --- -Learn more about all the [TCP Monitor capabilities](/detect/uptime-monitoring/tcp-monitors/overview) in the general overview. +Learn more about all the [TCP monitor capabilities](/detect/uptime-monitoring/tcp-monitors/overview) in the general overview. This guide walks you through creating your first TCP monitor to check the availability of your network services, databases, or any TCP-based application. diff --git a/detect/uptime-monitoring/traceroute-monitors/configuration.mdx b/detect/uptime-monitoring/traceroute-monitors/configuration.mdx index de734c41..7830d924 100644 --- a/detect/uptime-monitoring/traceroute-monitors/configuration.mdx +++ b/detect/uptime-monitoring/traceroute-monitors/configuration.mdx @@ -1,12 +1,12 @@ --- -title: 'Traceroute Monitor Configuration' +title: 'Traceroute monitor configuration' description: 'Configure your Traceroute monitor to map network paths and detect routing issues, latency, and packet loss.' sidebarTitle: 'Configuration' canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/traceroute-monitors/configuration/' --- -To configure a Traceroute monitor using code, learn more about the [Traceroute Monitor Construct](/constructs/traceroute-monitor). +To configure a Traceroute monitor using code, learn more about the [Traceroute monitor construct](/constructs/traceroute-monitor). ### Basic Setup diff --git a/detect/uptime-monitoring/traceroute-monitors/overview.mdx b/detect/uptime-monitoring/traceroute-monitors/overview.mdx index f358fef6..11b2ae5d 100644 --- a/detect/uptime-monitoring/traceroute-monitors/overview.mdx +++ b/detect/uptime-monitoring/traceroute-monitors/overview.mdx @@ -1,15 +1,15 @@ --- -title: 'Traceroute Monitors Overview' +title: 'Traceroute monitors overview' description: 'Map the network path to any host and detect routing issues, high-latency hops, and packet loss.' sidebarTitle: Overview canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/traceroute-monitors/overview/' --- -**Monitoring as Code**: Learn more about the [Traceroute Monitor Construct](/constructs/traceroute-monitor). +**Monitoring as Code**: Learn more about the [Traceroute monitor construct](/constructs/traceroute-monitor). -## What are Traceroute Monitors? +## What are Traceroute monitors? Traceroute monitors map the network path between a Checkly location and your target host, recording every router hop along the way and measuring per-hop latency and packet loss. Typical use cases include: @@ -18,7 +18,7 @@ Traceroute monitors map the network path between a Checkly location and your tar * Verifying that the destination is reachable end-to-end, beyond just confirming that a port accepts connections * Continuously monitoring path stability across regions over time -## How do Traceroute Monitors work? +## How do Traceroute monitors work? A Traceroute monitor executes the following steps on each run: @@ -41,7 +41,7 @@ A Traceroute monitor executes the following steps on each run: The default port is protocol-dependent everywhere — web UI, CLI, and API: `443` for TCP and `33434` for UDP/SCTP. `33434` is a high, typically-closed port: UDP and SCTP arrival is only confirmed when the destination returns an ICMP Destination Unreachable, which requires the probed port to be closed. Avoid setting an open port (like `443`) for UDP/SCTP probes — it would never confirm arrival. -## Traceroute Monitor Results +## Traceroute monitor results Select a specific check run to inspect its results: @@ -73,7 +73,7 @@ Learn more in our documentation on [Results](/concepts/results). **How to fix**: 1. Switch the probe protocol — try `ICMP` if the host responds to ping, or `UDP` for a connectionless probe 2. For TCP probes, change the port to one that is explicitly open on the target (e.g. `80` or `22`). For UDP/SCTP, keep a *closed* port — arrival is only confirmed by an ICMP Destination Unreachable reply -3. Confirm reachability at the application layer with an [API Monitor](/detect/synthetic-monitoring/overview) or [TCP Monitor](/detect/uptime-monitoring/tcp-monitors/overview) targeting the same host and port +3. Confirm reachability at the application layer with an [API Monitor](/detect/synthetic-monitoring/overview) or [TCP monitor](/detect/uptime-monitoring/tcp-monitors/overview) targeting the same host and port diff --git a/detect/uptime-monitoring/url-monitors/configuration.mdx b/detect/uptime-monitoring/url-monitors/configuration.mdx index a14ef7fe..230da618 100644 --- a/detect/uptime-monitoring/url-monitors/configuration.mdx +++ b/detect/uptime-monitoring/url-monitors/configuration.mdx @@ -1,5 +1,5 @@ --- -title: 'URL Monitor Configuration' +title: 'URL monitor configuration' description: 'Configure your URL monitor to ensure your HTTP-based services are always available.' sidebarTitle: 'Configuration' canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/url-monitors/configuration/' @@ -129,7 +129,7 @@ Configure follow-up alerts after initial failure notification: | **Maximum reminders** | Number of follow-up alerts (0 = no reminders) | | **Reminder interval** | Time between reminders (only if maximum reminders > 0) | -#### Alert Channels +#### Alert channels Define where notifications are sent when checks fail or recover. Additional channels can be configured in global notification settings. diff --git a/detect/uptime-monitoring/url-monitors/overview.mdx b/detect/uptime-monitoring/url-monitors/overview.mdx index 09fbd58d..70491a21 100644 --- a/detect/uptime-monitoring/url-monitors/overview.mdx +++ b/detect/uptime-monitoring/url-monitors/overview.mdx @@ -1,14 +1,14 @@ --- -title: 'URL Monitors Overview' +title: 'URL monitors overview' description: 'Monitor websites and apps to verify their availability and performance.' sidebarTitle: Overview canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/url-monitors/overview/' --- -**Monitoring as Code**: Learn more about the [URL Monitor Construct](/constructs/url-monitor). +**Monitoring as Code**: Learn more about the [URL monitor construct](/constructs/url-monitor). -## What are URL Monitors? +## What are URL monitors? URL monitors track the availability of your HTTP-based services by sending requests to specified URLs and validating avaliability and performance. @@ -34,7 +34,7 @@ URL monitors track the availability of your HTTP-based services by sending reque * Checking that your SSL certificate is still valid * Confirming that a public pricing endpoint is reachable for customers -## How URL Monitors Work +## How URL monitors work URL monitors send HTTP requests to specified URLs and validate availability and performance. They can be configured to check for specific status codes and response times while running from multiple global locations. @@ -61,7 +61,7 @@ Schedule your monitor to run at the frequency you want. -## URL Monitor Results +## URL monitor results URL monitor results show details about each request and help you understand if your endpoint was available and performing as expected at the time of the check. @@ -102,5 +102,5 @@ Learn more in our documentation on [Results](/concepts/results). -For monitoring as code workflows, use the URL Monitor construct to version control your monitoring configuration and deploy alongside your application code. [Learn about URL Monitor Construct →](/constructs/url-monitor) +For monitoring as code workflows, use the URL monitor construct to version control your monitoring configuration and deploy alongside your application code. [Learn about URL monitor construct →](/constructs/url-monitor) diff --git a/detect/uptime-monitoring/url-monitors/quickstart.mdx b/detect/uptime-monitoring/url-monitors/quickstart.mdx index a290a65e..6abd5fb5 100644 --- a/detect/uptime-monitoring/url-monitors/quickstart.mdx +++ b/detect/uptime-monitoring/url-monitors/quickstart.mdx @@ -1,12 +1,12 @@ --- -title: 'Creating A URL Monitor' +title: 'Creating a URL monitor' description: 'Step-by-step guide to set up your first URL monitor and ensure your websites and APIs are always accessible.' sidebarTitle: 'Quickstart' canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/url-monitors/quickstart/' --- -Learn more about all the [URL Monitor capabilities](/detect/uptime-monitoring/url-monitors/overview) in the general overview. +Learn more about all the [URL monitor capabilities](/detect/uptime-monitoring/url-monitors/overview) in the general overview. This guide walks you through creating your first URL monitor to check the availability and performance of your websites, APIs, or any HTTP-based service. diff --git a/guides/agentic-workflows.mdx b/guides/agentic-workflows.mdx index 6c00099e..a1d6eece 100644 --- a/guides/agentic-workflows.mdx +++ b/guides/agentic-workflows.mdx @@ -241,7 +241,7 @@ new UrlMonitor("base-url-monitor", { ## Set up API monitoring -For a solid monitoring strategy uptime monitoring is only the first step. [API Checks](/detect/synthetic-monitoring/api-checks/overview) go beyond uptime monitoring by validating response payloads with assertions. +For a solid monitoring strategy uptime monitoring is only the first step. [API checks](/detect/synthetic-monitoring/api-checks/overview) go beyond uptime monitoring by validating response payloads with assertions. To create complex assertions, target AI to analyze your source code to generate meaningful assertions automatically. diff --git a/guides/claude-code-monitoring.mdx b/guides/claude-code-monitoring.mdx index d56dc0c6..42b43388 100644 --- a/guides/claude-code-monitoring.mdx +++ b/guides/claude-code-monitoring.mdx @@ -2,7 +2,7 @@ title: In-Depth Monitoring With Checkly and Claude Code sidebarTitle: Using Checkly and Claude Code description: - By integrating AI into your development workflow, you can generate valid Checkly constructs—including URL monitors and Playwright-based browser checks—with minimal effort. + By integrating AI into your development workflow, you can generate valid Checkly constructs—including URL monitors and Playwright-based Browser checks—with minimal effort. author: Nočnica Mellifera avatar: 'images/avatars/nica-mellifera.png' tags: @@ -58,7 +58,7 @@ npx checkly skills install --target claude After this you'll need to exit and restart Claude Code for it to pick up the skill. -## Create new URL Monitors +## Create new URL monitors We'll start with something easy. A URL monitor that will check an HTTP endpoint and alert if it doesn't receive the right status code. With the context set from the section above, try a command like: @@ -147,7 +147,7 @@ __checks__/book-detail-visibility.spec.ts *Like always with the `checkly test` command, this test isn't running from our workstation but rather from the Checkly's monitoring infrastructure.* -Next we'll want to create a `.check.ts` file for this browser check, which sets some check-specific settings and assigns the check's logical ID. +Next we'll want to create a `.check.ts` file for this Browser check, which sets some check-specific settings and assigns the check's logical ID. ```{title="Prompt:"} Write a .check.ts file for book-detail-visibility that runs the check from a US and EU region and defines a linear retry strategy. @@ -224,7 +224,7 @@ With this check created, let's add the following lines to your updated `CLAUDE.m Pro tip: from the Claude Code prompt, just hit octothorp "#" to add to Claude's memory. Each entry will be a new line in `CLAUDE.md`. -### 3. Use Claude Code to create multiple Browser Checks +### 3. Use Claude Code to create multiple Browser checks Now that we've got a working test and, let's let Claude Code create another check for us: @@ -379,7 +379,7 @@ Once we're happy with what will be deployed, it's time to run `npx checkly deplo ## Conclusion -AI-assisted coding tools like Claude Code can significantly accelerate the creation and deployment of monitoring checks with Checkly's Monitoring as Code approach. By integrating AI into your development workflow, you can generate valid Checkly constructs—including URL monitors and Playwright-based browser checks—with minimal effort. One of the superpowers that an AI workflow can unlock is the *mass updating of many files in your project.* Updating a large number of test files can go much faster with the help of Claude Code. +AI-assisted coding tools like Claude Code can significantly accelerate the creation and deployment of monitoring checks with Checkly's Monitoring as Code approach. By integrating AI into your development workflow, you can generate valid Checkly constructs—including URL monitors and Playwright-based Browser checks—with minimal effort. One of the superpowers that an AI workflow can unlock is the *mass updating of many files in your project.* Updating a large number of test files can go much faster with the help of Claude Code. While AI can handle much of the boilerplate work, human oversight remains essential for ensuring best practices, refining assertions, and maintaining high-quality monitoring scripts. By combining AI efficiency with developer expertise, teams can achieve comprehensive monitoring coverage in minutes rather than days. @@ -399,7 +399,7 @@ To learn more about Checkly's capabilities, explore these resources: - [Generating end-to-end tests with AI and Playwright MCP](https://www.checklyhq.com/blog/generate-end-to-end-tests-with-ai-and-playwright/) - Stefan's blog post makes a great starter for generalized Playwright development with an AI toolkit. - [Checkly CLI Documentation](/cli/overview) – Learn how to manage checks as code right from your command line. -- [Playwright Testing Guide](https://www.checklyhq.com/learn/playwright/) – Best practices for writing reliable browser checks. +- [Playwright Testing Guide](https://www.checklyhq.com/learn/playwright/) – Best practices for writing reliable Browser checks. - [What is monitoring as code?](https://www.checklyhq.com/guides/monitoring-as-code/) — A comprehensive guide to infrastructure-as-code principles for monitoring. - [Checkly Community Slack](https://checklyhq.com/slack) – Join discussions and get support from the Checkly team and other users. diff --git a/guides/communicate-availability.mdx b/guides/communicate-availability.mdx index 571c628d..55c4c38a 100644 --- a/guides/communicate-availability.mdx +++ b/guides/communicate-availability.mdx @@ -1,6 +1,6 @@ --- title: A status page backed by real monitors -sidebarTitle: Build Real-Time Status Pages +sidebarTitle: Build real-time status pages description: Build a public status page in code whose components go red when the checks that test them fail, and read and update its incidents from your coding agent with the Checkly MCP server. canonical: 'https://www.checklyhq.com/docs/guides/communicate-availability/' --- @@ -50,7 +50,7 @@ A status page is only as honest as what drives it. Drive each component with a c The tag on each check is the contract between the check and the status page. Use one tag per component, and do not reuse it for anything else. -The storefront component is backed by a search flow. Run it as a Playwright Check Suite or a Browser Check. Both use the same test file: +The storefront component is backed by a search flow. Run it as a Playwright Check Suite or a Browser check. Both use the same test file: diff --git a/guides/global-monitoring.mdx b/guides/global-monitoring.mdx index 9f21ada2..80eebd8f 100644 --- a/guides/global-monitoring.mdx +++ b/guides/global-monitoring.mdx @@ -203,7 +203,7 @@ In a parallel check, every location runs at every interval, and each one is a ch | Homepage from around the world | 13 | 5 minutes | 156 | | Checkout from three continents | 3 | 10 minutes | 18 | -Spend the width where it is cheap. URL, TCP, DNS, and ICMP monitors run in milliseconds, so run them from the core set or wider: they are what finds a regional path problem. API checks follow the core set. Browser checks and Playwright check suites take seconds to minutes per run, so one location per continent with meaningful revenue is enough to prove the flow works there. +Spend the width where it is cheap. URL, TCP, DNS, and ICMP monitors run in milliseconds, so run them from the core set or wider: they are what finds a regional path problem. API checks follow the core set. Browser checks and Playwright Check Suites take seconds to minutes per run, so one location per continent with meaningful revenue is enough to prove the flow works there. Even three locations create more chances for one noisy path to page someone. Two settings turn that around. Retry in the same region, so a flaky path is confirmed rather than papered over. Then alert only when a percentage of locations agree. diff --git a/guides/keyword-monitoring.mdx b/guides/keyword-monitoring.mdx index f4099c01..c9ac8ec7 100644 --- a/guides/keyword-monitoring.mdx +++ b/guides/keyword-monitoring.mdx @@ -108,7 +108,7 @@ Adding `.first()` makes the error go away and the check useless: it passes as lo ## Step 3: Run it on a schedule -Run the test as a Playwright Check Suite, or as a Browser Check if you prefer one file per check. Both use the same spec file. +Run the test as a Playwright Check Suite, or as a Browser check if you prefer one file per check. Both use the same spec file. @@ -209,7 +209,7 @@ Change the title back before you deploy again. ## Reference -- [Playwright Check Suites](/detect/synthetic-monitoring/playwright-checks/overview) and [Browser Checks](/detect/synthetic-monitoring/browser-checks/overview) +- [Playwright Check Suites](/detect/synthetic-monitoring/playwright-checks/overview) and [Browser checks](/detect/synthetic-monitoring/browser-checks/overview) - [Assertions in Playwright](/learn/playwright/assertions) and [locators](/learn/playwright/selectors) - [`BrowserCheck`](/constructs/browser-check) and [project configuration](/constructs/project) - [Checkly Skills](/ai/skills) diff --git a/guides/monitoring-an-openapi-spec.mdx b/guides/monitoring-an-openapi-spec.mdx index cfe52fdb..ea3ab3fa 100644 --- a/guides/monitoring-an-openapi-spec.mdx +++ b/guides/monitoring-an-openapi-spec.mdx @@ -242,7 +242,7 @@ As we look to increase our endpoint coverage across our APIs, we might want to e - Learn end-to-end monitoring with puppeteer and playwright to test key website flows. + Learn end-to-end monitoring with puppeteer and Playwright to test key website flows. diff --git a/guides/monitoring-ecommerce-apps-using-playwright.mdx b/guides/monitoring-ecommerce-apps-using-playwright.mdx index 707d1cd4..fe6459f9 100644 --- a/guides/monitoring-ecommerce-apps-using-playwright.mdx +++ b/guides/monitoring-ecommerce-apps-using-playwright.mdx @@ -180,7 +180,7 @@ export default defineConfig({ ## Step 4: Define the monitor -Install the CLI if this repository does not have it yet, then describe the monitor next to your Playwright config. A Playwright Check Suite runs the whole suite with your config and shows one test case per spec. A Browser Check runs a single spec file on its own. Pick one. +Install the CLI if this repository does not have it yet, then describe the monitor next to your Playwright config. A Playwright Check Suite runs the whole suite with your config and shows one test case per spec. A Browser check runs a single spec file on its own. Pick one. ```bash Terminal npm install --save-dev checkly @@ -239,7 +239,7 @@ new BrowserCheck('shop-checkout-browser-check', { -The base URL is a check-level environment variable in both paths. A staging monitor is the same entry with a different `SHOP_URL`, and the tests never change. The Browser Check path needs a copy of the checkout spec that opens `process.env.SHOP_URL` itself, kept in `checks/checkout.spec.ts` in the sample. +The base URL is a check-level environment variable in both paths. A staging monitor is the same entry with a different `SHOP_URL`, and the tests never change. The Browser check path needs a copy of the checkout spec that opens `process.env.SHOP_URL` itself, kept in `checks/checkout.spec.ts` in the sample. ## Step 5: Run it on Checkly, then deploy @@ -290,7 +290,7 @@ The suite now runs every ten minutes from both locations, and every later deploy ## Same thing in Terraform -If your team manages infrastructure with Terraform, the checkout flow is one `checkly_check` resource: a Browser Check with the self-contained spec and the same `SHOP_URL` variable. +If your team manages infrastructure with Terraform, the checkout flow is one `checkly_check` resource: a Browser check with the self-contained spec and the same `SHOP_URL` variable. ```terraform terraform/main.tf # Provider block as in the Terraform overview, then: diff --git a/guides/monitoring-ecommerce-apps-using-terraform.mdx b/guides/monitoring-ecommerce-apps-using-terraform.mdx index 9accea63..88e57a86 100644 --- a/guides/monitoring-ecommerce-apps-using-terraform.mdx +++ b/guides/monitoring-ecommerce-apps-using-terraform.mdx @@ -1,14 +1,14 @@ --- title: Monitor a shop with Terraform sidebarTitle: Monitoring a Shop with Terraform -description: Declare a shop's whole monitoring stack in Terraform with the Checkly provider, from the alert channel and check group to Browser Checks loaded from spec files and an API check with body assertions. +description: Declare a shop's whole monitoring stack in Terraform with the Checkly provider, from the alert channel and check group to Browser checks loaded from spec files and an API check with body assertions. canonical: 'https://www.checklyhq.com/docs/guides/monitoring-ecommerce-apps-using-terraform/' --- import GuideAgentIntro from '/snippets/guide-agent-intro.mdx' import { CopyPromptButton } from '/snippets/copy-prompt-button.jsx' -By the end of this guide, your shop's monitoring lives in five Terraform resources: an email alert channel, a check group that owns locations, retries, and alerting, two Browser Checks loaded from Playwright spec files, and an API check that asserts on the response body. +By the end of this guide, your shop's monitoring lives in five Terraform resources: an email alert channel, a check group that owns locations, retries, and alerting, two Browser checks loaded from Playwright spec files, and an API check that asserts on the response body. ```text Terminal # checkly_alert_channel.shop_email will be created @@ -182,9 +182,9 @@ resource "checkly_check_group_v2" "shop" { `checkly_check_group_v2` changes nothing about its checks unless you ask it to. Each `enforce_` block you add takes that setting away from the checks and applies the group's value instead. Here the group runs every check from N. Virginia and Ireland in parallel, retries a failed run up to twice from a different region, and emails you as soon as one run still fails after its retries. -The `SHOP_URL` variable reaches every Browser Check in the group. Point the whole stack at a staging shop with `terraform plan -var="shop_url="`, without touching a check. +The `SHOP_URL` variable reaches every Browser check in the group. Point the whole stack at a staging shop with `terraform plan -var="shop_url="`, without touching a check. -## Step 4: Monitor the shop's flows with Browser Checks +## Step 4: Monitor the shop's flows with Browser checks Keep each flow in its own Playwright spec file. The file is the check's script, and you can run it locally before Terraform ever sees it. @@ -244,7 +244,7 @@ Running 2 tests using 2 workers 2 passed (1.3s) ``` -Now turn every spec into a check. A `for_each` over a map creates one Browser Check per entry, and `file()` reads the spec as the check's script: +Now turn every spec into a check. A `for_each` over a map creates one Browser check per entry, and `file()` reads the spec as the check's script: ```terraform browser.tf # One Browser Check per spec file in scripts/. To monitor another flow, diff --git a/guides/monitoring-the-stripe-api.mdx b/guides/monitoring-the-stripe-api.mdx index 4ff985be..7bfdac8b 100644 --- a/guides/monitoring-the-stripe-api.mdx +++ b/guides/monitoring-the-stripe-api.mdx @@ -13,7 +13,7 @@ canonical: 'https://www.checklyhq.com/docs/guides/monitoring-the-stripe-api/' ## The rise of APIs -With the rise of the [Jamstack](https://jamstack.org/), the already broadly used web APIs have been brought further into the spotlight and explicitly named as cornerstone of a new way of building web applications. In the Jamstack paradigm, applications rely on APIs returning structured data (JSON or XML) when queried via a build process or Javascript-based frontend. +With the rise of the [Jamstack](https://jamstack.org/), the already broadly used web APIs have been brought further into the spotlight and explicitly named as cornerstone of a new way of building web applications. In the Jamstack paradigm, applications rely on APIs returning structured data (JSON or XML) when queried via a build process or JavaScript-based frontend. The API calls might be aimed at internal services or at third-parties handling complex flows such as content management, authentication, merchant services and more. An example of third-party API could be [Stripe](https://stripe.com/), which acts as payment infrastructure for a multitude of businesses. @@ -73,7 +73,7 @@ curl https://api.stripe.com/v1/customers \ -G ``` -If we chose to set up a call using Javascript, for example, we could achieve the same call as in the first case above using [axios](https://github.com/axios/axios): +If we chose to set up a call using JavaScript, for example, we could achieve the same call as in the first case above using [axios](https://github.com/axios/axios): ```js Stripe.js const { default: axios } = require("axios"); @@ -346,7 +346,7 @@ Response time limits enable us to set different thresholds to decide exactly whi Checkly is highly programmable and allows users to run scripts before and after the main HTTP request of an API check. -![programmable setup scripts](/images/guides/images/guides-checkly-setup.png "Setup and teardown methods are fully scriptable using NodeJS") +![programmable setup scripts](/images/guides/images/guides-checkly-setup.png "Setup and teardown methods are fully scriptable using Node.js") Setup scripts run before our check and give us access to properties like the URL, headers and query parameters, enabling us to set up all the prerequisites for a successful request. Some examples could be: @@ -372,7 +372,7 @@ As we increase our monitoring coverage across our APIs, we can also increase the - Learn end-to-end monitoring with playwright to test key website flows. + Learn end-to-end monitoring with Playwright to test key website flows. diff --git a/guides/overview.mdx b/guides/overview.mdx index d179c7bc..77ee8b8d 100644 --- a/guides/overview.mdx +++ b/guides/overview.mdx @@ -52,7 +52,7 @@ Create, configure, and update your monitoring through prompts to your coding age -Set up Claude Code to generate and deploy URL monitors and browser checks for your services +Set up Claude Code to generate and deploy URL monitors and Browser checks for your services @@ -87,7 +87,7 @@ Browse, search, add to cart, and checkout as one Playwright Check Suite with saf -Declare the alert channel, group, browser checks, and API check for a shop in Terraform +Declare the alert channel, group, Browser checks, and API check for a shop in Terraform diff --git a/guides/playwright-testing-to-monitoring.mdx b/guides/playwright-testing-to-monitoring.mdx index db9c9028..d0f89d47 100644 --- a/guides/playwright-testing-to-monitoring.mdx +++ b/guides/playwright-testing-to-monitoring.mdx @@ -131,7 +131,7 @@ Install the CLI if this repository does not have it yet, then describe the monit npm install --save-dev checkly ``` -A Playwright Check Suite reuses your Playwright config and runs a whole project. A Browser Check runs a single spec file with Checkly's own Playwright setup. Pick one. +A Playwright Check Suite reuses your Playwright config and runs a whole project. A Browser check runs a single spec file with Checkly's own Playwright setup. Pick one. @@ -181,7 +181,7 @@ new BrowserCheck('shop-checkout-browser-check', { -The Check Suite path needs nothing else: the `pwProjects` entry selects the `monitoring` project, and the suite runs every ten minutes from Virginia and Ireland. The Browser Check path needs a copy of the spec with `page.goto('https://danube-web.shop/')`, because there is no `playwright.config.ts` to supply `baseURL`. The sample keeps that copy in `checks/checkout.spec.ts`. +The Check Suite path needs nothing else: the `pwProjects` entry selects the `monitoring` project, and the suite runs every ten minutes from Virginia and Ireland. The Browser check path needs a copy of the spec with `page.goto('https://danube-web.shop/')`, because there is no `playwright.config.ts` to supply `baseURL`. The sample keeps that copy in `checks/checkout.spec.ts`. Prefer to have your coding agent write this file? The [Playwright Check Suite quickstart](/detect/synthetic-monitoring/playwright-checks/quickstart) has a prompt that inspects your Playwright config and generates the `checkly.config.ts`. diff --git a/guides/reading-traces.mdx b/guides/reading-traces.mdx index 4890c90c..8d9fc007 100644 --- a/guides/reading-traces.mdx +++ b/guides/reading-traces.mdx @@ -289,7 +289,7 @@ The agent calls `list-check-stats` with the failing filter to find the check, `g ## Next -[Monitor a checkout flow](/guides/monitoring-ecommerce-apps-using-playwright): now that you can debug one, build a full checkout monitor with the Playwright Check Suite and a Browser Check side by side. +[Monitor a checkout flow](/guides/monitoring-ecommerce-apps-using-playwright): now that you can debug one, build a full checkout monitor with the Playwright Check Suite and a Browser check side by side. ## Reference diff --git a/guides/sdlc-monitoring.mdx b/guides/sdlc-monitoring.mdx index d693521a..b0ea2865 100644 --- a/guides/sdlc-monitoring.mdx +++ b/guides/sdlc-monitoring.mdx @@ -14,7 +14,7 @@ By the end of this guide, your pull requests will test their preview URL before Passing URL monitor and browser check with the Production environment, repository, branch, and commit recorded -The [sample project](https://github.com/checkly/docs/tree/main/samples/guides/checks-on-deploy) monitors the Danube shop with one URL monitor and one Browser Check. +The [sample project](https://github.com/checkly/docs/tree/main/samples/guides/checks-on-deploy) monitors the Danube shop with one URL monitor and one Browser check. @@ -77,7 +77,7 @@ new BrowserCheck('deploy-shop-browser', { }) ``` -The URL monitor reads the local variable when the CLI builds it. The Browser Check reads the remote variable when Playwright runs: +The URL monitor reads the local variable when the CLI builds it. The Browser check reads the remote variable when Playwright runs: ```typescript __checks__/shop.spec.ts import { test, expect } from '@playwright/test' @@ -89,7 +89,7 @@ test('shop displays books', async ({ page }) => { }) ``` -Both [Browser Checks](/detect/synthetic-monitoring/browser-checks/overview) and [Playwright Check Suites](/detect/synthetic-monitoring/playwright-checks/overview) work with this deployment pattern. This sample uses a Browser Check. For a target behind your firewall, see [private locations](/platform/private-locations/overview). +Both [Browser checks](/detect/synthetic-monitoring/browser-checks/overview) and [Playwright Check Suites](/detect/synthetic-monitoring/playwright-checks/overview) work with this deployment pattern. This sample uses a Browser check. For a target behind your firewall, see [private locations](/platform/private-locations/overview). From the sample directory, test and deploy the production defaults: @@ -223,7 +223,7 @@ The Action supplies commit metadata from the event. Checkout uses the same SHA, For local runs, the CLI reads git metadata from your checkout and `repoUrl` from the project config. Uncommitted edits are tested, but the recorded SHA still identifies the current commit. Commit your checks before using that SHA to reproduce a run. -`CHECKLY_RUN_SOURCE` describes what started a run, not its environment or commit. In Playwright Check Suites, recorded CLI tests use `TEST_RECORD`, recorded triggers use `TRIGGER_RECORD`, and scheduled runs use `SCHEDULER`. A GitHub Action running `trigger` is still `TRIGGER_RECORD`; `DEPLOYMENT` denotes a Checkly deployment hook. This sample's Browser Check did not expose that variable, so it logs the target URL instead. +`CHECKLY_RUN_SOURCE` describes what started a run, not its environment or commit. In Playwright Check Suites, recorded CLI tests use `TEST_RECORD`, recorded triggers use `TRIGGER_RECORD`, and scheduled runs use `SCHEDULER`. A GitHub Action running `trigger` is still `TRIGGER_RECORD`; `DEPLOYMENT` denotes a Checkly deployment hook. This sample's Browser check did not expose that variable, so it logs the target URL instead. ## Verify it works diff --git a/guides/setup-scripts-for-apis.mdx b/guides/setup-scripts-for-apis.mdx index 7994ae11..ea828da1 100644 --- a/guides/setup-scripts-for-apis.mdx +++ b/guides/setup-scripts-for-apis.mdx @@ -249,6 +249,6 @@ if (response.statusCode >= 200 && response.statusCode < 300) { - Learn end-to-end monitoring with puppeteer and playwright to test key website flows. + Learn end-to-end monitoring with puppeteer and Playwright to test key website flows. diff --git a/integrations/alerts/slack.mdx b/integrations/alerts/slack.mdx index fc6cf4e2..5c9ddff0 100644 --- a/integrations/alerts/slack.mdx +++ b/integrations/alerts/slack.mdx @@ -22,7 +22,7 @@ You can add any **#public-channel-name** or **@username** for Direct Messages. E For each check and / or monitor, the Slack alert message contains key information, a possible root cause analysis and key actions like rerunning the check. -![A slack message showing a failed alert](/images/docs/images/alerting/slack-failed-check.png) +![A Slack message showing a failed alert](/images/docs/images/alerting/slack-failed-check.png) The root cause analysis uses AI to analyze your logs, traces, test source code, error information and other artefacts available to Checkly. Be aware that AI can make mistakes so outputs should be verified independently. @@ -32,7 +32,7 @@ For each check and / or monitor, the Slack alert message contains key informatio From the recovered Slack message, you can see the timestamp as well as a link to the check itself. -![A slack message showing a recovered alert](/images/docs/images/alerting/slack-recovered-check.png) +![A Slack message showing a recovered alert](/images/docs/images/alerting/slack-recovered-check.png) ## Migrating from the deprecated Slack webhook alert channels diff --git a/integrations/alerts/webhooks.mdx b/integrations/alerts/webhooks.mdx index 807bfc2f..d1282844 100644 --- a/integrations/alerts/webhooks.mdx +++ b/integrations/alerts/webhooks.mdx @@ -270,9 +270,9 @@ This means that for checks on a 1 minute schedule, there is a potential overlap The following examples give an idea how to integrate Checkly with 3rd party alerting and issue tracking systems. -### OpsGenie +### Opsgenie -You can create an OpsGenie +You can create an Opsgenie alert by POST-ing the following body @@ -284,13 +284,13 @@ alert by POST-ing the following body } ``` -to the OpsGenie `alerts` API endpoint +to the Opsgenie `alerts` API endpoint ``` https://{{OPSGENIE_API_KEY}}@api.opsgenie.com/v2/alerts ``` -Or you can add the OpsGenie API key in the headers, e.g. +Or you can add the Opsgenie API key in the headers, e.g. ``` Authorization: GenieKey {{OPSGENIE_API_KEY}} @@ -314,7 +314,7 @@ This is an example of a full alert body: } ``` -In case you would like different teams to be responsible for different Check Groups, you could add a `CHECK_GROUP_TEAM` variable with a different value for each Group, then modify the above snippet with the following: +In case you would like different teams to be responsible for different check groups, you could add a `CHECK_GROUP_TEAM` variable with a different value for each Group, then modify the above snippet with the following: ```json "responders": [ diff --git a/integrations/ci-cd/github/deployments.mdx b/integrations/ci-cd/github/deployments.mdx index 9dfdb73f..5416aa8b 100644 --- a/integrations/ci-cd/github/deployments.mdx +++ b/integrations/ci-cd/github/deployments.mdx @@ -61,7 +61,7 @@ The API supports GitHub deployment triggers. To configure the Checkly Vercel int If you omit both deployment filters, every successful deployment reported for the repository can trigger a run, including production deployments. Set `environmentRegexFilter` or `environmentUrlRegexFilter` when you only want to run checks against specific environments. -You can use deployment environment URLs with API, URL, browser, and multi-step checks. API and URL checks replace the host in the configured request URL. Browser and multi-step checks receive the deployment URL through the `ENVIRONMENT_URL` environment variable. +You can use deployment environment URLs with API, URL, Browser, and Multistep checks. API and URL checks replace the host in the configured request URL. Browser and Multistep checks receive the deployment URL through the `ENVIRONMENT_URL` environment variable. To change or remove a trigger created through the API, open the check or check group in Checkly and use its **CI/CD** settings. @@ -88,7 +88,7 @@ Notice we only replace the **host** part, not the URL path or any query paramete ### Browser checks & environment URLs -For browser checks, the environment URL is exposed as the `ENVIRONMENT_URL` environment variable. This means you can use that +For Browser checks, the environment URL is exposed as the `ENVIRONMENT_URL` environment variable. This means you can use that variable in your code to replace any hardcoded URL you might have, i.e.: diff --git a/integrations/ci-cd/vercel/deployment-protection.mdx b/integrations/ci-cd/vercel/deployment-protection.mdx index 2a83bda7..4c613fd4 100644 --- a/integrations/ci-cd/vercel/deployment-protection.mdx +++ b/integrations/ci-cd/vercel/deployment-protection.mdx @@ -1,6 +1,6 @@ --- title: Vercel Deployment Protection -description: "Let Checkly's browser checks reach protected Vercel preview and production deployments by passing a Protection Bypass for Automation secret in your tests." +description: "Let Checkly's Browser checks reach protected Vercel preview and production deployments by passing a Protection Bypass for Automation secret in your tests." sidebarTitle: Deployment Protection canonical: 'https://www.checklyhq.com/docs/integrations/ci-cd/vercel/deployment-protection/' --- @@ -70,7 +70,7 @@ You can tweak this setting in the Vercel dashboard under *Settings > General > D #### How to make this work with Checkly? 1. You can completely disable Standard Protection in the Vercel dashboard. This will make your deployments publicly accessible. -2. You can add some extra code to a browser check to actually log in to Vercel. Here is an example of how that would work +2. You can add some extra code to a Browser check to actually log in to Vercel. Here is an example of how that would work if you are authenticating using GitHub. Note: if you have 2FA enabled on your GitHub account, this will not work. @@ -116,7 +116,7 @@ test('visit protected deployment', async ({ page }) => { You will have to supply your GitHub username and password as environment variables (e.g. `GITHUB_USER` and `GITHUB_PASSWORD` in -the code example) to your Checkly account or as part of the [browser check's environment variables](/platform/variables). +the code example) to your Checkly account or as part of the [Browser check's environment variables](/platform/variables). ### Only Preview Deployments @@ -186,7 +186,7 @@ explore bypassing 2FA using the `otpauth` library. [Check our blog post for more ## Password Protection Vercel's [Password Protection](https://vercel.com/docs/concepts/deployments/deployment-protection#password-protection) is a paid addon that allows you to set a dedicated password for your deployments and specifically bypass protection for E2E tests / automation. -You can accomplish this using the resources referenced in the docs for [browser checks](/detect/synthetic-monitoring/browser-checks/examples#username--password-login) +You can accomplish this using the resources referenced in the docs for [Browser checks](/detect/synthetic-monitoring/browser-checks/examples#username--password-login) or [API checks](/detect/synthetic-monitoring/api-checks/setup-and-teardown). diff --git a/integrations/ci-cd/vercel/overview.mdx b/integrations/ci-cd/vercel/overview.mdx index 6cf8eb2d..0919523c 100644 --- a/integrations/ci-cd/vercel/overview.mdx +++ b/integrations/ci-cd/vercel/overview.mdx @@ -10,7 +10,7 @@ If you are using Vercel to develop, preview, and ship your application, you can Checkly offers two integrations for Vercel users: - Marketplace Integration, **for managing your Checkly account and users**. With the native integration, user access and billing is managed through Vercel. If you are new to Vercel's native integrations you can read more about them on the [Vercel documentation page](https://vercel.com/docs/integrations#native-integrations). - Connected Integration, **to monitor your preview and production deployments**. The connected integration can be installed stand-alone or on top of the native integration and helps you by: - - Automatically creating a pre-scripted browser check to catch any errors and failed requests as your web page loads. + - Automatically creating a pre-scripted Browser check to catch any errors and failed requests as your web page loads. - Enabling you to run checks against preview and production deployments on Vercel. @@ -113,7 +113,7 @@ With API checks, we automatically replace the hostname part of your request URL Notice we only replace the host part, not the URL path or any query parameters. -Just like for browser checks, the check will run on deploy against our preview environment, while also still running on a schedule against production. +Just like for Browser checks, the check will run on deploy against our preview environment, while also still running on a schedule against production. ### How Checkly checks maps to Vercel checks @@ -143,8 +143,8 @@ Vercel deployment in two ways because the Reliability part and Performance part | Checkly | Vercel | Blocking heuristic | |---------------|-------------------|------------------------------------------------------------------------------------------------------------------------------------------------------| -| API Check | Reliability Check | Blocks deployment when it fails due to > 399 HTTP response codes, assertions and other API check specific features. | -| Browser Check | Reliability Check | Blocks deployment when it fails due to > 399 HTTP response codes on the main HTML document, syntax errors in the script, or assertions using the `expect` or `assert` libraries in the browser check script. | +| API check | Reliability Check | Blocks deployment when it fails due to > 399 HTTP response codes, assertions and other API check specific features. | +| Browser check | Reliability Check | Blocks deployment when it fails due to > 399 HTTP response codes on the main HTML document, syntax errors in the script, or assertions using the `expect` or `assert` libraries in the Browser check script. | | | Performance Check | Blocks deployment when a degradation is registered in the aggregate **Virtual Experience Score** based on Web Vitals. Read below for more details. | diff --git a/integrations/iac/pulumi/best-practices.mdx b/integrations/iac/pulumi/best-practices.mdx index 10d2bf4e..e0ee543e 100644 --- a/integrations/iac/pulumi/best-practices.mdx +++ b/integrations/iac/pulumi/best-practices.mdx @@ -90,7 +90,7 @@ apiChecks.forEach(check => { Never commit API keys, passwords, or other sensitive information directly in your Pulumi code or version control. -**Use Environment Variables:** +**Use environment variables:** ```javascript // Good: Use environment variables new checkly.Check('authenticated-api', { @@ -240,7 +240,7 @@ new checkly.Check('admin-dashboard', { ### Assertion Best Practices -**Comprehensive API Checks:** +**Comprehensive API checks:** ```javascript new checkly.Check('comprehensive-api-check', { request: { diff --git a/integrations/iac/pulumi/ci-cd.mdx b/integrations/iac/pulumi/ci-cd.mdx index 86f163d9..8ae9e4b1 100644 --- a/integrations/iac/pulumi/ci-cd.mdx +++ b/integrations/iac/pulumi/ci-cd.mdx @@ -715,7 +715,7 @@ workflows: ### Secret Management - + **Secure Storage** - Use CI/CD platform secret management - Never hardcode secrets in pipeline files diff --git a/integrations/iac/pulumi/examples.mdx b/integrations/iac/pulumi/examples.mdx index f5c3071f..ba67ac9b 100644 --- a/integrations/iac/pulumi/examples.mdx +++ b/integrations/iac/pulumi/examples.mdx @@ -8,7 +8,7 @@ canonical: 'https://www.checklyhq.com/docs/integrations/iac/pulumi/examples/' This page provides comprehensive examples of how to use the Checkly Pulumi provider to create various types of monitoring checks and configurations. -## Basic API Checks +## Basic API checks ### Simple GET Request @@ -150,7 +150,7 @@ new checkly.Check('post-api-check', { -## Browser Checks +## Browser checks ### Basic Page Load Check @@ -292,7 +292,7 @@ new checkly.Check('login-flow-check', { -## Check Groups +## Check groups ### Organizing Related Checks @@ -411,9 +411,9 @@ new checkly.Check('metrics-check', { -## Alert Channels +## Alert channels -### Email Alert Channel +### Email alert channel @@ -490,7 +490,7 @@ new checkly.Check('monitored-api', { -### Slack Alert Channel +### Slack alert channel diff --git a/integrations/iac/pulumi/setup.mdx b/integrations/iac/pulumi/setup.mdx index 9e5d2079..fcda425d 100644 --- a/integrations/iac/pulumi/setup.mdx +++ b/integrations/iac/pulumi/setup.mdx @@ -141,7 +141,7 @@ yarn add @checkly/pulumi ## Step 5: Configure Authentication -### Option 1: Environment Variables (Recommended for Development) +### Option 1: Environment variables (recommended for development) Add to your shell profile (`.bashrc`, `.zshrc`, etc.): diff --git a/integrations/iac/terraform/alerting.mdx b/integrations/iac/terraform/alerting.mdx index 0034f0f6..3ec81470 100644 --- a/integrations/iac/terraform/alerting.mdx +++ b/integrations/iac/terraform/alerting.mdx @@ -1,6 +1,6 @@ --- title: 'Alert channels and settings for Terraform' -sidebarTitle: 'Alert Channels' +sidebarTitle: 'Alert channels' description: 'Configure alert settings and alert channels for your Terraform-managed monitoring setup' canonical: 'https://www.checklyhq.com/docs/integrations/iac/terraform/alerting/' --- @@ -92,7 +92,7 @@ resource "checkly_alert_channel" "email_ac" { } ``` -Checkly supports a variety of alert channels, from email and SMS to Pagerduty and custom webhooks. For all available alert channels, see the corresponding [resource page](https://registry.terraform.io/providers/checkly/checkly/latest/docs/resources/alert_channel). +Checkly supports a variety of alert channels, from email and SMS to PagerDuty and custom webhooks. For all available alert channels, see the corresponding [resource page](https://registry.terraform.io/providers/checkly/checkly/latest/docs/resources/alert_channel). ### Alert channel subscriptions diff --git a/integrations/iac/terraform/checks-groups.mdx b/integrations/iac/terraform/checks-groups.mdx index e78650e2..f86a79f2 100644 --- a/integrations/iac/terraform/checks-groups.mdx +++ b/integrations/iac/terraform/checks-groups.mdx @@ -1,7 +1,7 @@ --- title: 'Checks and groups for Terraform' sidebarTitle: 'Checks & Groups' -description: 'Create and manage browser checks, API checks, heartbeat monitors, and check groups using Terraform' +description: 'Create and manage Browser checks, API checks, Heartbeat monitors, and check groups using Terraform' canonical: 'https://www.checklyhq.com/docs/integrations/iac/terraform/checks-groups/' --- @@ -14,7 +14,7 @@ but also have their own unique ones. The type of your check is controlled using ### Browser checks -For example, a browser check can look as follows: +For example, a Browser check can look as follows: ```terraform resource "checkly_check" "e2e-login" { @@ -118,7 +118,7 @@ resource "checkly_check" "get-books" { ### Heartbeat monitors -For example, a heartbeat monitor can look as follows: +For example, a Heartbeat monitor can look as follows: ```terraform resource "checkly_heartbeat_monitor" "send-weekly-digest-v-2" { @@ -134,7 +134,7 @@ resource "checkly_heartbeat_monitor" "send-weekly-digest-v-2" { } ``` -Upon applying your terraform configuration changes, you will be returned a read-only key value for the heartbeat ping token. The token is stored in your `tfstate` file. +Upon applying your Terraform configuration changes, you will be returned a read-only key value for the heartbeat ping token. The token is stored in your `tfstate` file. ### Multistep checks @@ -163,7 +163,7 @@ For example, a Multistep check can look as follows: ``` -### Tcp Monitors +### TCP monitors TCP monitors verify the availability and responsiveness of services running on specific ports, ensuring they are reachable and operating within acceptable response time thresholds. diff --git a/integrations/iac/terraform/dashboards.mdx b/integrations/iac/terraform/dashboards.mdx index 4ad0c45c..1b035b67 100644 --- a/integrations/iac/terraform/dashboards.mdx +++ b/integrations/iac/terraform/dashboards.mdx @@ -33,4 +33,4 @@ You can see all the configuration options for checks, as well as more examples, > Available as of `v1.6.6` -You can control your dashboards private/public status via Terraform by setting the `is_private` boolean to `true`. If activated, upon applying your terraform configuration changes, you will be returned a `read-only` `key` value for the dashboard which represents the password you can use to login via the browser. The password is stored in your `tfstate` file. +You can control your dashboards private/public status via Terraform by setting the `is_private` boolean to `true`. If activated, upon applying your Terraform configuration changes, you will be returned a `read-only` `key` value for the dashboard which represents the password you can use to login via the browser. The password is stored in your `tfstate` file. diff --git a/integrations/iac/terraform/environment-variables.mdx b/integrations/iac/terraform/environment-variables.mdx index 565cc1fb..11cef314 100644 --- a/integrations/iac/terraform/environment-variables.mdx +++ b/integrations/iac/terraform/environment-variables.mdx @@ -1,6 +1,6 @@ --- -title: 'Environment Variables in Terraform' -sidebarTitle: 'Environment Variables' +title: 'Environment variables in Terraform' +sidebarTitle: 'Environment variables' description: 'Manage environment variables to reduce duplication in your monitoring setup' canonical: 'https://www.checklyhq.com/docs/integrations/iac/terraform/environment-variables/' --- diff --git a/integrations/iac/terraform/maintenance-windows.mdx b/integrations/iac/terraform/maintenance-windows.mdx index c026cd70..198e32d8 100644 --- a/integrations/iac/terraform/maintenance-windows.mdx +++ b/integrations/iac/terraform/maintenance-windows.mdx @@ -1,6 +1,6 @@ --- title: 'Service maintenance windows in Terraform' -sidebarTitle: 'Service Maintenance Windows' +sidebarTitle: 'Service maintenance windows' description: 'Schedule planned maintenance windows to prevent checks from running during specific times' canonical: 'https://www.checklyhq.com/docs/integrations/iac/terraform/maintenance-windows/' --- diff --git a/integrations/iac/terraform/overview.mdx b/integrations/iac/terraform/overview.mdx index fc57b865..c32f0a13 100644 --- a/integrations/iac/terraform/overview.mdx +++ b/integrations/iac/terraform/overview.mdx @@ -92,9 +92,9 @@ commands will detect it and remind you to do so if necessary. You can now start adding resources to your file. You can check the official documentation to see [available parameters](https://registry.terraform.io/providers/checkly/checkly/latest/docs/resources/check) for each resource type. -## Your first browser check +## Your first Browser check -As an example, you could add a basic browser check resource at the bottom of your `main.tf`. +As an example, you could add a basic Browser check resource at the bottom of your `main.tf`. ```terraform main.tf resource "checkly_check" "browser-check-1" { @@ -128,7 +128,7 @@ EOT ## Applying changes -You can now have Terraform apply your changes on Checkly by running `terraform apply`. Terraform will draft a plan and ask you to confirm by typing `yes`. Once that is done, Terraform will go ahead and create the resources you have specified (one browser check, so far) for you. +You can now have Terraform apply your changes on Checkly by running `terraform apply`. Terraform will draft a plan and ask you to confirm by typing `yes`. Once that is done, Terraform will go ahead and create the resources you have specified (one Browser check, so far) for you. ```bash Terminal $ terraform apply diff --git a/integrations/iac/terraform/parameterized-resources.mdx b/integrations/iac/terraform/parameterized-resources.mdx index a2bcf6a2..a8ef2cf2 100644 --- a/integrations/iac/terraform/parameterized-resources.mdx +++ b/integrations/iac/terraform/parameterized-resources.mdx @@ -9,7 +9,7 @@ There are cases where you might want to declare a single, parameterized resource ## File-based parameterization -You can use a combination of the [`for_each` meta-argument](https://www.terraform.io/language/meta-arguments/for_each) and the [fileset function](https://www.terraform.io/language/functions/fileset) to your advantage, for example when creating browser checks that share all their settings apart from their script: +You can use a combination of the [`for_each` meta-argument](https://www.terraform.io/language/meta-arguments/for_each) and the [fileset function](https://www.terraform.io/language/functions/fileset) to your advantage, for example when creating Browser checks that share all their settings apart from their script: ```terraform resource "checkly_check" "browser-check" { @@ -34,6 +34,6 @@ resource "checkly_check" "browser-check" { } ``` -This will create as many browser checks running each minute as there are files in the `./scripts` folder in your project's path. +This will create as many Browser checks running each minute as there are files in the `./scripts` folder in your project's path. > Aside from checks, these constructs can be useful for a variety of resources like alert channels and more. diff --git a/integrations/iac/terraform/testing-scripts-locally.mdx b/integrations/iac/terraform/testing-scripts-locally.mdx index 6e1589dc..932921d6 100644 --- a/integrations/iac/terraform/testing-scripts-locally.mdx +++ b/integrations/iac/terraform/testing-scripts-locally.mdx @@ -1,15 +1,15 @@ --- title: 'Testing Terraform scripts locally' sidebarTitle: 'Testing Scripts Locally' -description: 'Run Playwright Test scripts locally for faster development and debugging of browser checks' +description: 'Run Playwright Test scripts locally for faster development and debugging of Browser checks' canonical: 'https://www.checklyhq.com/docs/integrations/iac/terraform/testing-scripts-locally/' --- -Having the possibility to run Playwright Test scripts for your browser checks locally will allow you to develop them faster and with more confidence. +Having the possibility to run Playwright Test scripts for your Browser checks locally will allow you to develop them faster and with more confidence. ## Enabling local script execution -You can easily enable local execution by storing your browser check scripts in local folders and passing the path to the right script: +You can easily enable local execution by storing your Browser check scripts in local folders and passing the path to the right script: ```terraform resource "checkly_check" "e2e-checkout" { diff --git a/integrations/incident-management/opsgenie.mdx b/integrations/incident-management/opsgenie.mdx index d30014bc..fc809e36 100644 --- a/integrations/incident-management/opsgenie.mdx +++ b/integrations/incident-management/opsgenie.mdx @@ -44,7 +44,7 @@ create a new Opsgenie channel. 5. Choose a name for your Opsgenie channel, paste your **API Key** and select your Opsgenie region (`EU` for EU based customers, `US` for the rest of the world). - > 💡 In OpsGenie you can configure other options like + > 💡 In Opsgenie you can configure other options like [alert priority](https://docs.opsgenie.com/docs/alert-priority-settings). > 💡 On Checkly, you can specify which [check events](/communicate/alerts/channels) will be sent over to Opsgenie. diff --git a/integrations/incident-management/pagerduty.mdx b/integrations/incident-management/pagerduty.mdx index 9c0377e6..a820f1b4 100644 --- a/integrations/incident-management/pagerduty.mdx +++ b/integrations/incident-management/pagerduty.mdx @@ -13,21 +13,21 @@ import AlertChannelSecrets from '/snippets/alert-channel-secrets-callout.mdx'; The PagerDuty channel's `serviceKey` (integration key) accepts environment-variable references — e.g. `{{PAGERDUTY_SERVICE_KEY}}` — so you can store the integration key as an account secret instead of inline in the channel config. -Checkly integrates with [Pagerduty](https://pagerduty.com) and can deliver all failure and recovery events -to your Pagerduty account. After setting up the integration, Checkly will: +Checkly integrates with [PagerDuty](https://pagerduty.com) and can deliver all failure and recovery events +to your PagerDuty account. After setting up the integration, Checkly will: -1. Trigger alerts in Pagerduty when a check fails. +1. Trigger alerts in PagerDuty when a check fails. 2. Resolve alerts when a check recovers. 3. Trigger alerts when a check degrades or an SSL certificate is about to expire, if you enable these notification events. -Setup is as simple as following the three-step Pagerduty connect process. You can add as many Pagerduty channels as +Setup is as simple as following the three-step PagerDuty connect process. You can add as many PagerDuty channels as you wish. 1. Click **Alert channels** in the left sidebar (under **Communicate**) to open your [alert settings](https://app.checklyhq.com/alerts/settings), then click the **Add more channels** button and select **PagerDuty**. ![setup checkly pagerduty integration step 1](/images/docs/images/integrations/pagerduty_step1.png) -2. Clicking the **Alert with Pagerduty** button will take you to a Pagerduty Connect screen. Provide your credentials and click -**Sign In** to allow Checkly to connect with Pagerduty. +2. Clicking the **Alert with Pagerduty** button will take you to a PagerDuty Connect screen. Provide your credentials and click +**Sign In** to allow Checkly to connect with PagerDuty. ![set up checkly pagerduty integration step 2](/images/docs/images/integrations/pagerduty_step2.png) 3. On the next screen you can hook up Checkly to one or more existing services. If you select multiple services, we will @@ -35,12 +35,12 @@ create multiple dedicated channels so you have more flexibility of muting, editi Click **Connect** to save your settings and redirect you back to Checkly. ![set up checkly pagerduty integration step 3](/images/docs/images/integrations/pagerduty_step3.png) -4. Back in Checkly, you should see your Pagerduty **integration credentials** reflected in the alert settings. Don't forget +4. Back in Checkly, you should see your PagerDuty **integration credentials** reflected in the alert settings. Don't forget to hit **Create PagerDuty channel**. ![set up checkly pagerduty integration step 4](/images/docs/images/integrations/pagerduty_step4.png) -5. Checkly will trigger an incident in Pagerduty when checks fail and also mark them as resolved when the checks are passing again. +5. Checkly will trigger an incident in PagerDuty when checks fail and also mark them as resolved when the checks are passing again. ![set up checkly pagerduty integration step 5](/images/docs/images/integrations/pagerduty_step5.png) ## PagerDuty Best Practices diff --git a/integrations/observability/coralogix.mdx b/integrations/observability/coralogix.mdx index 9b16b947..4b8c1c99 100644 --- a/integrations/observability/coralogix.mdx +++ b/integrations/observability/coralogix.mdx @@ -1,20 +1,20 @@ --- title: 'Export Metrics & Data via Coralogix' -description: 'Deep integration with Coralogix for Open Telemetry tracing, RUM monitoring, and alert notifications' +description: 'Deep integration with Coralogix for OpenTelemetry tracing, RUM monitoring, and alert notifications' sidebarTitle: 'Coralogix' canonical: 'https://www.checklyhq.com/docs/integrations/observability/coralogix/' --- Checkly deeply integrates with [Coralogix](https://coralogix.com/) in three ways: -1. Checkly can automatically instrument all check executions with **Open Telemetry tracing** and send the data to Coralogix +1. Checkly can automatically instrument all check executions with **OpenTelemetry tracing** and send the data to Coralogix as traces. 2. Checkly can automatically instrument your Browser checks with **Coralogix RUM (Real User Monitoring)**. 3. Checkly can send **alert notifications** when checks pass and/or fail to **Coralogix Logs**. -## Open Telemetry tracing integration +## OpenTelemetry tracing integration -To set up the Open Telemetry tracing integration, first enable the Coralogix integration in your Checkly account in the +To set up the OpenTelemetry tracing integration, first enable the Coralogix integration in your Checkly account in the [integrations section](https://app.checklyhq.com/settings/account/integrations). ![coralogix otel integration](/images/docs/images/integrations/coralogix/cx_otel_int1.png) @@ -73,7 +73,7 @@ and forward to Coralogix using an OpenTelemetry Collector. ## RUM integration -In addition to the Open Telemetry tracing, Checkly can also send RUM data to Coralogix for all Browser checks. This enables +In addition to the OpenTelemetry tracing, Checkly can also send RUM data to Coralogix for all Browser checks. This enables tracking your Playwright-powered checks to be recorded as (semi) real users, so you can compare and contrast the performance between synthetic and real users. @@ -90,7 +90,7 @@ Copy and paste the integration key into Checkly. > Only the integration key is needed for the Checkly integration. -5. As Checkly automatically injects the Coralogix RUM SDK to each browser check run, uploading and setting up the SourceMap is not required. You can **skip** the **Install & setup Browser SDK Package** step and finish the set up there. +5. As Checkly automatically injects the Coralogix RUM SDK to each Browser check run, uploading and setting up the SourceMap is not required. You can **skip** the **Install & setup Browser SDK Package** step and finish the set up there. If you are targeting multiple applications with your checks, you can override the global application name by adding the environment variable `CORALOGIX_RUM_APP_NAME` to your Browser check. You can find the Browser check specific environment @@ -101,7 +101,7 @@ After enabling the RUM integration, Checkly will start sending RUM data to Coral > Note that you do not need to install the RUM SDK in your application, Checkly will automatically inject the necessary > JavaScript snippet into your Browser checks. However, if you have installed the SDK we will use the existing installation and not inject the snippet. -## Alert Channel → Coralogix Logs integration +## Alert channel → Coralogix Logs integration You can set up Coralogix as an alert channel destination, so Coralogix receives any alert notifications you have set up as logs. Note that you can use this integration separately from the other two integrations mentioned above. diff --git a/integrations/observability/prometheus-v2.mdx b/integrations/observability/prometheus-v2.mdx index 2aa81e93..74f05c34 100644 --- a/integrations/observability/prometheus-v2.mdx +++ b/integrations/observability/prometheus-v2.mdx @@ -74,8 +74,8 @@ The following metrics are available to monitor checks: | `checkly_dns_monitor_timing_seconds` | Histogram | The total duration of the DNS monitor. | | `checkly_grpc_monitor_timing_seconds` | Histogram | The timing phases of the gRPC monitor, including DNS resolution, connection, and total RPC duration. | | `checkly_grpc_monitor_status_code` | Gauge | The gRPC status code returned on the latest run (`0` = OK). | -| `checkly_traceroute_monitor_timing_seconds` | Histogram | The timing phases of the traceroute monitor, including DNS resolution and final hop latency. | -| `checkly_traceroute_monitor_hops` | Gauge | The total number of hops for the traceroute monitor. | +| `checkly_traceroute_monitor_timing_seconds` | Histogram | The timing phases of the Traceroute monitor, including DNS resolution and final hop latency. | +| `checkly_traceroute_monitor_hops` | Gauge | The total number of hops for the Traceroute monitor. | | `checkly_traceroute_monitor_destination_reached` | Gauge | Whether the traceroute reached its destination on the latest run (`1`) or not (`0`). | | `checkly_ssl_monitor_days_until_expiry` | Gauge | The average days remaining until the certificate checked by the SSL monitor expires, over the current scrape window. | | `checkly_ssl_monitor_handshake_seconds` | Histogram | The TLS handshake duration of the SSL monitor. | @@ -87,7 +87,7 @@ The following metrics are available to monitor checks: | `checkly_multistep_check_duration_seconds` | Histogram | The total check duration. This includes all requests done and any waits. | | `checkly_playwright_check_duration_seconds` | Histogram | The total duration of the Playwright Check Suite. | | `checkly_heartbeat_last_success_timestamp_seconds` | Gauge | The Unix timestamp of the last successful heartbeat ping. A value of `0` means no successful ping has ever been received. | -| `checkly_heartbeat_expected_interval_seconds` | Gauge | The configured maximum interval between heartbeat pings, in seconds. Derived from the heartbeat monitor's period and period unit settings. | +| `checkly_heartbeat_expected_interval_seconds` | Gauge | The configured maximum interval between heartbeat pings, in seconds. Derived from the Heartbeat monitor's period and period unit settings. | | `checkly_time_to_ssl_expiry_seconds` | Gauge | The amount of time remaining before the SSL certificate of the monitored domain expires. See the [SSL certificate expiration docs](/communicate/alerts/ssl-expiration) for more information on monitoring SSL certificates with checks. | The `checkly_check_status` and `checkly_check_result_total` metrics contain a `status` label with values `passing`, `failing`, and `degraded`. @@ -132,7 +132,7 @@ In addition, the check metrics all contain the following labels: To avoid creating a high volume of metrics, by default the metrics don't include a label for the check run location. It is possible to enable this by adding the query param `locationLabelEnabled=true` to your API request. This will add a `location` label giving the location where the checks ran. -Since check status and SSL days remaining is only tracked on a per-check basis rather than by location, `checkly_check_status` and `checkly_time_to_ssl_expiry_seconds` do not have the `location` label included. Heartbeat metrics (`checkly_heartbeat_last_success_timestamp_seconds`, `checkly_heartbeat_expected_interval_seconds`, and heartbeat entries in `checkly_check_result_total`) also do not have a `location` label, since heartbeat monitors receive pings rather than running from specific locations. All other [check metrics](#check-metrics) will have the `location` label added. +Since check status and SSL days remaining is only tracked on a per-check basis rather than by location, `checkly_check_status` and `checkly_time_to_ssl_expiry_seconds` do not have the `location` label included. Heartbeat metrics (`checkly_heartbeat_last_success_timestamp_seconds`, `checkly_heartbeat_expected_interval_seconds`, and heartbeat entries in `checkly_check_result_total`) also do not have a `location` label, since Heartbeat monitors receive pings rather than running from specific locations. All other [check metrics](#check-metrics) will have the `location` label added. Here is an example for how to set this in your `prometheus.yml` config: @@ -210,7 +210,7 @@ sum by(type) (rate(checkly_browser_check_web_vitals_seconds_sum{name="Check Name [Heartbeat monitors](/detect/uptime-monitoring/heartbeat-monitors/overview) are passive checks that wait for your scheduled jobs and automated processes to send a ping. The Prometheus exporter includes heartbeat checks in the standard `checkly_check_status` and `checkly_check_result_total` metrics, plus two heartbeat-specific gauges designed for [dead man's switch](https://en.wikipedia.org/wiki/Dead_man%27s_switch) alerting. - **`checkly_heartbeat_last_success_timestamp_seconds`** — The Unix timestamp of the last successful ping, searched across the entire event history (no time window). A value of `0` means no successful ping has ever been received — this immediately triggers a dead man's switch alert since `time() - 0` produces a very large value. -- **`checkly_heartbeat_expected_interval_seconds`** — The maximum expected time between pings, derived from the heartbeat monitor's configured period and period unit (e.g., `5 minutes` = `300` seconds). Use this as a threshold for alerting. +- **`checkly_heartbeat_expected_interval_seconds`** — The maximum expected time between pings, derived from the Heartbeat monitor's configured period and period unit (e.g., `5 minutes` = `300` seconds). Use this as a threshold for alerting. ### How heartbeats map to `checkly_check_result_total` @@ -220,7 +220,7 @@ Heartbeat checks contribute to `checkly_check_result_total` using a 1-hour count |----------------|--------------------------| | `passing` | `RECEIVED`, `EARLY`, `GRACE`, `LATE` — any ping that arrived | | `failing` | `FAILING` — no ping received before the grace period expired | -| `degraded` | Always `0` — heartbeat monitors do not have a degraded state | +| `degraded` | Always `0` — Heartbeat monitors do not have a degraded state | ### Dead Man's Switch PromQL Examples @@ -248,27 +248,27 @@ Show how long ago each heartbeat was last seen: time() - checkly_heartbeat_last_success_timestamp_seconds ``` -## Private Location Metrics +## Private location metrics -The Prometheus exporter also contains metrics for monitoring [Private Locations](/platform/private-locations/overview). These metrics can be used to ensure that your Private Locations have enough Checkly Agent instances running to execute all of your checks, and to drive [agent autoscaling](/platform/private-locations/autoscaling). +The Prometheus exporter also contains metrics for monitoring [private locations](/platform/private-locations/overview). These metrics can be used to ensure that your private locations have enough Checkly Agent instances running to execute all of your checks, and to drive [agent autoscaling](/platform/private-locations/autoscaling). -The following metrics are available to monitor Private Locations: +The following metrics are available to monitor private locations: | Metric | Type | Description | |--------|------|-------------| -| `checkly_private_location_queue_size` | Gauge | The number of check runs scheduled to the Private Location and waiting to be executed. A high value indicates that checks are becoming backlogged and that you may need to [scale your Checkly Agents](/platform/private-locations/scaling-redundancy). | -| `checkly_private_location_oldest_scheduled_check_run` | Gauge | The age in seconds of the oldest check run job scheduled to the Private Location queue. A high value indicates that checks are becoming backlogged. | -| `checkly_private_location_queue_duration_ms` | Gauge | The scheduling delay in milliseconds for check runs routed through a Private Location, by queue and `stat`. Derived from the last 2 minutes of check run data. Used to evaluate whether sufficient agent capacity is provisioned for the Private Location. | -| `checkly_private_location_agent_count` | Gauge | The number of agents connected for the Private Location. | -| `checkly_private_location_check_runs` | Gauge | The count of check runs in the Private Location, broken down by lifecycle state via the `state` label and by routing queue via the `queue` label. Used as the signal for [autoscaling Checkly Agents](/platform/private-locations/autoscaling). | +| `checkly_private_location_queue_size` | Gauge | The number of check runs scheduled to the private location and waiting to be executed. A high value indicates that checks are becoming backlogged and that you may need to [scale your Checkly Agents](/platform/private-locations/scaling-redundancy). | +| `checkly_private_location_oldest_scheduled_check_run` | Gauge | The age in seconds of the oldest check run job scheduled to the private location queue. A high value indicates that checks are becoming backlogged. | +| `checkly_private_location_queue_duration_ms` | Gauge | The scheduling delay in milliseconds for check runs routed through a private location, by queue and `stat`. Derived from the last 2 minutes of check run data. Used to evaluate whether sufficient agent capacity is provisioned for the private location. | +| `checkly_private_location_agent_count` | Gauge | The number of agents connected for the private location. | +| `checkly_private_location_check_runs` | Gauge | The count of check runs in the private location, broken down by lifecycle state via the `state` label and by routing queue via the `queue` label. Used as the signal for [autoscaling Checkly Agents](/platform/private-locations/autoscaling). | -The Private Location metrics all contain the following labels: +The private location metrics all contain the following labels: | Label | Description | | ------|-------------| -| `private_location_name` | the name of the Private Location. | -| `private_location_slug_name` | the Private Location's human readable unique identifier. | -| `private_location_id` | the Private Location's UUID. | +| `private_location_name` | the name of the private location. | +| `private_location_slug_name` | the private location's human readable unique identifier. | +| `private_location_id` | the private location's UUID. | `checkly_private_location_check_runs` additionally carries a `queue` label (`uptime` or `main`) and a `state` label. The `state` values relevant for autoscaling are: diff --git a/learn/incidents/anatomy-of-a-status-page.mdx b/learn/incidents/anatomy-of-a-status-page.mdx index a8e2e182..bd2105cf 100644 --- a/learn/incidents/anatomy-of-a-status-page.mdx +++ b/learn/incidents/anatomy-of-a-status-page.mdx @@ -1,7 +1,7 @@ --- -title: Anatomy of a Status Page | Checkly Guide -displayTitle: Anatomy of a Status Page -sidebarTitle: Anatomy of a Status Page +title: Anatomy of a status page | Checkly Guide +displayTitle: Anatomy of a status page +sidebarTitle: Anatomy of a status page description: Discover what makes a status page users trust - automated monitoring, clear visuals, service groupings, and more. date: 2025-04-08 author: Nocnica Mellifera @@ -57,7 +57,7 @@ The basic technical requirements (fast loading pages, manual edits permitted, et **3. Clear infographics** - a status page should be able to take complex historical data and turn it into a clear history for the viewer. Some kind of graphing library should represent high level status data visually. -**4. Incidents should be organized into services** - for Checkly’s Status Pages, you organize each page into [components](/communicate/status-pages/overview#components) ahead of time, and on Team and Enterprise plans, [automation rules](/communicate/status-pages/overview#automatically-creating-incidents) match failing checks by tag and open an incident on the components you choose. We don’t want to present our product as a monolith, nor should we print inscrutable internal labels. With this organization, we can present sections on a single status page, or multiple separate status pages with groupings of services. +**4. Incidents should be organized into services** - for Checkly’s status pages, you organize each page into [components](/communicate/status-pages/overview#components) ahead of time, and on Team and Enterprise plans, [automation rules](/communicate/status-pages/overview#automatically-creating-incidents) match failing checks by tag and open an incident on the components you choose. We don’t want to present our product as a monolith, nor should we print inscrutable internal labels. With this organization, we can present sections on a single status page, or multiple separate status pages with groupings of services. **5. Subscription service** - Users should subscribe to only the pages they care about. @@ -65,4 +65,4 @@ The basic technical requirements (fast loading pages, manual edits permitted, et In short, a good status page keeps users informed and builds trust. It must be clear, reliable, and easy to use. Users want quick updates, simple labels, and the ability to subscribe. On the tech side, it needs automated monitoring, independent hosting, and clear visuals. By meeting these needs, your status page will help users stay updated and reduce frustration. -**Further reading:** [A guide to Checkly’s Status Pages](/communicate/status-pages/overview) \ No newline at end of file +**Further reading:** [A guide to Checkly’s status pages](/communicate/status-pages/overview) \ No newline at end of file diff --git a/learn/incidents/mttr-challenges.mdx b/learn/incidents/mttr-challenges.mdx index 03187ccb..85f6fc66 100644 --- a/learn/incidents/mttr-challenges.mdx +++ b/learn/incidents/mttr-challenges.mdx @@ -61,7 +61,7 @@ Once an issue is detected, the next step is to stop the customer pain by impleme - Providing engineers with actionable data and context in alerts. For example, linking alerts to dashboards that show affected services or customers can help engineers prioritize and resolve issues more efficiently. - Linking alerts with deeper root cause information. While it’s critical to show ‘who is affected and how,’ it’s also supremely important to give some indication of what’s happening internal to our services so that our engineers are not stuck sorting through backend logs trying to match time stamps. For example, Checkly Traces links backend traces with synthetic monitoring data, to show application internals related to any user-facing issue. -- Easy rollbacks. Whether it’s deploying rolled back code right from source control with (for example) GitHub actions, or feature flagging to disable a new feature that’s causing trouble, it’s critical that on-call teams are empowered to get the service back to a working state by rolling back the clock. +- Easy rollbacks. Whether it’s deploying rolled back code right from source control with (for example) GitHub Actions, or feature flagging to disable a new feature that’s causing trouble, it’s critical that on-call teams are empowered to get the service back to a working state by rolling back the clock. With these tools an on-call team can get the system working for users quickly, followed by a longer period of root cause analysis and postmortem. diff --git a/learn/incidents/overview.mdx b/learn/incidents/overview.mdx index 7e3ed1f2..8aaddec1 100644 --- a/learn/incidents/overview.mdx +++ b/learn/incidents/overview.mdx @@ -25,7 +25,7 @@ Further, expectations about uptime have gone from ‘best practices’ to ‘bin Incident Response in the software industry refers to a time-critical response to some kind of availability incident. What makes a good status page? Learn user expectations and technical requirements diff --git a/learn/incidents/reduce-mttd.mdx b/learn/incidents/reduce-mttd.mdx index 44577d95..1748ad5b 100644 --- a/learn/incidents/reduce-mttd.mdx +++ b/learn/incidents/reduce-mttd.mdx @@ -49,7 +49,7 @@ Many of the points listed in this article will revolve around making sure that a - Take alert fatigue seriously — false positives (alerts when there was no problem) should trigger investigations and fixes just like false negatives (undetected outages). - Set retry policies — requests sometimes fail via the internet. Set a reasonable [retry policy](/communicate/alerts/overview) on your checks so you’re not generating false alarms. - Use smart tests — using the [auto-waiting](https://www.checklyhq.com/learn/playwright/waits-and-timeouts/) and intelligent user-centric assertions of Playwright will help ensure your tests aren’t too strict and therefore flaky (generating lots of false positives). -- Route alerts intelligently — use a tool like Rootly or Pagerduty to make sure only the right people are getting alerts. +- Route alerts intelligently — use a tool like Rootly or PagerDuty to make sure only the right people are getting alerts. If you take these steps, you can help ensure that a human being is reading all the alerts they receive. The other points included in this article will also help reduce how many alerts your engineers get that they can safely ignore. diff --git a/learn/incidents/root-cause-with-traces.mdx b/learn/incidents/root-cause-with-traces.mdx index d2f6dbb0..b94328cf 100644 --- a/learn/incidents/root-cause-with-traces.mdx +++ b/learn/incidents/root-cause-with-traces.mdx @@ -59,7 +59,7 @@ Example trace showing a failed payment process: Proactively test critical user journeys with: -- Scripted browser checks (e.g., login → add to cart → checkout) +- Scripted Browser checks (e.g., login → add to cart → checkout) - API test sequences with assertions - Geographic performance testing @@ -83,7 +83,7 @@ When combined, these approaches: | --- | --- | --- | | Tracing | Jaeger, Tempo, Honeycomb | Visualize request flows | | Synthetic | Checkly, Synthetics | Test user journeys proactively | -| Alerting | Rootly, OpsGenie | Route incidents effectively | +| Alerting | Rootly, Opsgenie | Route incidents effectively | ### 3. Analyze Incidents diff --git a/learn/incidents/slo-sla-sli.mdx b/learn/incidents/slo-sla-sli.mdx index c606c972..b8e778da 100644 --- a/learn/incidents/slo-sla-sli.mdx +++ b/learn/incidents/slo-sla-sli.mdx @@ -165,9 +165,9 @@ By setting these SLIs, SLOs, and SLAs, the company not only commits to deliverin ## **How Checkly Can Help You Hit Your SLAs** -[Checkly](https://www.checklyhq.com/) focuses on Synthetic Monitoring to track how well websites, applications, and APIs work. Its goal is to help [meet Service Level Agreements (SLAs)](https://www.checklyhq.com/blog/how-to-monitor-all-the-nines-of-your-service-level-agreements/) with customers with its features such as API checks, browser checks, heartbeat monitoring, etc. +[Checkly](https://www.checklyhq.com/) focuses on Synthetic Monitoring to track how well websites, applications, and APIs work. Its goal is to help [meet Service Level Agreements (SLAs)](https://www.checklyhq.com/blog/how-to-monitor-all-the-nines-of-your-service-level-agreements/) with customers with its features such as API checks, Browser checks, heartbeat monitoring, etc. -### **API Checks** +### **API checks** [API checks](https://www.checklyhq.com/blog/what-is-api-monitoring/) monitor vital API endpoints frequently from various global locations. They allow for the validation of response codes and bodies to ensure accuracy, while also keeping an eye on response times to maintain a quick and efficient experience. Additionally, the feature of receiving instant alerts when any monitoring checks indicate a failure provides the assurance needed for maintaining smooth API operations. This proactive approach to monitoring ensures that APIs function seamlessly, enhancing reliability and user satisfaction. @@ -184,23 +184,23 @@ Checkly’s API checks can help you achieve your SLAs through: - **Performance Tracking:** Checkly tracks the performance of your APIs over time, offering insights into trends and potential areas of improvement. This data can help you optimize your services to not only meet but exceed SLA expectations regarding response times and reliability. - **Detailed Reporting:** The platform provides detailed reports and dashboards that give visibility into API health, performance metrics, and historical data. These insights can be used to demonstrate compliance with SLAs during audits and reviews with stakeholders. -### **Browser Checks** +### **Browser checks** -On the other hand, Checkly’s Playwright-based [browser checks](/detect/synthetic-monitoring/browser-checks/overview) mimic user actions to make sure key processes work smoothly, and the heartbeat feature checks if systems are running properly. These capabilities enable the monitoring of response times, uptime, functionality, and internal systems performance. This comprehensive monitoring supports SLAs in keeping services healthy and running efficiently. +On the other hand, Checkly’s Playwright-based [Browser checks](/detect/synthetic-monitoring/browser-checks/overview) mimic user actions to make sure key processes work smoothly, and the heartbeat feature checks if systems are running properly. These capabilities enable the monitoring of response times, uptime, functionality, and internal systems performance. This comprehensive monitoring supports SLAs in keeping services healthy and running efficiently. ![a checkly dashboard](/images/learn/images/sla-02.png) -Checkly’s browser checks can help you achieve your SLAs through: +Checkly’s Browser checks can help you achieve your SLAs through: -- **Real User Simulation:** Checkly's browser checks use real browsers to simulate user actions, such as clicking links, filling out forms, and navigating through web pages. This allows you to test and monitor the end-to-end user experience, ensuring that your application meets SLA requirements for functionality and user satisfaction. -- **Global Coverage:** By running browser checks from multiple locations worldwide, you can ensure that your web application delivers a consistent user experience across different geographical regions. This is particularly important for SLAs that specify performance standards across diverse user bases. +- **Real User Simulation:** Checkly's Browser checks use real browsers to simulate user actions, such as clicking links, filling out forms, and navigating through web pages. This allows you to test and monitor the end-to-end user experience, ensuring that your application meets SLA requirements for functionality and user satisfaction. +- **Global Coverage:** By running Browser checks from multiple locations worldwide, you can ensure that your web application delivers a consistent user experience across different geographical regions. This is particularly important for SLAs that specify performance standards across diverse user bases. - **Performance Metrics:** Checkly provides detailed performance metrics, such as page load times, which are crucial for meeting SLAs related to website speed and responsiveness. Monitoring these metrics allows you to identify and address performance bottlenecks before they affect user satisfaction. - **Visual Regression Testing:** You can use Checkly to perform [visual regression testing](https://www.checklyhq.com/blog/visual-regression-testing-with-playwright/), which ensures that your web application's visual elements render correctly across different browsers and devices. This helps maintain a high-quality user interface, in line with SLA standards for usability and design. -- **Error Detection and Alerting:** Checkly alerts you in real-time if a browser check fails, enabling you to quickly identify and resolve issues such as broken links, malfunctioning features, or downtime. This rapid response capability is essential for adhering to SLAs that stipulate minimal downtime and quick issue resolution. -- **Customizable Check Intervals:** You can configure the frequency of your browser checks to match the criticality of different application components. For example, you might run checks on key user flows every few minutes to ensure high availability and performance, aligning with stringent SLA requirements. +- **Error Detection and Alerting:** Checkly alerts you in real-time if a Browser check fails, enabling you to quickly identify and resolve issues such as broken links, malfunctioning features, or downtime. This rapid response capability is essential for adhering to SLAs that stipulate minimal downtime and quick issue resolution. +- **Customizable Check Intervals:** You can configure the frequency of your Browser checks to match the criticality of different application components. For example, you might run checks on key user flows every few minutes to ensure high availability and performance, aligning with stringent SLA requirements. - **Reporting and Insights:** Checkly provides comprehensive reports and dashboards that offer insights into the historical performance and reliability of your web application. These insights can be used to demonstrate compliance with SLAs during stakeholder reviews and to identify areas for improvement. -*To find out more about Checkly’s browser checks & how to get started, check out [this article](/detect/synthetic-monitoring/browser-checks/overview).* +*To find out more about Checkly’s Browser checks & how to get started, check out [this article](/detect/synthetic-monitoring/browser-checks/overview).* ### **Checkly Best Practices** diff --git a/learn/monitoring/api-monitoring.mdx b/learn/monitoring/api-monitoring.mdx index 3fcbd942..e0147373 100644 --- a/learn/monitoring/api-monitoring.mdx +++ b/learn/monitoring/api-monitoring.mdx @@ -77,7 +77,7 @@ The next step is to choose an API monitoring tool that will best support your ne Checkly’s [API monitoring tool](https://www.checklyhq.com/product/api-monitoring/) is an optimal solution for companies keen to develop and integrate an effective API monitoring flow into their existing development and maintenance processes. -Checkly enables you to streamline the API monitoring process. You can start by creating or importing HTTP requests for the endpoints you want to monitor, then specify assertions against the response (and response time). There are ample opportunities to customize [setup and teardown](/detect/synthetic-monitoring/api-checks/setup-and-teardown) [using scripts](/guides/setup-scripts-for-apis) to fetch OAuth tokens or help clean test data. Checkly has data centers in twenty locations worldwide, from which it can run API checks up to every ten seconds. This is crucial to get a comprehensive and accurate picture of the health of your APIs. Finally, depending on your workflow, [Checkly also integrates with services such as Slack](/communicate/alerts/channels), email, and Pagerduty to notify and alert you of any incidents. +Checkly enables you to streamline the API monitoring process. You can start by creating or importing HTTP requests for the endpoints you want to monitor, then specify assertions against the response (and response time). There are ample opportunities to customize [setup and teardown](/detect/synthetic-monitoring/api-checks/setup-and-teardown) [using scripts](/guides/setup-scripts-for-apis) to fetch OAuth tokens or help clean test data. Checkly has data centers in twenty locations worldwide, from which it can run API checks up to every ten seconds. This is crucial to get a comprehensive and accurate picture of the health of your APIs. Finally, depending on your workflow, [Checkly also integrates with services such as Slack](/communicate/alerts/channels), email, and PagerDuty to notify and alert you of any incidents. ## API Monitoring as Code @@ -101,9 +101,9 @@ By default, you have access to a free Team trial which expires after 14 days, so ### Step 2: Create a New Check -Once you've signed up and logged in, you can proceed to a [Browser Check](/detect/synthetic-monitoring/browser-checks/overview), API Check or use the CLI script. +Once you've signed up and logged in, you can proceed to a [Browser check](/detect/synthetic-monitoring/browser-checks/overview), API check or use the CLI script. -Let’s play around with the API Check. On your dashboard, click the "API Check" tab (you can toggle between tabs). You should see an interface like this: +Let’s play around with the API check. On your dashboard, click the "API Check" tab (you can toggle between tabs). You should see an interface like this: ![A diagram of dependencies](/images/learn/images/api-monitoring-03.png) @@ -151,7 +151,7 @@ Monitoring frequency determines how often Checkly will send requests to your API You can choose from various intervals like every minute or custom intervals based on your needs. You can also add assertions and limits to validate specific response criteria like status codes or response time. -### Step 5: Define Alert Channels +### Step 5: Define alert channels Alert channels allow you to receive notifications when issues or errors are detected during API monitoring. Checkly supports multiple alert channels including email, phone calls, SMS, Slack, Discord, Telegram, PagerDuty, Webhooks and more. Configure the desired alert channels and provide relevant contact information. diff --git a/learn/monitoring/end-to-end-monitoring.mdx b/learn/monitoring/end-to-end-monitoring.mdx index d0038025..cba65457 100644 --- a/learn/monitoring/end-to-end-monitoring.mdx +++ b/learn/monitoring/end-to-end-monitoring.mdx @@ -1,6 +1,6 @@ --- title: What is End to End Monitoring? An Overview with Examples -description: Learn end-to-end monitoring with playwright to test key website flows. Follow our guide that gets you up and running in 10 minutes. +description: Learn end-to-end monitoring with Playwright to test key website flows. Follow our guide that gets you up and running in 10 minutes. tags: Playwright sidebarTitle: What is End-to-End Monitoring? canonical: 'https://www.checklyhq.com/docs/learn/monitoring/end-to-end-monitoring/' @@ -157,7 +157,7 @@ We can move our scripts to separate checks to keep them [independent](/learn/pla ![checkly dashboard screenshot](/images/guides/images/guides-checkly-dashboard.png "Checkly's dashboard") -As soon as a check runs red, we are alerted in real time and can **intervene before the issue impacts our users**. Alerting can be set up with all the industry-standard channels like Pagerduty, Opsgenie, Slack, email, SMS and more. +As soon as a check runs red, we are alerted in real time and can **intervene before the issue impacts our users**. Alerting can be set up with all the industry-standard channels like PagerDuty, Opsgenie, Slack, email, SMS and more. ![checkly alerting screenshot](/images/guides/images/guides-checkly-alerting.png "Alert channels on Checkly") @@ -251,7 +251,7 @@ Once this setup is complete, log in to your Checkly account via the CLI using th `npx checkly login` You can choose to log in from the browser or in your terminal. After logging in, you'll be able to update Checkly Checks from your local machine as long as you're connected to the internet. Step 3: Writing Your Monitoring Scripts -In your development environment, write JavaScript/TypeScript tests for your code updates, similar to unit tests. We typically write Playwright tests in `.spec.ts` files. The `.check.ts` files configure checks, such as API checks and heartbeat monitors. +In your development environment, write JavaScript/TypeScript tests for your code updates, similar to unit tests. We typically write Playwright tests in `.spec.ts` files. The `.check.ts` files configure checks, such as API checks and Heartbeat monitors. Consider a scenario where you want to monitor the title of the Checkly documentation and take a screenshot of the page. To do this, replace the code in the `homepage.spec.ts` with the following: ```javascript homepage.spec.ts @@ -276,7 +276,7 @@ This test uses the `page.goto` method to navigate to the specified URL (`https:/ Then we use the `expect` function to assert that the HTTP status code of the response is less than 400. This is a way to ensure that the page is loaded successfully without any HTTP errors. `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 +Step 4: Running test sessions 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. diff --git a/learn/monitoring/frontend-monitoring.mdx b/learn/monitoring/frontend-monitoring.mdx index 3bea527b..55b5bd24 100644 --- a/learn/monitoring/frontend-monitoring.mdx +++ b/learn/monitoring/frontend-monitoring.mdx @@ -49,7 +49,7 @@ RUM tracks actual user interactions with your application, offering insights int ![A diagram of the Real User Monitoring model](/images/learn/images/frontend-monitoring-01.png) -*A diagram of the Real User Monitoring model, with in-page Javascript reporting from a user's device to an observability service.* +*A diagram of the Real User Monitoring model, with in-page JavaScript reporting from a user's device to an observability service.* However this approach has several challenges: @@ -57,7 +57,7 @@ However this approach has several challenges: - Rum can impact browser performance for users. - Transmitting data for every user every time is quite expensive, both for you the service provider and for the user’s browser performance and network bandwidth. The suggested solution for this known issue is to sample randomly: when a user starts a session on your site, they’re randomly assigned whether that session will be tracked in detail and transmitted to your observability service. This raises the issue of missing key failures: when a key client reports an error on your site, but no data was captured, you’re stuck trying to replicate an issue with only a user description. - Difficulty finding patterns - user behavior is inherently inconsistent. It’s often very difficult to identify connected failures or trends based on multiple users’ inconsistent behavior. The situation is similar to the sampling problem: we’re left trying to guess what happened based on sketchy information. -- Complex implementation - from loading a javascript package to track user experience in the browser, to endpoints to collect that information, and a system to find patterns in stochastic user behavior, RUM is a complex technical challenge with extensive technical lift. If you’re trying to create a DIY solution for RUM, you’ll find that [CORS: Cross-Origin Request Blocked](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors) errors are the first of many challenges. +- Complex implementation - from loading a JavaScript package to track user experience in the browser, to endpoints to collect that information, and a system to find patterns in stochastic user behavior, RUM is a complex technical challenge with extensive technical lift. If you’re trying to create a DIY solution for RUM, you’ll find that [CORS: Cross-Origin Request Blocked](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors) errors are the first of many challenges. **Synthetic Monitoring** @@ -73,7 +73,7 @@ Synthetic monitoring solves many of the problems listed above with RUM: ![A diagram of the Synthetic Monitoring model](/images/learn/images/frontend-monitoring-02.png) -*A diagram of the Synthetic Monitoring model, with an observability service like checkly sending requests to your production service. SREs and Ops engineers can then view reports and receives alerts the moment a problem is detected.* +*A diagram of the Synthetic Monitoring model, with an observability service like Checkly sending requests to your production service. SREs and Ops engineers can then view reports and receives alerts the moment a problem is detected.* **Application Performance Monitoring (APM)** diff --git a/learn/monitoring/monitoring-as-code.mdx b/learn/monitoring/monitoring-as-code.mdx index 3dda0691..ffa41485 100644 --- a/learn/monitoring/monitoring-as-code.mdx +++ b/learn/monitoring/monitoring-as-code.mdx @@ -124,7 +124,7 @@ MaC also simplifies scaling uptime monitoring across multiple regions. By deploy ### **UI Functionality** -MaC allows you to simulate and test user interactions with your web application. For example, you can create browser checks to validate critical workflows like logging in, completing a checkout, or performing a search. +MaC allows you to simulate and test user interactions with your web application. For example, you can create Browser checks to validate critical workflows like logging in, completing a checkout, or performing a search. These automated tests ensure that every step—loading pages, submitting forms, and rendering elements—works as expected. They catch issues early, safeguarding functionality and user satisfaction. @@ -213,7 +213,7 @@ MaC makes it easy to monitor performance across regions, simulating user experie Scheduled jobs or cron jobs are crucial for automating tasks, but failures can lead to major problems if undetected. MaC enables [heartbeat monitoring](https://www.checklyhq.com/blog/heartbeat-monitoring-with-checkly/) to ensure these jobs run on schedule. -A heartbeat monitor verifies that a job reports back within the expected timeframe. If it doesn’t, an alert is triggered, giving you a chance to fix the issue before it impacts your system. +A Heartbeat monitor verifies that a job reports back within the expected timeframe. If it doesn’t, an alert is triggered, giving you a chance to fix the issue before it impacts your system. This proactive approach ensures your critical automation workflows are reliable and resilient. @@ -237,13 +237,13 @@ Checkly’s compatibility with CI/CD pipelines ensures monitoring is embedded in ### Native Playwright Support -With native Playwright support, Checkly enables you to directly use existing Playwright scripts as browser checks. This integration allows you to monitor complex user workflows—such as logins, form submissions, or multi-step transactions—without needing to rewrite tests. +With native Playwright support, Checkly enables you to directly use existing Playwright scripts as Browser checks. This integration allows you to monitor complex user workflows—such as logins, form submissions, or multi-step transactions—without needing to rewrite tests. Your monitoring aligns with your application logic, offering precise, actionable insights into the user experience. ### **Alert Management via Code** -A strong alerting strategy ensures critical issues are addressed promptly while minimizing noise for your team. With Checkly, you can configure alerting integrations like [PagerDuty](/integrations/incident-management/pagerduty) or [OpsGenie](/integrations/incident-management/opsgenie) directly in your codebase. This approach allows you to: +A strong alerting strategy ensures critical issues are addressed promptly while minimizing noise for your team. With Checkly, you can configure alerting integrations like [PagerDuty](/integrations/incident-management/pagerduty) or [Opsgenie](/integrations/incident-management/opsgenie) directly in your codebase. This approach allows you to: - Define alert thresholds, escalation paths, and severity levels as part of your monitoring setup. - Automatically deploy and update alerting configurations alongside your application changes. diff --git a/learn/monitoring/synthetic-monitoring.mdx b/learn/monitoring/synthetic-monitoring.mdx index b82cff49..fbd227b2 100644 --- a/learn/monitoring/synthetic-monitoring.mdx +++ b/learn/monitoring/synthetic-monitoring.mdx @@ -139,7 +139,7 @@ While multiple Observability vendors offer limited site pings as part of a large Checkly offers rich options for scheduling tests on a cadence, including [scheduling checks from multiple regions](https://www.checklyhq.com/blog/parallel-scheduling/), and offers the most complete answer to ‘how is our service performing for all our users? ### Monitoring as Code -At Checkly, we’ve pioneered Monitoring as Code to help shift observability left and unite testing and monitoring in the SDLC. With MaC, you can reuse real, end-to-end Playwright tests as monitors, configure alerting and thresholds with code, and deploy Dashboards and Status Pages to communicate your application’s health with internal and external stakeholders. +At Checkly, we’ve pioneered Monitoring as Code to help shift observability left and unite testing and monitoring in the SDLC. With MaC, you can reuse real, end-to-end Playwright tests as monitors, configure alerting and thresholds with code, and deploy dashboards and status pages to communicate your application’s health with internal and external stakeholders. ## Conclusion Synthetic monitoring forms the foundation of shipping a seamless user experience. It is a safety net for development and DevOps teams, allowing them to innovate confidently. By integrating synthetic monitoring with a MaC approach, we create a bridge between testing and monitoring, fostering a collaborative environment that enhances the overall health of your application. diff --git a/learn/monitoring/transaction-monitoring.mdx b/learn/monitoring/transaction-monitoring.mdx index 2a42a15f..61d87202 100644 --- a/learn/monitoring/transaction-monitoring.mdx +++ b/learn/monitoring/transaction-monitoring.mdx @@ -58,7 +58,7 @@ The synthetic transaction engine executes predefined scripts, mimicking user int **Scripting Language** -A flexible scripting language allows testers to define transactions. Languages like JavaScript, Python, or typescript are commonly used, with support for [integrating APIs](https://www.checklyhq.com/blog/what-is-api-monitoring/), [handling cookies](https://www.checklyhq.com/learn/playwright/authentication/), and [managing dynamic content](https://www.checklyhq.com/learn/playwright/iframe-interaction/). +A flexible scripting language allows testers to define transactions. Languages like JavaScript, Python, or TypeScript are commonly used, with support for [integrating APIs](https://www.checklyhq.com/blog/what-is-api-monitoring/), [handling cookies](https://www.checklyhq.com/learn/playwright/authentication/), and [managing dynamic content](https://www.checklyhq.com/learn/playwright/iframe-interaction/). **Test Execution Scheduler** @@ -114,7 +114,7 @@ Synthetic monitoring tracks key performance metrics like response time, latency, While it’s nice to imagine our service or website as self-contained, albeit with multiple internal microservices, the modern web app has more dependencies than ever, including dependencies on third party services all the way to the front end. A missing npm package or a service outage from Intercom can all cause our user experience to shift in unpredictable ways. Detecting any problems with third-party services before your users do is one of the many benefits of synthetic transaction monitoring. Some useful checks to add: - End-to-end testing of key user transaction to make sure, for example, that users can find items, add them to a cart, and check out on your e-commerce service. -- [Visual regression tests](https://www.checklyhq.com/blog/visual-regression-testing-with-playwright/) to make sure third-party javascript add ons haven’t caused problems for your front end experience. +- [Visual regression tests](https://www.checklyhq.com/blog/visual-regression-testing-with-playwright/) to make sure third-party JavaScript add ons haven’t caused problems for your front end experience. - Synthetics checks pointed directly at the third party services. If responses from the your payment provider are often unreliable, set up a monitor (and an alert) to know as soon as it has a chance to affect your users. **Compliance** @@ -138,7 +138,7 @@ When [retries are set up correctly](/communicate/alerts/overview), we should onl **Tool Integration Needs** -Integrating synthetic monitoring tools with existing systems can pose challenges, especially if the ecosystem includes multiple platforms and technologies. Seamless integration is crucial for accurate monitoring and efficient workflows, but it often requires customization and ongoing maintenance. As ‘table stakes’ your synthetic transaction monitoring tool should make its results available on a shared dashboqard, and route alerts intelligently either natively or through integration with tools like [Rootly](/integrations/incident-management/rootly) and [Pagerduty](/integrations/incident-management/pagerduty). Ideally your synthetic monitoring could automatically connect back end tracing that was started by a synthetics request. With [Checkly Traces](/resolve/traces/how-it-works), you can do just that: integrate back end traces with synthetic transaction monitoring, adding insight into the root cause of errors. +Integrating synthetic monitoring tools with existing systems can pose challenges, especially if the ecosystem includes multiple platforms and technologies. Seamless integration is crucial for accurate monitoring and efficient workflows, but it often requires customization and ongoing maintenance. As ‘table stakes’ your synthetic transaction monitoring tool should make its results available on a shared dashboqard, and route alerts intelligently either natively or through integration with tools like [Rootly](/integrations/incident-management/rootly) and [PagerDuty](/integrations/incident-management/pagerduty). Ideally your synthetic monitoring could automatically connect back end tracing that was started by a synthetics request. With [Checkly Traces](/resolve/traces/how-it-works), you can do just that: integrate back end traces with synthetic transaction monitoring, adding insight into the root cause of errors. By understanding these benefits and challenges, organizations can better implement synthetic transaction monitoring as part of a balanced observability strategy. @@ -150,7 +150,7 @@ Synthetic transaction monitoring begins with a clear understanding of what your **Crafting Realistic Test Scenarios** -Design test scenarios that mimic real-world user interactions as closely as possible. This includes simulating different devices, browsers, and network conditions to ensure comprehensive coverage. In playwright, use the [user agent](https://www.checklyhq.com/learn/playwright/challenging-flows/#bot-detection) and [viewport](https://www.checklyhq.com/learn/playwright/taking-screenshots/#generating-and-saving-screenshots) settings to simulate different scenarios. +Design test scenarios that mimic real-world user interactions as closely as possible. This includes simulating different devices, browsers, and network conditions to ensure comprehensive coverage. In Playwright, use the [user agent](https://www.checklyhq.com/learn/playwright/challenging-flows/#bot-detection) and [viewport](https://www.checklyhq.com/learn/playwright/taking-screenshots/#generating-and-saving-screenshots) settings to simulate different scenarios. **Prioritizing Business-Critical Transactions** diff --git a/learn/opentelemetry/context-propagation.mdx b/learn/opentelemetry/context-propagation.mdx index 9036c35e..8fff0672 100644 --- a/learn/opentelemetry/context-propagation.mdx +++ b/learn/opentelemetry/context-propagation.mdx @@ -91,7 +91,7 @@ At Checkly, we had a problem. We wanted to let our users connect data on the bac ![A checkly dashboard](/images/learn/images/context-propagation-02.png) -*Users of checkly data can see relevant backend performance data, but don’t send any timespans that aren’t necessary.* +*Users of Checkly data can see relevant backend performance data, but don’t send any timespans that aren’t necessary.* This is just one example of how context propagation is a key superpower for OpenTelemetry. diff --git a/learn/opentelemetry/how-to-instrument.mdx b/learn/opentelemetry/how-to-instrument.mdx index abc57fd6..475c2891 100644 --- a/learn/opentelemetry/how-to-instrument.mdx +++ b/learn/opentelemetry/how-to-instrument.mdx @@ -34,7 +34,7 @@ Auto-instrumentation eliminates the need for manual code changes by **injecting 2. **Coverage for Standard Libraries**: Many popular libraries and frameworks come with built-in support for auto-instrumentation. 3. **Consistency**: Ensures consistent telemetry for common operations, reducing the risk of missing critical observability data. - Auto-instrumentation may not offer the same level of granularity or customization as manual instrumentation. Automatic instrumentation can produce unnecessarily ‘noisy’ instrumentation, as just one example the NodeJS auto-instrumentation can produce traces with [hundreds of file system spans](https://github.com/open-telemetry/opentelemetry-js-contrib/issues/1344) that can even overrun available memory. + Auto-instrumentation may not offer the same level of granularity or customization as manual instrumentation. Automatic instrumentation can produce unnecessarily ‘noisy’ instrumentation, as just one example the Node.js auto-instrumentation can produce traces with [hundreds of file system spans](https://github.com/open-telemetry/opentelemetry-js-contrib/issues/1344) that can even overrun available memory. Finally, auto-instrumentation won’t generally produce useful results if something really unusual is happening inside your application. At base, automatic instrumentation assumes that your service is some kind of online application handling requests and sending responses. If that’s not the case, for example if your application is a machine learning system processing through a database and taking over 48 hours to produce results, you may get less useful information. In these cases, you may want to look into manually reporting [OpenTelemetry metrics](/learn/opentelemetry/metrics). diff --git a/learn/opentelemetry/what-is-the-otel-collector.mdx b/learn/opentelemetry/what-is-the-otel-collector.mdx index 53c6a879..ee2c3693 100644 --- a/learn/opentelemetry/what-is-the-otel-collector.mdx +++ b/learn/opentelemetry/what-is-the-otel-collector.mdx @@ -82,7 +82,7 @@ receivers: - targets: ['0.0.0.0:8888'] ``` -There are a large number of receivers for multiple formats of data coming in to an OpenTelemetry system. Note that, sadly, not all Prometheus data can be translated 1:1 into OTLP. The Prometheus receiver on Github is [currently listed as a work in progress](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/prometheusreceiver/README.md). +There are a large number of receivers for multiple formats of data coming in to an OpenTelemetry system. Note that, sadly, not all Prometheus data can be translated 1:1 into OTLP. The Prometheus receiver on GitHub is [currently listed as a work in progress](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/prometheusreceiver/README.md). ### Processors diff --git a/learn/playwright/assertions.mdx b/learn/playwright/assertions.mdx index 7fdbe3d0..c7db73c6 100644 --- a/learn/playwright/assertions.mdx +++ b/learn/playwright/assertions.mdx @@ -140,7 +140,7 @@ test("SpaceX-API Dragon Capsules & Next Launch", async ({ request }) => { }) ``` -`degraded` using `@checkly/playwright-helpers` states are currently only available for [Multistep Checks](/detect/synthetic-monitoring/multistep-checks/overview) and [Browser Checks](/detect/synthetic-monitoring/browser-checks/overview). +`degraded` using `@checkly/playwright-helpers` states are currently only available for [Multistep checks](/detect/synthetic-monitoring/multistep-checks/overview) and [Browser checks](/detect/synthetic-monitoring/browser-checks/overview). In this case if the response has a `200` status code but the API response time is more than 200 milliseconds, the status of this check will be degraded and the slow API response time will be included as a failed step. If the response came back as a non-200 status (indicating an error) then the check would be 'failed,' whether or not `markCheckAsDegraded` was called. You can [configure alert channels](https://www.checklyhq.com/docs/communicate/alerts/channels#managing-alert-channels) to notify you when a check has degraded. @@ -254,7 +254,7 @@ Implementing best practices can make your tests more reliable and easier to main - **Test Granularity**: Structure tests to cover distinct, isolated behaviors, making debugging easier. The choice between one 'super test' and 5 or 10 smaller tests should always go with the more granular option. Since [tests can be run in parallel](https://www.checklyhq.com/learn/playwright/testing-in-parallel/), it's likely that better test granularity will also improve test execution time. - **Create Concise Statements**: Keep assertions simple and focused. Asserting that five different page components is an indicator that you're testing multiple ideas with one test, and want to consider either breaking up your test or should at least have multiple steps. -- **Use Descriptive Messages**: Adding clear messages to assertions helps identify failures quickly. It's also good to use [test steps](https://www.checklyhq.com/blog/improve-your-playwright-documentation-with-steps/) to add more description to the exact phase where the test failed. Read further to see how to [add test steps programmatically with Typescript decorators](https://www.checklyhq.com/blog/playwright-test-steps-with-typescript-decorators/). +- **Use Descriptive Messages**: Adding clear messages to assertions helps identify failures quickly. It's also good to use [test steps](https://www.checklyhq.com/blog/improve-your-playwright-documentation-with-steps/) to add more description to the exact phase where the test failed. Read further to see how to [add test steps programmatically with TypeScript decorators](https://www.checklyhq.com/blog/playwright-test-steps-with-typescript-decorators/). - **Parameterize Assertions**: Use variables for assertion parameters to improve test readability and maintainability. - **Leverage Libraries**: Utilize existing libraries for common assertions where possible. Note that if you're running tests on a cadence, a full set of libraries may not be available in your execution environment. - **Be Specific**: Make sure your assertions are as targeted as possible to avoid false positives. Bet on auto-waiting and web-first assertions. Even a change from checking if a text label has the needed text with [`.toContain()`](https://playwright.dev/docs/api/class-genericassertions#generic-assertions-to-contain-1) rather than `toBe()` can improve the reliability of a page monitor. diff --git a/learn/playwright/bypass-totp.mdx b/learn/playwright/bypass-totp.mdx index 069aea54..b7a4254f 100644 --- a/learn/playwright/bypass-totp.mdx +++ b/learn/playwright/bypass-totp.mdx @@ -58,7 +58,7 @@ This encoded URL includes: - a secret (`SECRET`) - the issuer (`GitHub`) -**The essential piece to logging in and automating the TOTP flow is the provided secret.** You can access this secret in the Github UI by clicking 'enter this text code' to view the plain text version of the secret. +**The essential piece to logging in and automating the TOTP flow is the provided secret.** You can access this secret in the GitHub UI by clicking 'enter this text code' to view the plain text version of the secret. ![a two-factor secret](/images/samples/images/totp-2.jpeg) @@ -141,7 +141,7 @@ const totp = new OTPAuth.TOTP({ }) ``` -And fill Github’s passcode input field with a newly generated token! +And fill GitHub’s passcode input field with a newly generated token! ```js // generate the passcode when filling the input field diff --git a/learn/playwright/codegen.mdx b/learn/playwright/codegen.mdx index 7bfdbefc..632d165a 100644 --- a/learn/playwright/codegen.mdx +++ b/learn/playwright/codegen.mdx @@ -1,7 +1,7 @@ --- title: Record Automation Scripts Using Playwright Codegen description: "Generate Playwright scripts automatically with the codegen command, recording your browser interactions into editable test code with user-first locators." -subTitle: Automatically record playwright tests with codegen +subTitle: Automatically record Playwright tests with codegen date: 2025-02-20 author: Nočnica Mellifera githubUser: serverless-mom @@ -84,7 +84,7 @@ this will generate a `.toContainText(` assertion in the inspector Note that the assertions created by codegen are fairly basic, and while they could be the whole basis for a test suite, it’s a great idea to learn about [Playwright assertions](https://www.checklyhq.com/learn/playwright/assertions/) and write more complex ones yourself. You can write any calculable value into an assertion, so the sky is the limit. -### Step 4: Write tests in Java, Python, .Net or Javascript - Choose Your Target Environment +### Step 4: Write tests in Java, Python, .Net or JavaScript - Choose Your Target Environment After you're done interacting with the website, you can choose the target environment for your script. Playwright allows you to generate scripts in various languages, such as JavaScript, Python, or Playwright's own test framework. diff --git a/learn/playwright/steps-decorators.mdx b/learn/playwright/steps-decorators.mdx index 0c2eb281..dce16c9a 100644 --- a/learn/playwright/steps-decorators.mdx +++ b/learn/playwright/steps-decorators.mdx @@ -1,5 +1,5 @@ --- -title: Self-documenting tests - add automatic Playwright steps with Typescript Decorators +title: Self-documenting tests - add automatic Playwright steps with TypeScript Decorators description: "Structure complex Playwright tests with a single @step TypeScript decorator, replacing repetitive test.step calls to make reports easier to scan." subTitle: Understand tests better with steps date: 2024-11-15 diff --git a/learn/playwright/testing-apis.mdx b/learn/playwright/testing-apis.mdx index 70ed4091..4c1e5ac8 100644 --- a/learn/playwright/testing-apis.mdx +++ b/learn/playwright/testing-apis.mdx @@ -105,7 +105,7 @@ test('the GraphQL API works', async ({ request }) => { }) ``` -This version requires that you provide a JSON file with the expected response (that response.json file that's imported at the top). That's not ideal, instead, let's use playwright's snapshot tool so that we can take an initial snapshot of the JSON and compare later runs to that initial version. We'll replace the line: +This version requires that you provide a JSON file with the expected response (that response.json file that's imported at the top). That's not ideal, instead, let's use Playwright's snapshot tool so that we can take an initial snapshot of the JSON and compare later runs to that initial version. We'll replace the line: `expect(body).toEqual(countryData)` with @@ -150,7 +150,7 @@ By running multiple small API requests from within Playwright, you can verify th The dashboard for a Checkly API check, complete with response times, failures and retries, and checks run from multiple locations -As a bonus, Checkly’s API checks are cheaper to run than browser checks. +As a bonus, Checkly’s API checks are cheaper to run than Browser checks. ## Conclusion diff --git a/learn/playwright/testing-pyramid.mdx b/learn/playwright/testing-pyramid.mdx index 4c428194..cf3ccff1 100644 --- a/learn/playwright/testing-pyramid.mdx +++ b/learn/playwright/testing-pyramid.mdx @@ -186,7 +186,7 @@ At base, the advantage of end-to-end testing is that it answers the real questio ### From E2E Testing to E2E Monitoring -If we agree on the importance of end-to-end testing, it begs the question if testing should stop after deploy time. Thousands of unforseen interactions can break a production service even after the code is tested post-deployment, and our users are certainly using the service all the time. Shouldn’t our testing also continue after the code is out? For end-to-end testing on a cadence, there’s Checkly, which uses the power of playwright to test your sites, services, and APIs around the clock. [Get started today](https://www.checklyhq.com/docs/)! +If we agree on the importance of end-to-end testing, it begs the question if testing should stop after deploy time. Thousands of unforseen interactions can break a production service even after the code is tested post-deployment, and our users are certainly using the service all the time. Shouldn’t our testing also continue after the code is out? For end-to-end testing on a cadence, there’s Checkly, which uses the power of Playwright to test your sites, services, and APIs around the clock. [Get started today](https://www.checklyhq.com/docs/)! ## What problem is the testing pyramid trying to solve? diff --git a/platform/allowlisting-traffic.mdx b/platform/allowlisting-traffic.mdx index 74fda860..94da9c2f 100644 --- a/platform/allowlisting-traffic.mdx +++ b/platform/allowlisting-traffic.mdx @@ -68,14 +68,14 @@ You can then [set the Cookie header](/detect/synthetic-monitoring/api-checks/con > You can set the header at group-level using [API check defaults](/platform/groups#headers--query-parameters) to have it applied to every API check in the group. -### Allowlisting browser checks with user agents +### Allowlisting Browser checks with user agents -To allowlist browser checks, allow traffic with user agent containing `Checkly/`, with `` being your shortened Checkly ID or another chosen value. +To allowlist Browser checks, allow traffic with user agent containing `Checkly/`, with `` being your shortened Checkly ID or another chosen value. -You will then be able to set up the matching user agent in your browser checks using Playwright's [`userAgent`](https://playwright.dev/docs/emulation#user-agent) property. +You will then be able to set up the matching user agent in your Browser checks using Playwright's [`userAgent`](https://playwright.dev/docs/emulation#user-agent) property. - + ```ts user-agent.spec.ts import { test } from '@playwright/test' @@ -103,7 +103,7 @@ test('my user agent test', async ({ page }) => { -### Allowlisting Playwright check suites with user agents +### Allowlisting Playwright Check Suites with user agents You can configure the user agent globally in your `playwright.config.ts` file to ensure all your Playwright tests use the Checkly user agent. @@ -167,7 +167,7 @@ export default defineConfig({ ## Filtering Google Analytics -You might want to filter Checkly traffic in Google Analytics to prevent Checkly browser checks from skewing your results. +You might want to filter Checkly traffic in Google Analytics to prevent Checkly Browser checks from skewing your results. If you are using Google Analytics 4 or newer, Checkly traffic is [already being excluded](https://support.google.com/analytics/answer/9888366?hl=en) as it is recognized as coming from a known bot-traffic source. diff --git a/platform/dynamic-secret-scrubbing.mdx b/platform/dynamic-secret-scrubbing.mdx index 164a2cd9..b022b8ff 100644 --- a/platform/dynamic-secret-scrubbing.mdx +++ b/platform/dynamic-secret-scrubbing.mdx @@ -14,7 +14,7 @@ Set environment variables with the `CHECKLY_SECRET_*` prefix and the runtime wil ## How it works -Currently, dynamic secret scrubbing is only supported for Browser and Multi-Step Checks. +Currently, dynamic secret scrubbing is only supported for Browser and Multistep checks. Assign values to `process.env.CHECKLY_SECRET_*` in your check code: @@ -52,7 +52,7 @@ process.env.CHECKLY_SECRET_PAYMENT_KEY = await vault.get('payment-api-key') ## Limitations -- **Check types**: Only works in browser and multistep checks +- **Check types**: Only works in Browser and Multistep checks - **Value format**: Must be a string (empty strings, `null`, `undefined`, numbers, objects, and arrays are ignored) - **Size limit**: Values cannot exceed 128KB (~128,000 characters) - **Pattern-based detection**: Scrubbing works by detecting code and output structures. Complex or unconventional Playwright usage may fall outside of this detection. Follow the documented patterns for reliable scrubbing. diff --git a/platform/groups.mdx b/platform/groups.mdx index c1eede4d..b6b9d508 100644 --- a/platform/groups.mdx +++ b/platform/groups.mdx @@ -100,9 +100,9 @@ A common scenario for having two levels of setup scripts is the following: ### Variables You can set both variables and secrets for a Group of checks. -For browser and multistep checks, you can set variables at the check level. See [browser check variables and secrets](/platform/variables) for more details. +For Browser and Multistep checks, you can set variables at the check level. See [Browser check variables and secrets](/platform/variables) for more details. -Secrets are fully supported starting with runtime version 2024.09 and later. For [Private Locations](/platform/private-locations/overview), secrets are available in agent version `3.3.4` and later, and for the [CLI](/cli/overview), in version `4.9.0` and later. +Secrets are fully supported starting with runtime version 2024.09 and later. For [private locations](/platform/private-locations/overview), secrets are available in agent version `3.3.4` and later, and for the [CLI](/cli/overview), in version `4.9.0` and later. #### Variable hierarchy @@ -126,7 +126,7 @@ that variable to be overridden at the group level or check level. ### Testing & Runtimes - **Testing:** Run checks in this group as E2E tests locally or from CI/CD pipelines -- **Runtimes:** Set the JavaScript runtime environment for browser checks and scripts if different from account default +- **Runtimes:** Set the JavaScript runtime environment for Browser checks and scripts if different from account default diff --git a/platform/ip-information.mdx b/platform/ip-information.mdx index 0cadae1b..77872f71 100644 --- a/platform/ip-information.mdx +++ b/platform/ip-information.mdx @@ -11,9 +11,9 @@ canonical: 'https://www.checklyhq.com/docs/platform/ip-information/' Checkly supports both IPv4 and IPv6. We have a dual stack setup, meaning that we can reach both IPv4 and IPv6 addresses from our check runtime. -Note that for most workloads (API checks, browser checks, etc.) the IPv6 stack is preferred over IPv4. This means that if your endpoint is reachable over IPv6, we will use that. If not, we will fall back to IPv4. +Note that for most workloads (API checks, Browser checks, etc.) the IPv6 stack is preferred over IPv4. This means that if your endpoint is reachable over IPv6, we will use that. If not, we will fall back to IPv4. -You can actually influence this behaviour in a browser check by passing the `--host-resolver-rules` flag to a `chromium` instance. In the code example below, we force the browser to use IPv4, whereas the host `dual.tlund.se` is reachable over both IPv4 and IPv6. +You can actually influence this behaviour in a Browser check by passing the `--host-resolver-rules` flag to a `chromium` instance. In the code example below, we force the browser to use IPv4, whereas the host `dual.tlund.se` is reachable over both IPv4 and IPv6. ```ts resolver.spec.ts import { test, chromium } from '@playwright/test' diff --git a/platform/manage-secrets-at-scale.mdx b/platform/manage-secrets-at-scale.mdx index 72b54914..209f15b2 100644 --- a/platform/manage-secrets-at-scale.mdx +++ b/platform/manage-secrets-at-scale.mdx @@ -13,7 +13,7 @@ This prevents every check execution from receiving a large account-wide secret s - A Checkly Monitoring as Code project using a current version of the Checkly CLI. - A secrets manager that your CI/CD workload can authenticate to. - Permission to deploy the checks and groups that will use the secrets. - - Runtime `2024.09` or later. Private Locations require agent `3.3.4` or later. + - Runtime `2024.09` or later. Private locations require agent `3.3.4` or later. ## Understand the names in these examples @@ -132,7 +132,7 @@ new ApiCheck('payments-admin-health', { }) ``` -Inside Browser, Multi-Step, Playwright, and API setup or teardown scripts, read the deployed value with `process.env.PAYMENTS_ADMIN_TOKEN` instead. +Inside Browser, Multistep, Playwright, and API setup or teardown scripts, read the deployed value with `process.env.PAYMENTS_ADMIN_TOKEN` instead. ## Treat the deployment as authoritative @@ -162,4 +162,4 @@ Use the guide for your secrets manager: - [Azure Key Vault](/integrations/ci-cd/github/secrets/azure-key-vault) - [HashiCorp Vault](/integrations/ci-cd/github/secrets/hashicorp-vault) -For Browser and Multi-Step checks that must retrieve credentials while the check is running, see [Dynamic Secret Scrubbing](/platform/dynamic-secret-scrubbing). Runtime retrieval is a separate pattern with different check-type support. +For Browser and Multistep checks that must retrieve credentials while the check is running, see [Dynamic Secret Scrubbing](/platform/dynamic-secret-scrubbing). Runtime retrieval is a separate pattern with different check-type support. diff --git a/platform/private-locations/agent-configuration.mdx b/platform/private-locations/agent-configuration.mdx index ae4504a6..fdb7ce13 100644 --- a/platform/private-locations/agent-configuration.mdx +++ b/platform/private-locations/agent-configuration.mdx @@ -4,13 +4,13 @@ description: "Configure the Checkly Agent for a private location with environmen canonical: 'https://www.checklyhq.com/docs/platform/private-locations/agent-configuration/' --- -The Checkly Agent is a container that you need to deploy to run a Private Location in Checkly. The agent needs to be deployed on your infrastructure and executes checks on behalf of the Checkly application. For installation details, [check the getting started guide](/platform/private-locations/overview). +The Checkly Agent is a container that you need to deploy to run a private location in Checkly. The agent needs to be deployed on your infrastructure and executes checks on behalf of the Checkly application. For installation details, [check the getting started guide](/platform/private-locations/overview). The Checkly Agent has several environment variables that can be configured: Variable|Description ---|--- -`API_KEY`|API key for the Private Location in which the agent will serve. The API key is shown in the web app once, when initially creating a Private Location. +`API_KEY`|API key for the private location in which the agent will serve. The API key is shown in the web app once, when initially creating a private location. `HTTPS_PROXY`|HTTPS proxy configuration for the outbound connection to the Checkly API, used for agent management and monitoring. `https://user:password@127.0.0.1:8080` `HTTP_PROXY`|HTTP proxy configuration for the outbound connection to the Checkly API, used for agent management and monitoring. Used if the proxy server does not accept HTTPS connections. `http://user:password@127.0.0.1:8080` `JOB_CONCURRENCY`|(Default: 1, recommended: up to 10) Number of concurrent Browser, Multistep and Playwright checks that are run by the agent. Not used by the [uptime image](/platform/private-locations/agent-images#uptime-image). @@ -114,16 +114,16 @@ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock containrrr/watchtow ## Rotating API keys -API keys can be rotated as necessary in order to maintain good security practices or in case a key is lost or compromised. A Private Location can have two active API keys. To rotate the API keys: +API keys can be rotated as necessary in order to maintain good security practices or in case a key is lost or compromised. A private location can have two active API keys. To rotate the API keys: -1. Click **Private locations** in the left sidebar (under **Configuration**) to open the [Private Locations page](https://app.checklyhq.com/accounts/private-locations). -2. Click the edit icon on the Private Location you want to update. -3. There will only be a single API key in place on a new Private Location. Click Add new API key to add the second key. +1. Click **Private locations** in the left sidebar (under **Configuration**) to open the [Private locations page](https://app.checklyhq.com/accounts/private-locations). +2. Click the edit icon on the private location you want to update. +3. There will only be a single API key in place on a new private location. Click Add new API key to add the second key. 4. The new API key will appear. Click the copy icon to copy it to your clipboard and save it somewhere secure. ![new key](/images/docs/images/private-locations/new_key.png) -5. Click Save to close the dialog. You can now see the trailing characters of the two defined API keys in the list of Private Locations. +5. Click Save to close the dialog. You can now see the trailing characters of the two defined API keys in the list of private locations. ![two keys](/images/docs/images/private-locations/two_keys.png) @@ -133,7 +133,7 @@ API keys can be rotated as necessary in order to maintain good security practice docker run -e API_KEY="pl_...." -d checkly/agent:latest ``` -7. Make sure the new agents are running properly. You can check the agent count on the Private Locations page, or check your container logs. Remove the old agent containers: +7. Make sure the new agents are running properly. You can check the agent count on the Private locations page, or check your container logs. Remove the old agent containers: ```bash Terminal docker stop @@ -141,9 +141,9 @@ docker stop If you lose track of which agent containers are using the old API key, you can use the `docker inspect ` command and look for the `API_KEY` variable in the output. -8. Now that your new agents are in place, remove the old API key. Click the edit icon in the Private Location again. +8. Now that your new agents are in place, remove the old API key. Click the edit icon in the private location again. 9. Click the delete icon next to the old API key (verified by the shown trailing characters) then click the confirmation. -10. Click Save to close the dialog. You will now only see the new API key listed for the Private Location. +10. Click Save to close the dialog. You will now only see the new API key listed for the private location. ## Trusting Enterprise TLS Certificates diff --git a/platform/private-locations/agent-images.mdx b/platform/private-locations/agent-images.mdx index a515c2e3..e938bf7b 100644 --- a/platform/private-locations/agent-images.mdx +++ b/platform/private-locations/agent-images.mdx @@ -49,7 +49,7 @@ It supports URL, DNS, TCP and ICMP monitors. Concurrency is controlled by `AGENT ## Dev Image -If any of the checks you run on Private Locations rely on npm packages with native code, those packages need to be compiled during installation. +If any of the checks you run on private locations rely on npm packages with native code, those packages need to be compiled during installation. The standard agent is optimized for size and doesn’t ship with build tools. In those cases, you’ll need to use the dev image instead. diff --git a/platform/private-locations/autoscaling.mdx b/platform/private-locations/autoscaling.mdx index f39945ec..3a8e68f1 100644 --- a/platform/private-locations/autoscaling.mdx +++ b/platform/private-locations/autoscaling.mdx @@ -1,6 +1,6 @@ --- title: 'Autoscaling' -description: 'Autoscale Checkly Agents in a Private Location with KEDA based on queued and in-flight check runs.' +description: 'Autoscale Checkly Agents in a private location with KEDA based on queued and in-flight check runs.' canonical: 'https://www.checklyhq.com/docs/platform/private-locations/autoscaling/' --- @@ -16,7 +16,7 @@ Scale Checkly Agent pods automatically in relation to live load. This page cover ## The signal -Checkly exposes the `checkly_private_location_check_runs` gauge through the Prometheus V2 exporter. Filtered by `state` and a `private_location_slug_name`, it provides the count of pending and currently-executing check runs in a single Private Location — the signal you drive replica count from. +Checkly exposes the `checkly_private_location_check_runs` gauge through the Prometheus V2 exporter. Filtered by `state` and a `private_location_slug_name`, it provides the count of pending and currently-executing check runs in a single private location — the signal you drive replica count from. The relevant `state` values are: @@ -24,7 +24,7 @@ The relevant `state` values are: - `inflight` — the check run is currently being executed by an agent. -The gauge is aggregated on a ~1 minute interval, so checks that start and finish within that window may be excluded — their impact on Private Location capacity is negligible. +The gauge is aggregated on a ~1 minute interval, so checks that start and finish within that window may be excluded — their impact on private location capacity is negligible. ## KEDA `ScaledObject` @@ -65,7 +65,7 @@ spec: query: sum(checkly_private_location_check_runs{queue="main", state=~"queued|inflight", private_location_slug_name=""}) ``` -The query is scoped to a single Private Location by `private_location_slug_name`, so create one `ScaledObject` per Private Location. It counts only the `main` queue: uptime monitors and API checks run on the `uptime` queue, which the agent processes with `AGENT_WORKER_COUNT` workers instead of `JOB_CONCURRENCY` slots. +The query is scoped to a single private location by `private_location_slug_name`, so create one `ScaledObject` per private location. It counts only the `main` queue: uptime monitors and API checks run on the `uptime` queue, which the agent processes with `AGENT_WORKER_COUNT` workers instead of `JOB_CONCURRENCY` slots. If you deploy agents with the [Checkly agent Helm chart](https://github.com/checkly/helm-charts/tree/main/charts/agent), template the `ScaledObject` alongside your chart values so the autoscaler ships with the deployment. @@ -90,8 +90,8 @@ For example, with `threshold: "1"`, `minReplicaCount: 2`, `maxReplicaCount: 10`: ## Tuning the bounds - **`threshold`** — set it to match the agent's `JOB_CONCURRENCY`. The default `JOB_CONCURRENCY` is `1`, so leave `threshold: "1"`. A higher value packs more checks per pod and can cause scheduling delays for long-running checks. -- **`minReplicaCount`** — keep at `2` or higher so a single agent failure doesn't take the Private Location offline. See [Scaling and Redundancy](/platform/private-locations/scaling-redundancy). -- **`maxReplicaCount`** — must exceed your expected peak queued + in-flight check runs. If the cap is too low, queued check runs accumulate above it and are dropped once the queue TTL expires: 10 minutes for the main queue on current agents, 6 minutes for uptime monitors and for Private Locations still running an older agent. +- **`minReplicaCount`** — keep at `2` or higher so a single agent failure doesn't take the private location offline. See [Scaling and Redundancy](/platform/private-locations/scaling-redundancy). +- **`maxReplicaCount`** — must exceed your expected peak queued + in-flight check runs. If the cap is too low, queued check runs accumulate above it and are dropped once the queue TTL expires: 10 minutes for the main queue on current agents, 6 minutes for uptime monitors and for private locations still running an older agent. If you set `minReplicaCount: 0` to scale to zero when idle, [`cooldownPeriod`](https://keda.sh/docs/latest/reference/scaledobject-spec/#cooldownperiod) becomes important — it controls how long KEDA waits after the trigger goes inactive before scaling the deployment down to zero. @@ -131,7 +131,7 @@ Maximum runtime by check type: sum(checkly_private_location_check_runs{queue="main", state=~"queued|inflight", private_location_slug_name=""}) ``` -3. Schedule a burst of checks against the Private Location and watch the replica count climb toward `maxReplicaCount`, then settle back to `minReplicaCount` once the burst clears. +3. Schedule a burst of checks against the private location and watch the replica count climb toward `maxReplicaCount`, then settle back to `minReplicaCount` once the burst clears. ## See also diff --git a/platform/private-locations/change-log.mdx b/platform/private-locations/change-log.mdx index 4269e9ce..06672897 100644 --- a/platform/private-locations/change-log.mdx +++ b/platform/private-locations/change-log.mdx @@ -123,8 +123,8 @@ Learn more about: -- Added support for cancelling running Playwright check suites -- Playwright check suites can run in different NodeJs or Bun versions (22, 24, 26 or Bun 1.3) +- Added support for cancelling running Playwright Check Suites +- Playwright Check Suites can run in different Node.js or Bun versions (22, 24, 26 or Bun 1.3) @@ -193,9 +193,9 @@ Updated packages: - - Added support for running [ICMP](/detect/uptime-monitoring/icmp-monitors/overview) and [DNS monitors](/detect/uptime-monitoring/dns-monitors/overview) on Private Locations + - Added support for running [ICMP](/detect/uptime-monitoring/icmp-monitors/overview) and [DNS monitors](/detect/uptime-monitoring/dns-monitors/overview) on private locations - Introduced the [uptime agent image](/platform/private-locations/agent-images#uptime-image), a lightweight version of the agent for running uptime monitors (URL, DNS, TCP, ICMP) only - - Added [external observability](/platform/private-locations/agent-configuration#external-observability) for Private Location agents to capture runtime errors + - Added [external observability](/platform/private-locations/agent-configuration#external-observability) for private location agents to capture runtime errors - Error-level events can be reported to Checkly to help detect crashes, bugs, and environment-related issues - Only limited technical metadata is collected (error message, stack trace, agent version, platform, Go runtime) - Sensitive data such as API keys, environment variables, check configuration, URLs, headers, and response bodies is never sent @@ -239,7 +239,7 @@ Updated packages: Added Checkly environment variables and configuration to [Playwright Check Suites](/detect/synthetic-monitoring/playwright-checks/overview). See the docs on [Playwright Check Suites environment variables](/detect/synthetic-monitoring/playwright-checks/environment-variables): - - Adds support for `CHECKLY` to all checkly triggered runs: scheduled checks and test sessions triggered through either `npx checkly test`, `npx checkly trigger` or `npx checkly pw-test` + - Adds support for `CHECKLY` to all Checkly triggered runs: scheduled checks and test sessions triggered through either `npx checkly test`, `npx checkly trigger` or `npx checkly pw-test` - Includes the environment variable `CI` as true only for test session triggered runs diff --git a/platform/private-locations/kubernetes-deployment.mdx b/platform/private-locations/kubernetes-deployment.mdx index c1283f45..26371046 100644 --- a/platform/private-locations/kubernetes-deployment.mdx +++ b/platform/private-locations/kubernetes-deployment.mdx @@ -8,7 +8,7 @@ We advise running any production-grade Checkly Agent deployments on a container ## Prerequisites -- You've [created a Private Location](/platform/private-locations/overview) and have an API key +- You've [created a private location](/platform/private-locations/overview) and have an API key - You have a running Kubernetes cluster - [Helm](https://helm.sh/) is installed diff --git a/platform/private-locations/overview.mdx b/platform/private-locations/overview.mdx index 2111ac71..19a79a74 100644 --- a/platform/private-locations/overview.mdx +++ b/platform/private-locations/overview.mdx @@ -1,6 +1,6 @@ --- -title: 'Getting started with Private Locations' -description: 'Monitor internal systems and test from custom locations using Checkly Private Locations. Run checks from within your own infrastructure with the lightweight Checkly Agent.' +title: 'Getting started with private locations' +description: 'Monitor internal systems and test from custom locations using Checkly private locations. Run checks from within your own infrastructure with the lightweight Checkly Agent.' sidebarTitle: 'Overview' canonical: 'https://www.checklyhq.com/docs/platform/private-locations/overview/' --- @@ -10,18 +10,18 @@ canonical: 'https://www.checklyhq.com/docs/platform/private-locations/overview/' -**Owner** or **Admin** permissions are required to create, edit, and delete Private Locations. +**Owner** or **Admin** permissions are required to create, edit, and delete private locations. -A Private Location is a monitoring location that you manage by simply deploying a lightweight Checkly Agent. +A private location is a monitoring location that you manage by simply deploying a lightweight Checkly Agent. -Running a check from a Private Location allows you to: +Running a check from a private location allows you to: - **Monitor internal systems**: Test the performance and reliability of applications and APIs that are only accessible from within your network (e.g., development environments, intranet tools) - **Test from anywhere**: Test the performance and reliability of applications and APIs from different parts of the world. Install your Checkly Agent(s) for location-based performance insights, that we don't cover with our [Global Locations](/concepts/locations) -Configure your checks to use your Private Location and that's it. As long as you have at least one operational Checkly Agent, checks will run in your Private Location. [Adding more agents](/platform/private-locations/scaling-redundancy) will distribute the load and improve resilience automatically. +Configure your checks to use your private location and that's it. As long as you have at least one operational Checkly Agent, checks will run in your private location. [Adding more agents](/platform/private-locations/scaling-redundancy) will distribute the load and improve resilience automatically. ## Requirements @@ -29,12 +29,12 @@ Here are the requirements before you get started: - A container runtime (we test using Docker, but other runtimes should work) - Outbound internet access for the Agent to https://agent.checklyhq.com (proxy configuration is supported) -- Access to your API or browser-based applications and services from the Private Location network -- Owner or Admin permissions (required to create, edit, and delete Private Locations) +- Access to your API or browser-based applications and services from the private location network +- Owner or Admin permissions (required to create, edit, and delete private locations) -## Configuring a Private Location +## Configuring a private location -1. Navigate to the [Private Locations page](https://app.checklyhq.com/private-locations) and click "New private location" +1. Navigate to the [Private locations page](https://app.checklyhq.com/private-locations) and click "New private location" ![private locations screen](/images/docs/images/private-locations/pl_started_1.png) @@ -54,7 +54,7 @@ docker run -e API_KEY="pl_...." -d checkly/agent:latest ``` -5. Refresh the Private Locations page in the Checkly app and you will see a count of the number of running agents. +5. Refresh the Private locations page in the Checkly app and you will see a count of the number of running agents. ![agent running](/images/docs/images/private-locations/pl_started_4.png) @@ -63,9 +63,9 @@ docker run -e API_KEY="pl_...." -d checkly/agent:latest ![select private location](/images/docs/images/private-locations/pl_started_5.png) -## Using Private Locations with the CLI +## Using private locations with the CLI -With the [Checkly CLI](/cli/overview), you can configure any check to run on a Private Location by adding the slug name to the `privateLocations` array. For example, with an [ApiCheck construct](/constructs/api-check): +With the [Checkly CLI](/cli/overview), you can configure any check to run on a private location by adding the slug name to the `privateLocations` array. For example, with an [ApiCheck construct](/constructs/api-check): ```ts {title="api.check.ts"} import { ApiCheck } from 'checkly/constructs' @@ -83,13 +83,13 @@ new ApiCheck('hello-api-1', { }) ``` -## Unavailable Private Locations +## Unavailable private locations If a private location has checks assigned but no Checkly agents connected in the last 10 to 20 minutes, it will be flagged as unavailable. Checkly will email account owners and admins when this happens. While a location is unavailable, no checks will be scheduled to run on it. When a location becomes available, check scheduling and execution will resume automatically. -## Using Playwright Check Suites in Private Locations +## Using Playwright Check Suites in private locations We recommend to update the Checkly agent regularly. @@ -99,7 +99,7 @@ Please use a minimum container size of 2 CPU cores and 4 GB of RAM when running ## Next Steps -Once your first agent is running, explore these topics to start using Private Locations in production: +Once your first agent is running, explore these topics to start using private locations in production: diff --git a/platform/private-locations/proxy-setup.mdx b/platform/private-locations/proxy-setup.mdx index 73b20d56..8f6ac5aa 100644 --- a/platform/private-locations/proxy-setup.mdx +++ b/platform/private-locations/proxy-setup.mdx @@ -1,6 +1,6 @@ --- title: 'Proxy Setup' -description: 'Configure HTTP proxies for Checkly Private Locations in enterprise environments. Set up proxy routing for both agent management traffic and check execution.' +description: 'Configure HTTP proxies for Checkly private locations in enterprise environments. Set up proxy routing for both agent management traffic and check execution.' canonical: 'https://www.checklyhq.com/docs/platform/private-locations/proxy-setup/' --- @@ -12,24 +12,24 @@ setup. > Note you can also define a proxy for management traffic from your private location to the Checkly API where we ingest > your telemetry and management events. See [the environment variables available to the Checkly Agent container](/platform/private-locations/agent-configuration) -## Setting an HTTP proxy for your Private Location +## Setting an HTTP proxy for your private location We recommend storing the URL of your proxy in a [global environment variable](https://app.checklyhq.com/environment-variables) -so you can easily reuse it in your Private Location configuration and checks. In the example below we store it as `PROXY_URL` +so you can easily reuse it in your private location configuration and checks. In the example below we store it as `PROXY_URL` ![private location proxy url](/images/docs/images/private-locations/proxy_private_locations_1.png) -After this, you can reference this variable using `{{PROXY_URL}}` in the Private Location configuration. +After this, you can reference this variable using `{{PROXY_URL}}` in the private location configuration. ![private location proxy url](/images/docs/images/private-locations/proxy_private_locations_2.png) ## Using an HTTP proxy -With the setup complete, any API check or URL monitor which uses that Private Location will automatically inherit the proxy configuration for outgoing traffic. Other uptime monitors (TCP, DNS, ICMP, traceroute, gRPC and SSL) don't use the proxy. +With the setup complete, any API check or URL monitor which uses that private location will automatically inherit the proxy configuration for outgoing traffic. Other uptime monitors (TCP, DNS, ICMP, traceroute, gRPC and SSL) don't use the proxy. ## Using an HTTP proxy with Browser checks -You can enable your proxy directly in your browser checks via a few extra lines of code, using the `process.env.PROXY_URL` +You can enable your proxy directly in your Browser checks via a few extra lines of code, using the `process.env.PROXY_URL` notation and Playwright Test's `test.use()` method: @@ -65,5 +65,5 @@ test('Go to google.com', async ({ page }) => { -This is all that is required for a browser check to proxy all outbound network connections via your designated HTTP proxy. +This is all that is required for a Browser check to proxy all outbound network connections via your designated HTTP proxy. Check out both the Playwright [networking docs](https://playwright.dev/docs/network#http-proxy) and the Chromium [network settings docs](https://www.chromium.org/developers/design-documents/network-settings/) for some more information. diff --git a/platform/private-locations/scaling-redundancy.mdx b/platform/private-locations/scaling-redundancy.mdx index c6d3de6d..9ddde2ca 100644 --- a/platform/private-locations/scaling-redundancy.mdx +++ b/platform/private-locations/scaling-redundancy.mdx @@ -1,21 +1,21 @@ --- title: 'Scaling and Redundancy' -description: 'Plan capacity, implement redundancy, and scale Checkly Private Locations for production workloads.' +description: 'Plan capacity, implement redundancy, and scale Checkly private locations for production workloads.' canonical: 'https://www.checklyhq.com/docs/platform/private-locations/scaling-redundancy/' --- -At least two running Checkly Agents per Private Location are recommended for redundancy. Agents are stateless and can be scaled horizontally as needed. You can add additional agents to a location at any time and remove them +At least two running Checkly Agents per private location are recommended for redundancy. Agents are stateless and can be scaled horizontally as needed. You can add additional agents to a location at any time and remove them as necessary. -If one Checkly Agent fails, the other agents in the same Private Location will continue to run the checks assigned to that location. Even checks that are currently in progress on an agent that fails will be rerun by another agent after a timeout period of 300 seconds. +If one Checkly Agent fails, the other agents in the same private location will continue to run the checks assigned to that location. Even checks that are currently in progress on an agent that fails will be rerun by another agent after a timeout period of 300 seconds. There are two cases where checks assigned to a location could fail to run: -1. All the agents in the Private Location have failed. -2. There is insufficient agent capacity in the Private Location. +1. All the agents in the private location have failed. +2. There is insufficient agent capacity in the private location. -**Checks will stay queued for up to 10 minutes** waiting for an available agent. Uptime monitors, and all checks on Private Locations that still run an older agent version, stay queued for 6 minutes. If there are no agents available or the available +**Checks will stay queued for up to 10 minutes** waiting for an available agent. Uptime monitors, and all checks on private locations that still run an older agent version, stay queued for 6 minutes. If there are no agents available or the available agents are so busy that they cannot process all the pending checks in that timeframe, the pending checks older than that will be lost. Agents can be scaled up and scaled out. Scaling up means adding additional CPU and memory allocations to existing agent @@ -37,7 +37,7 @@ Location, the formula (rounded down) is: For example: if your container has 8GB of memory allocated, you should set `JOB_CONCURRENCY` to 5 (8GB / 1.5GB per check). -If your Private Location is only running API checks or uptime monitors, for example on the +If your private location is only running API checks or uptime monitors, for example on the [uptime image](/platform/private-locations/agent-images#uptime-image), size `AGENT_WORKER_COUNT` instead: `AGENT_WORKER_COUNT = Container memory allocation (GB) / 0.15` @@ -46,13 +46,13 @@ For example: if your container has 1GB of memory allocated, you should set `AGEN ## Scale out -To determine the number of agents you need in a Private Location you first need to know the number of checks assigned to +To determine the number of agents you need in a private location you first need to know the number of checks assigned to the location and their frequency. API checks can be scheduled as frequently as every 10 seconds and Browser checks as frequently as every 1 minute. -Based on your configuration, you should be able to estimate how many checks will run per minute in your Private Location. +Based on your configuration, you should be able to estimate how many checks will run per minute in your private location. API checks have a maximum running time of 30 seconds, Browser checks 4 minutes. This means that in the worst case scenario, -a checkly agent can run two API checks per minute per `AGENT_WORKER_COUNT` slot, or 1 Browser check per 4 minutes per +a Checkly agent can run two API checks per minute per `AGENT_WORKER_COUNT` slot, or 1 Browser check per 4 minutes per `JOB_CONCURRENCY` slot. In an average configuration this will be higher and API checks are generally faster than Browser checks. Once you have an idea of how many checks will be running and you know the per-agent concurrency limit based on the diff --git a/platform/reporting/analytics-api.mdx b/platform/reporting/analytics-api.mdx index dbfefd12..d376442b 100644 --- a/platform/reporting/analytics-api.mdx +++ b/platform/reporting/analytics-api.mdx @@ -28,7 +28,7 @@ There are several endpoints, with one for each check or monitor type. | `/v1/analytics/api-checks/{checkId}` | Returns metrics for API checks | [Learn more](/api-reference/analytics/api-checks) | | `/v1/analytics/browser-checks/{checkId}` | Returns metrics for Browser checks | [Learn more](/api-reference/analytics/browser-checks) | | `/v1/analytics/multistep-checks/{id}` | Returns metrics for Multistep checks | [Learn more](/api-reference/analytics/multistep-checks) | -| `/v1/analytics/playwright-checks/{id}` | Returns metrics for Playwright check suites | [Learn more](/api-reference/analytics/playwright-checks) | +| `/v1/analytics/playwright-checks/{id}` | Returns metrics for Playwright Check Suites | [Learn more](/api-reference/analytics/playwright-checks) | | `/v1/analytics/dns/{id}` | Returns metrics for DNS monitors | [Learn more](/api-reference/analytics/dns-monitors) | | `/v1/analytics/url-monitors/{id}` | Returns metrics for URL monitors | [Learn more](/api-reference/analytics/url-monitors) | | `/v1/analytics/tcp-checks/{id}` | Returns metrics for TCP monitors | [Learn more](/api-reference/analytics/tcp-checks) | @@ -149,7 +149,7 @@ data (`TTFB_p50` and `TTFB_p90`) for the last 7 days grouping by page. > You **must** add the `X-Checkly-Account` and `Authorization` headers to authenticate. -## Creating a Grafana Dashboard +## Creating a Grafana dashboard Following these instructions you'll learn how to use the Analytics API within a [Grafana](https://grafana.com/) dashboard: diff --git a/platform/reporting/overview.mdx b/platform/reporting/overview.mdx index 89f76ff7..0bcce9af 100644 --- a/platform/reporting/overview.mdx +++ b/platform/reporting/overview.mdx @@ -9,7 +9,7 @@ The reporting dashboard provides comprehensive insights into your monitoring per ![Reporting Dashboard](/images/docs/images/reporting/dashboard.png) -## Dashboard Overview +## Dashboard overview The reporting dashboard lists your checks, 25 per page, with key performance metrics at a glance. Use this view to: diff --git a/platform/runtimes/overview.mdx b/platform/runtimes/overview.mdx index 2106907d..969cf55e 100644 --- a/platform/runtimes/overview.mdx +++ b/platform/runtimes/overview.mdx @@ -5,7 +5,7 @@ sidebarTitle: 'Overview' canonical: 'https://www.checklyhq.com/docs/platform/runtimes/overview/' --- -Checkly lets you use JavaScript code in your [Browser checks](/detect/synthetic-monitoring/browser-checks/overview), [MultiStep Checks](/detect/synthetic-monitoring/multistep-checks/overview), and optional [setup and teardown scripts](/detect/synthetic-monitoring/api-checks/setup-and-teardown) for API checks. +Checkly lets you use JavaScript code in your [Browser checks](/detect/synthetic-monitoring/browser-checks/overview), [Multistep checks](/detect/synthetic-monitoring/multistep-checks/overview), and optional [setup and teardown scripts](/detect/synthetic-monitoring/api-checks/setup-and-teardown) for API checks. This JavaScript code executes in a runtime environment that is managed by Checkly. This environment includes a specific Node.js version, Playwright version, browser binaries, and selected npm packages. We call these managed environments **runtimes**. diff --git a/platform/runtimes/runtime-specification.mdx b/platform/runtimes/runtime-specification.mdx index 1c64aee5..ee023635 100644 --- a/platform/runtimes/runtime-specification.mdx +++ b/platform/runtimes/runtime-specification.mdx @@ -10,7 +10,7 @@ By default, all Checkly runners (the isolated environments where checks execute) ## Resource limitations -### Browser and Multistep Checks +### Browser and Multistep checks Browser and Multistep checks can use up to `2.7 GiB` of memory and `1678m` [milli-CPU units](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu). This limit applies to all processes spawned by the check, including the browser, the test framework, and the test code itself. The limit is enforced by the runner and is not configurable. @@ -57,7 +57,7 @@ import * as path from 'path' - util - zlib -See the built-in module documentation on the official Node.js site (please see below which runtime includes what NodeJS version): +See the built-in module documentation on the official Node.js site (please see below which runtime includes what Node.js version): - [24.x](https://nodejs.org/dist/latest-v24.x/docs/api/) - [22.x](https://nodejs.org/dist/latest-v22.x/docs/api/) @@ -459,7 +459,7 @@ The main updates are Playwright 1.32.1, faker 7.6.0 and the addition of date-fns Node.js Version: `v16.20.2` -The main updates are Playwright 1.28.0, Node.js v16.20.2 and Typescript support. We are dropping support for Puppeteer. +The main updates are Playwright 1.28.0, Node.js v16.20.2 and TypeScript support. We are dropping support for Puppeteer. - [@faker-js/faker](https://npmjs.com/package/@faker-js/faker/v/5.5.3) 5.5.3 - [@opentelemetry/api](https://npmjs.com/package/@opentelemetry/api/v/1.0.4) 1.0.4 diff --git a/platform/secrets.mdx b/platform/secrets.mdx index f20a9be1..df1807bd 100644 --- a/platform/secrets.mdx +++ b/platform/secrets.mdx @@ -139,7 +139,7 @@ The power of Secrets lies in making security invisible to your monitoring logic ## Alternative: Dynamic Secret Detection -For browser checks and multistep checks, you can also use dynamic secret detection. This approach allows you to retrieve secrets at runtime (from external vaults like Azure Key Vault, AWS Secrets Manager, etc.) and have them automatically scrubbed from logs and traces. +For Browser checks and Multistep checks, you can also use dynamic secret detection. This approach allows you to retrieve secrets at runtime (from external vaults like Azure Key Vault, AWS Secrets Manager, etc.) and have them automatically scrubbed from logs and traces. ```javascript // Example: Retrieve from external vault at runtime diff --git a/platform/variables.mdx b/platform/variables.mdx index 5eb97e5a..9bacc0a9 100644 --- a/platform/variables.mdx +++ b/platform/variables.mdx @@ -1,6 +1,6 @@ --- title: 'Environment variables and secrets' -sidebarTitle: 'Environment Variables' +sidebarTitle: 'Environment variables' description: 'Store and manage common configuration values across your checks' canonical: 'https://www.checklyhq.com/docs/platform/variables/' --- @@ -16,7 +16,7 @@ There are two ways to store configuration information in Checkly: Variables and * **Secrets** allow you to store sensitive data for use in checks. Once saved, secrets are never shown in the UI or in logs and cannot be accessed via the CLI or API. -Secrets are fully supported starting with runtime version 2024.09 and later. For [Private Locations](/platform/private-locations/overview/), secrets are available in agent version `3.3.4` and later, and for the [CLI](/cli/overview/), in version `4.9.0` and later. +Secrets are fully supported starting with runtime version 2024.09 and later. For [private locations](/platform/private-locations/overview/), secrets are available in agent version `3.3.4` and later, and for the [CLI](/cli/overview/), in version `4.9.0` and later. @@ -86,8 +86,8 @@ be overridden at the check level. How variables are accessed depends on where you're accessing them from: -* In [Browser](/detect/synthetic-monitoring/browser-checks/mac-structure#environment-variables), [Multistep](/detect/synthetic-monitoring/multistep-checks/overview#built-in-runtime-variables), and [API Check setup/teardown scripts](/detect/synthetic-monitoring/api-checks/setup-and-teardown#built-in-variables), use the standard Node.js `process.env.VARIABLE_NAME` notation. -* In [API Check requests](/detect/synthetic-monitoring/api-checks/configuration#accessing-environment-variables), use Handlebars/Moustache templating delimiters, i.e. `{{VARIABLE_NAME}}` +* In [Browser](/detect/synthetic-monitoring/browser-checks/mac-structure#environment-variables), [Multistep](/detect/synthetic-monitoring/multistep-checks/overview#built-in-runtime-variables), and [API check setup/teardown scripts](/detect/synthetic-monitoring/api-checks/setup-and-teardown#built-in-variables), use the standard Node.js `process.env.VARIABLE_NAME` notation. +* In [API check requests](/detect/synthetic-monitoring/api-checks/configuration#accessing-environment-variables), use Handlebars/Moustache templating delimiters, i.e. `{{VARIABLE_NAME}}` * In [webhook alert channels](/integrations/alerts/webhooks#template-variables), also use the Handlebar/Moustache format, i.e. `{{VARIABLE_NAME}}` diff --git a/quickstart.mdx b/quickstart.mdx index 302615fe..c3f2c170 100644 --- a/quickstart.mdx +++ b/quickstart.mdx @@ -102,7 +102,7 @@ The steps below use the Checkly CLI directly so you can build and deploy your mo - Checks are code. The scaffolded `__checks__/homepage.spec.ts` is a [Browser Check](/detect/synthetic-monitoring/browser-checks/quickstart): a standard `@playwright/test` file that Checkly runs as a monitor. Edit it to load a page and assert on what matters: + Checks are code. The scaffolded `__checks__/homepage.spec.ts` is a [Browser check](/detect/synthetic-monitoring/browser-checks/quickstart): a standard `@playwright/test` file that Checkly runs as a monitor. Edit it to load a page and assert on what matters: ```ts homepage.spec.ts @@ -128,7 +128,7 @@ The steps below use the Checkly CLI directly so you can build and deploy your mo ``` - Checkly turns every `*.spec.ts` file in a `__checks__` folder into a Browser Check through the `browserChecks.testMatch` pattern in your `checkly.config.ts`. To monitor an endpoint instead, edit `__checks__/api.check.ts`, which defines an [API Check](/detect/synthetic-monitoring/api-checks/quickstart). For every construct and option, see the [Constructs reference](/constructs/overview). + Checkly turns every `*.spec.ts` file in a `__checks__` folder into a Browser check through the `browserChecks.testMatch` pattern in your `checkly.config.ts`. To monitor an endpoint instead, edit `__checks__/api.check.ts`, which defines an [API check](/detect/synthetic-monitoring/api-checks/quickstart). For every construct and option, see the [Constructs reference](/constructs/overview). @@ -192,7 +192,7 @@ The steps below use the Checkly CLI directly so you can build and deploy your mo - Import the channels you defined and set them as defaults in your `checkly.config.ts` so every check, including your Browser Check, uses them. This example assumes you defined both, so import only the channels you created: + Import the channels you defined and set them as defaults in your `checkly.config.ts` so every check, including your Browser check, uses them. This example assumes you defined both, so import only the channels you created: ```ts checkly.config.ts import { defineConfig } from 'checkly' diff --git a/resolve/ai-root-cause-analysis/overview.mdx b/resolve/ai-root-cause-analysis/overview.mdx index 8a593159..3246d0f3 100644 --- a/resolve/ai-root-cause-analysis/overview.mdx +++ b/resolve/ai-root-cause-analysis/overview.mdx @@ -22,7 +22,7 @@ Rocky AI — Checkly's Agent — can automatically analyze, categorize and summa /> -Using any available artifacts like error message, user code, check description, logs, metrics, trace routes, Open Telemetry traces, packet captures, Playwright traces, screenshots and other evidence, it will quickly assess what the impact is of a failure and what the underlying (possible) root cause is. It will also provide a suggested code fix for any check based on (Playwright) code. +Using any available artifacts like error message, user code, check description, logs, metrics, trace routes, OpenTelemetry traces, packet captures, Playwright traces, screenshots and other evidence, it will quickly assess what the impact is of a failure and what the underlying (possible) root cause is. It will also provide a suggested code fix for any check based on (Playwright) code. ## Getting Started with Rocky AI Root Cause Analysis @@ -109,7 +109,7 @@ Root cause: The check is calling a ... For API, Browser, Multistep, and Playwright Checks, the **Check intent** card beside the analysis lets you select **Define intent** or **Edit intent** to open the check's settings. Use it to record the outcomes the check must prove and behavior a repair must preserve. Intent informs root cause analysis independently of whether you enable automatic repair. -For Browser and Multistep Checks, select **Repair with AI** on a completed analysis to attempt a script fix. See [Start a manual repair](../automatic-check-repair#start-a-manual-repair) for prerequisites, repair history, and restoring the original script. +For Browser and Multistep checks, select **Repair with AI** on a completed analysis to attempt a script fix. See [Start a manual repair](../automatic-check-repair#start-a-manual-repair) for prerequisites, repair history, and restoring the original script. ## Key Capabilities diff --git a/resolve/automatic-check-repair.mdx b/resolve/automatic-check-repair.mdx index 12c5fdf6..a3ed8fbd 100644 --- a/resolve/automatic-check-repair.mdx +++ b/resolve/automatic-check-repair.mdx @@ -1,17 +1,17 @@ --- title: 'Automatic check repair' sidebarTitle: 'Automatic Repair' -description: 'Configure automatic repair, start a manual attempt, and restore a Browser or Multistep Check script.' +description: 'Configure automatic repair, start a manual attempt, and restore a Browser or Multistep check script.' canonical: 'https://www.checklyhq.com/docs/resolve/automatic-check-repair/' --- -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. +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. Repair tests the proposed script before saving it to the running check. For a check managed as code, repair can also create a GitHub pull request to keep its source file in sync. Review, merge, and deploy that change so a later deployment does not overwrite the repair. -- A saved Browser or Multistep Check with at least one public execution location +- A saved Browser or Multistep check with at least one public execution location - [Edit checks and Repair checks with Rocky permissions](/admin/team-management/permissions) (`checks:update` and `check-repairs:create`) - Rocky AI enabled, with access to check repair and AI invocations available for analysis and repair - For Monitoring as Code configuration: Checkly CLI 9.4.0 or later @@ -31,7 +31,7 @@ An AI-generated check already has an intent. Review it before enabling repair. R ## Add intent to an existing check -For an existing Browser or Multistep Check, select **Initialize from saved check** in the **Check intent** section. Checkly reads the saved script and dependencies and suggests an intent. Review the suggestion, edit its goal and outcomes if needed, then save the check. The suggestion is not saved and repair is not enabled just by selecting the button. +For an existing Browser or Multistep check, select **Initialize from saved check** in the **Check intent** section. Checkly reads the saved script and dependencies and suggests an intent. Review the suggestion, edit its goal and outcomes if needed, then save the check. The suggestion is not saved and repair is not enabled just by selecting the button. 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. @@ -39,10 +39,10 @@ You can also write the intent yourself. Use this option when the script does not You can also define `intent` and enable repair with `aiAutoRepairEnabled` in your [Monitoring as Code](../cli/overview) configuration using the Checkly CLI. Keep the goal, required outcomes, and guardrails alongside your check definition. For a check the CLI manages, a deploy writes what the code declares, like every other property, so a value set only in Checkly is cleared by the next deploy of code that does not set it. Before that happens, the deploy plan lists the value and can [update your code with it](../cli/checkly-deploy#updating-your-code-with-changes-made-in-checkly). 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. +Use your existing Browser or Multistep check test file in these examples. - + ```ts import { BrowserCheck } from "checkly/constructs" @@ -71,7 +71,7 @@ new BrowserCheck("dashboard-browser", { ``` - + ```ts import { MultiStepCheck } from "checkly/constructs" diff --git a/resolve/traces/import/missing-spans.mdx b/resolve/traces/import/missing-spans.mdx index a611c5f1..dcfe7338 100644 --- a/resolve/traces/import/missing-spans.mdx +++ b/resolve/traces/import/missing-spans.mdx @@ -31,7 +31,7 @@ Missing spans can happen due to various reasons. Whether you're sending data to #### Sampling in the OpenTelemetry Collector - * **Step 1**. Make sure that you're filtering out non-checkly spans: + * **Step 1**. Make sure that you're filtering out non-Checkly spans: ```yaml processors: @@ -89,8 +89,8 @@ Ensure the right Authorization keys and endpoints are in use. OTEL_EXPORTER_OTLP_ENDPOINT="https://otel.eu-west-1.checklyhq.com" ``` -### Checkly Private Location setup - When setting up Traces with a [Checkly Private Location](/platform/private-locations/overview): +### Checkly private location setup + When setting up Traces with a [Checkly private location](/platform/private-locations/overview): * **Step 1**. Ensure your [Checkly Agent](https://hub.docker.com/r/checkly/agent) version is at least 3.3.5. * **Step 2**. Review your internal Firewall rules: diff --git a/resolve/traces/import/open-telemetry.mdx b/resolve/traces/import/open-telemetry.mdx index f4bf600b..c6e4aceb 100644 --- a/resolve/traces/import/open-telemetry.mdx +++ b/resolve/traces/import/open-telemetry.mdx @@ -13,7 +13,7 @@ a little setting up, but it's worth it. * An OpenTelemetry collector running and configured. -If you need to set up OpenTelemetry for the first time, please use [the Open Telemetry Collector getting started documentation](https://opentelemetry.io/docs/collector/installation/). +If you need to set up OpenTelemetry for the first time, please use [the OpenTelemetry Collector getting started documentation](https://opentelemetry.io/docs/collector/installation/). ## Step 1: Update your config @@ -54,7 +54,7 @@ service: ``` ## Step 2: Restart your collector -Grab your **OTel API key** in the *Send traces* section of the [Open Telemetry Integration page in the Checkly app](https://app.checklyhq.com/settings/account/open-telemetry). +Grab your **OTel API key** in the *Send traces* section of the [OpenTelemetry Integration page in the Checkly app](https://app.checklyhq.com/settings/account/open-telemetry). Now, export your API key in your shell by setting the `CHECKLY_OTEL_API_KEY` environment variable. ```bash Terminal diff --git a/resolve/traces/overview.mdx b/resolve/traces/overview.mdx index adba6b4a..1b6e8d0f 100644 --- a/resolve/traces/overview.mdx +++ b/resolve/traces/overview.mdx @@ -67,9 +67,9 @@ See the built-in variables for [Browser checks](/detect/synthetic-monitoring/bro ## Works hand-in-hand with Rocky AI -Checkly Traces automatically integrates with Rocky AI, helping you automatically analyze root causes of check failures. [Rocky AI Root Cause Analysis](/resolve/ai-root-cause-analysis/overview) can search, fetch and interpret Open Telemetry (OTeL) traces ingested by Checkly Traces and use it as a piece of "evidence" in determining why and where a check failed.\ +Checkly Traces automatically integrates with Rocky AI, helping you automatically analyze root causes of check failures. [Rocky AI Root Cause Analysis](/resolve/ai-root-cause-analysis/overview) can search, fetch and interpret OpenTelemetry (OTeL) traces ingested by Checkly Traces and use it as a piece of "evidence" in determining why and where a check failed.\ \ -A simple example. Your API or Playwright check fails with a 500 error. Luckily your backend is instrumented with Open Telemetry and sends a trace indicating an issue with a downstream database, 3rd party service, proxy etc. Now, Rocky AI automatically pulls these OTeL traces into its context window and correlates it with your failing check. \ +A simple example. Your API or Playwright check fails with a 500 error. Luckily your backend is instrumented with OpenTelemetry and sends a trace indicating an issue with a downstream database, 3rd party service, proxy etc. Now, Rocky AI automatically pulls these OTeL traces into its context window and correlates it with your failing check. \ \ Here's an actual example from Checkly's own backend. diff --git a/snippets/check-intent.mdx b/snippets/check-intent.mdx index 4dba37cd..0085e74e 100644 --- a/snippets/check-intent.mdx +++ b/snippets/check-intent.mdx @@ -2,7 +2,7 @@ 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. Left unset, or set to `null`, the check has no intent. -Intent is used for [automatic repair](/resolve/automatic-check-repair) only for Browser and Multistep Checks. +Intent is used for [automatic repair](/resolve/automatic-check-repair) only for Browser and Multistep checks. The object accepts the following fields: @@ -19,7 +19,7 @@ Each constraint has a required `type` and `statement`: 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: +For example, configure intent on a Browser check: ```ts import { BrowserCheck } from "checkly/constructs" diff --git a/snippets/general-monitor-options-table.mdx b/snippets/general-monitor-options-table.mdx index 839fd1a3..e52cddd4 100644 --- a/snippets/general-monitor-options-table.mdx +++ b/snippets/general-monitor-options-table.mdx @@ -8,7 +8,7 @@ | `frequency` | `Frequency` | ❌ | `EVERY_10M` | How often to run your monitor | | `group` | `CheckGroupV1` `CheckGroupV2` | ❌ | - | The CheckGroup this monitor belongs to | | `locations` | `string[]` | ❌ | `[]` | Array of public location codes | -| `privateLocations` | `string[]` | ❌ | `[]` | Array of Private Location slugs | +| `privateLocations` | `string[]` | ❌ | `[]` | Array of private location slugs | | `muted` | `boolean` | ❌ | `false` | Whether alert notifications are muted | | `tags` | `string[]` | ❌ | `[]` | Array of tags to organize monitors | | `testOnly` | `boolean` | ❌ | `false` | Only run with test, not during deploy | diff --git a/what-is-checkly.mdx b/what-is-checkly.mdx index b17e81c7..0d05a8e0 100644 --- a/what-is-checkly.mdx +++ b/what-is-checkly.mdx @@ -27,7 +27,7 @@ Checkly is an Application Reliability platform that enables teams to **test, mon Checkly has three core capabilities: - **Detect**: Testing, Uptime Monitoring, and Synthetic Monitoring with Playwright. -- **Communicate**: Customizable Alerting, Dashboards, & Status Pages for clear communication. +- **Communicate**: Customizable alerting, dashboards, & status pages for clear communication. - **Resolve**: Distributed full-stack tracing and AI-powered incident analysis and context. ## Why Checkly?