From b0935bbd94238c0cf3df5ed9b4018c0b2bec837d Mon Sep 17 00:00:00 2001 From: Paula Mallol Date: Wed, 17 Sep 2025 15:23:15 +0200 Subject: [PATCH 01/10] docs: update group documentation with validation troubleshooting guide --- site/content/docs/cli/constructs-reference.md | 8 +- site/content/docs/groups/_index.md | 19 ++- site/content/docs/groups/troubleshoot.md | 123 ++++++++++++++++++ 3 files changed, 143 insertions(+), 7 deletions(-) create mode 100644 site/content/docs/groups/troubleshoot.md diff --git a/site/content/docs/cli/constructs-reference.md b/site/content/docs/cli/constructs-reference.md index 2814bcf47..6621c85e4 100644 --- a/site/content/docs/cli/constructs-reference.md +++ b/site/content/docs/cli/constructs-reference.md @@ -474,7 +474,7 @@ Use the CheckGroupV2 construct to organize your Checks into groups. This comes w > Note: you will notice that managing shared configuration between Checks is very easy just using JS/TS. You might not need Check Groups for that purpose. -#### Adding Checks to a Check Group +### Adding Checks to a Check Group You can add a Check to a group in two ways. @@ -533,6 +533,12 @@ new ApiCheck('check-group-api-check-1', { > Note that you can configure two different `frequency` properties for API and Browser checks in a `CheckGroup` separately. > The CLI follows a fallback logic using `Check->CheckGroup->Project` configurations. +### Troubleshooting validation + +Group validation ensures that all checks within a group can support the selected configuration settings. Since uptime monitors and synthetic checks have different feature limitations based on your plan tier, Checkly validates group settings against the lowest common denominator of supported features to prevent configuration conflicts. + +For detailed troubleshooting guidance, see [Troubleshoot validation of Group](/docs/groups/troubleshoot/). + ## `CheckGroup` (deprecated) As of CLI release v6.0 the CheckGroup construct is deprecated and will be removed in a future version. We recommend migrating to [CheckGroupV2](#checkgroupv2), which offers more intuitive behavior and better control. diff --git a/site/content/docs/groups/_index.md b/site/content/docs/groups/_index.md index 6ccb4a39a..d04ca313b 100644 --- a/site/content/docs/groups/_index.md +++ b/site/content/docs/groups/_index.md @@ -17,7 +17,7 @@ Groups help you organize your checks (e.g. by team or feature) and apply shared ![Check group screenshot](/docs/images/groups/group-in-dashboard.png) -# Creating a check group +## Creating a check group By default, newly created check groups behave like folders, with no [group-level configuration](#group-level-configuration) applied. To get started: @@ -27,14 +27,16 @@ By default, newly created check groups behave like folders, with no [group-level You can populate a group by moving existing checks into it or by creating new checks directly within the group. -# Group level configuration +## Group level configuration Groups let you apply shared configuration to standardize how checks behave. Below is a breakdown of each setting and how it affects checks in the group: ### API checks defaults + You can define [API check defaults](/docs/groups/api-check-defaults/) such as a common base URL, request information, [assertions](/docs/api-checks/assertions/), and [setup & teardown scripts](/docs/api-checks/setup-teardown-scripts/) to manage API checks in your group at scale. ### Variables + For configuration information commonly used by checks in your group, create [group environment variables and secrets](/docs/groups/variables/). These are merged with variables at the global and check levels when a check runs. ### Scheduling & locations overrides @@ -62,7 +64,7 @@ You can run checks in this group as [E2E tests](/docs/testing) locally or from y Checkly manages the [runtime](/docs/runtimes) environment for your JavaScript code in browser checks and setup & teardown scripts. If the checks in this group need a runtime different from your account default, you can set that here. -# Adding or removing checks from groups +## Adding or removing checks from groups * **Moving a check into a group:** If the group has [group-level configuration](#group-level-configuration) defined, adding a check may change how it runs. Settings like API defaults, locations & scheduling, or retries & alerting can override or append to the check’s configuration. @@ -71,7 +73,7 @@ Checkly manages the [runtime](/docs/runtimes) environment for your JavaScript co > [!WARNING] > To prevent issues (e.g. broken references to group variables), the check will be automatically deactivated after being added to or removed from a group. Make sure to review its settings before reactivating. -# How we run grouped checks +## How we run grouped checks It helps to understand how we run the checks in a group, specifically if you're doing more sophisticated checks with shared variables, script and alerting channels. Here are the rules: @@ -82,5 +84,10 @@ variables, script and alerting channels. Here are the rules: 4. There are no results or metrics collected at the group level. 5. Checks in a group still have their individual scheduling settings. -As you can see, groups in their current incarnation are mostly handy configuration buckets for common properties. In the -future we will expand the group features to make them smarter. +As you can see, groups in their current incarnation are mostly handy configuration buckets for common properties. In the future we will expand the group features to make them smarter. + +## Troubleshoot validation + +Group validation ensures that all checks within a group can support the selected configuration settings. Since uptime monitors and synthetic checks have different feature limitations based on your plan tier, Checkly validates group settings against the lowest common denominator of supported features to prevent configuration conflicts. + +Learn how to [resolve validation errors](/docs/groups/troubleshoot/) when configuring Groups with mixed check types. diff --git a/site/content/docs/groups/troubleshoot.md b/site/content/docs/groups/troubleshoot.md new file mode 100644 index 000000000..73bfb6456 --- /dev/null +++ b/site/content/docs/groups/troubleshoot.md @@ -0,0 +1,123 @@ +--- +title: Troubleshoot validation of Group - Checkly Docs +displayTitle: Troubleshoot validation of Group +navTitle: Troubleshoot +weight: 30 +menu: + resources: + parent: "Groups" + identifier: troubleshoot-groups + +--- + +Groups in Checkly allow you to apply shared settings like API check defaults, scheduling strategy, locations, retries, and alerting across multiple checks. However, uptime monitors (TCP, URL, HTTP) and synthetic checks (Browser, API, Multi-step) don't always support the same features, which can lead to validation errors when mixing check types or using certain configurations on specific [plan tiers](https://www.checklyhq.com/pricing/). + +## Understanding Group Validation Rules + +When configuring groups, Checkly validates that all checks within the group can support the selected settings. The validation rules depend on your plan tier and the types of checks in your group. + +### Group Types and Validation + +**Synthetic-only groups:** All group overrides are available (same functionality as today). + +**Monitor-only groups:** Overrides are limited by your plan type. For example, only round-robin scheduling and limited retry options may be available. + +**Mixed groups (Synthetics & Monitors):** Only monitor overrides are allowed (lowest common denominator). + +> [!WARNING] +> By default, all overrides are shown if a group is created without any checks. +> +> If you set scheduling or retry overrides before adding checks, this initializes the group as either synthetic-only or monitor-only. If features like parallel runs or advanced retries are selected, monitors cannot be added to the group. + +## Affected Properties by Plan Tier + +The following table shows which group properties are supported by different check types across plan tiers: + +| Group Property | Check Type | Hobby | Starter | Team | Enterprise | +|---|---|---|---|---|---| +| **Scheduling Strategy** | *Uptime* | Round robin | Round robin | Round robin | Round robin & Parallel | +| | *Synthetics* | Round robin & Parallel | Round robin & Parallel | Round robin & Parallel | Round robin & Parallel | +| **Retries** | *Uptime* | No retries | No retries | 1 retry | Full retries | +| | *Synthetics* | Full retries | Full retries | Full retries | Full retries | +| **Locations** | *Uptime* | 4 locations | 4 locations | 22 locations | 22 locations | +| | *Synthetics* | 4 locations | 4 locations | 22 locations | 22 locations | +| **Private Locations** | *Uptime* | No | No | Yes | Yes | +| | *Synthetics* | No | No | Yes | Yes | +| **Setup & Teardown** | *Uptime (HTTP)* | No | No | No | No | +| | *Synthetics (API)* | Yes | Yes | Yes | Yes | + +## Common Validation Errors + +### Scheduling Strategy Conflicts + +**Error:** "Parallel scheduling is not supported for uptime monitors on your current plan." + +**Solution:** + +- If your group contains uptime monitors and you're on a Hobby, Starter, or Team plan, change the scheduling strategy to "Round robin" +- Alternatively, separate uptime monitors into a different group +- Upgrade to Enterprise plan + +### Retry Configuration Conflicts + +**Error:** "Advanced retry settings are not supported for uptime monitors on your current plan." + +**Solution:** + +- On Hobby and Starter plans: Remove retry configuration for groups containing uptime monitors +- On Team plans: Limit retries to 1 for groups containing uptime monitors +- Alternatively, separate uptime monitors into a different group +- Upgrade to Enterprise plan + +### Location and Private Location Restrictions + +**Error:** "Some of the selected locations are not available on your current plan." + +**Solution:** + +- Ensure you're only using locations available on your plan tier +- Upgrade to Team or Enterprise plan + +**Error:** "Private locations are not supported on your current plan." + +**Solution:** + +- Upgrade to Team or Enterprise plan + +## Resolving Validation Errors + +### For New Groups + +When creating a new group, validation occurs in real-time. If you encounter errors: + +1. [**Check your plan tier**](https://app.checklyhq.com/settings/account/billing) and review the [supported features table](/docs/groups/troubleshoot/#affected-properties-by-plan-tier) above +2. **Consider the check types** you plan to add to the group +3. **Adjust group settings** to match the lowest common denominator of supported features +4. **Separate check types** into different groups if you need advanced features for synthetic checks + +### For Existing Groups + +Existing groups that have invalid rules will show errors when you attempt to save changes. To resolve these issues: + +1. **Review the specific error message** to identify the conflicting setting +2. **Update group configuration** to use only supported features for your plan and check types +3. **Move checks to separate groups** if you need different configurations for different check types + +> [!WARNING] +> When downgrading your plan (e.g., from Team to Starter), existing groups with advanced features will show validation errors. You'll need to update the group configuration to match your new plan's limitations before you can save any changes. + +## API Check Defaults + +API check defaults defined at the group level (including request config, assertions, and setup/teardown scripts) are only applied to API checks within the group. These settings don't apply to URL monitors, even if some properties like base URL or status code assertions could technically be used. + +If you need similar defaults for URL monitors, consider creating separate groups or configure these settings individually at the check level. + +## Best Practices + +To avoid validation issues: + +- **Plan your group structure** based on check types and required features +- **Use separate groups** for uptime monitors and synthetic checks if you need advanced features +- **Start with basic configurations** and add advanced features only when all checks in the group support them +- **Review plan limitations** before configuring group overrides +- **Test group settings** with a single check before adding multiple checks to the group \ No newline at end of file From 4e254903044e84b4784745683780aed94c5f2b28 Mon Sep 17 00:00:00 2001 From: Paula Mallol Date: Thu, 18 Sep 2025 14:22:02 +0200 Subject: [PATCH 02/10] docs: update troubleshooting section for mixed monitor types in groups and remove page --- site/content/docs/cli/constructs-reference.md | 2 +- site/content/docs/groups/_index.md | 15 ++- site/content/docs/groups/troubleshoot.md | 123 ------------------ 3 files changed, 14 insertions(+), 126 deletions(-) delete mode 100644 site/content/docs/groups/troubleshoot.md diff --git a/site/content/docs/cli/constructs-reference.md b/site/content/docs/cli/constructs-reference.md index 6621c85e4..c6899a8c1 100644 --- a/site/content/docs/cli/constructs-reference.md +++ b/site/content/docs/cli/constructs-reference.md @@ -537,7 +537,7 @@ new ApiCheck('check-group-api-check-1', { Group validation ensures that all checks within a group can support the selected configuration settings. Since uptime monitors and synthetic checks have different feature limitations based on your plan tier, Checkly validates group settings against the lowest common denominator of supported features to prevent configuration conflicts. -For detailed troubleshooting guidance, see [Troubleshoot validation of Group](/docs/groups/troubleshoot/). +For detailed troubleshooting guidance, see [Troubleshooting guide](/docs/groups/#troubleshooting-mixing-different-monitor-types-in-a-group). ## `CheckGroup` (deprecated) diff --git a/site/content/docs/groups/_index.md b/site/content/docs/groups/_index.md index d04ca313b..727a4710a 100644 --- a/site/content/docs/groups/_index.md +++ b/site/content/docs/groups/_index.md @@ -88,6 +88,17 @@ As you can see, groups in their current incarnation are mostly handy configurati ## Troubleshoot validation -Group validation ensures that all checks within a group can support the selected configuration settings. Since uptime monitors and synthetic checks have different feature limitations based on your plan tier, Checkly validates group settings against the lowest common denominator of supported features to prevent configuration conflicts. +### Mixing Different Monitor Types in a Group -Learn how to [resolve validation errors](/docs/groups/troubleshoot/) when configuring Groups with mixed check types. +When you purchase a plan in Checkly, it comes with certain feature entitlements, which you can review on our [pricing page](https://www.checklyhq.com/pricing/). These entitlements differ by monitor type: + +* Synthetic checks (API, Multi-step API, Browser, Playwright Check Suites) +* Uptime monitors (URL, TCP, DNS) + +This means monitors on the same plan may not all have access to the same features. For example: Synthetic checks might support `parallel` scheduling, while Uptime monitors on the same plan only allow `round-robin` scheduling. + +Groups let you organize any type of checks/monitors together and define shared settings. If those shared settings aren’t supported by all monitors in the group, Checkly will throw a validation error asking you to either adjust the setting or remove the incompatible monitor. + +Example: If your plan only allows `round-robin` for uptime monitors and you configure the group with `parallel` scheduling, you’ll see an error. To resolve it, switch to `round-robin`, move uptime monitors into a separate group, or upgrade your plan. + +If you’re unsure how to proceed, don’t hesitate to reach out to our [support team](mailto:support@checklyhq.com), we’re happy to help. diff --git a/site/content/docs/groups/troubleshoot.md b/site/content/docs/groups/troubleshoot.md deleted file mode 100644 index 73bfb6456..000000000 --- a/site/content/docs/groups/troubleshoot.md +++ /dev/null @@ -1,123 +0,0 @@ ---- -title: Troubleshoot validation of Group - Checkly Docs -displayTitle: Troubleshoot validation of Group -navTitle: Troubleshoot -weight: 30 -menu: - resources: - parent: "Groups" - identifier: troubleshoot-groups - ---- - -Groups in Checkly allow you to apply shared settings like API check defaults, scheduling strategy, locations, retries, and alerting across multiple checks. However, uptime monitors (TCP, URL, HTTP) and synthetic checks (Browser, API, Multi-step) don't always support the same features, which can lead to validation errors when mixing check types or using certain configurations on specific [plan tiers](https://www.checklyhq.com/pricing/). - -## Understanding Group Validation Rules - -When configuring groups, Checkly validates that all checks within the group can support the selected settings. The validation rules depend on your plan tier and the types of checks in your group. - -### Group Types and Validation - -**Synthetic-only groups:** All group overrides are available (same functionality as today). - -**Monitor-only groups:** Overrides are limited by your plan type. For example, only round-robin scheduling and limited retry options may be available. - -**Mixed groups (Synthetics & Monitors):** Only monitor overrides are allowed (lowest common denominator). - -> [!WARNING] -> By default, all overrides are shown if a group is created without any checks. -> -> If you set scheduling or retry overrides before adding checks, this initializes the group as either synthetic-only or monitor-only. If features like parallel runs or advanced retries are selected, monitors cannot be added to the group. - -## Affected Properties by Plan Tier - -The following table shows which group properties are supported by different check types across plan tiers: - -| Group Property | Check Type | Hobby | Starter | Team | Enterprise | -|---|---|---|---|---|---| -| **Scheduling Strategy** | *Uptime* | Round robin | Round robin | Round robin | Round robin & Parallel | -| | *Synthetics* | Round robin & Parallel | Round robin & Parallel | Round robin & Parallel | Round robin & Parallel | -| **Retries** | *Uptime* | No retries | No retries | 1 retry | Full retries | -| | *Synthetics* | Full retries | Full retries | Full retries | Full retries | -| **Locations** | *Uptime* | 4 locations | 4 locations | 22 locations | 22 locations | -| | *Synthetics* | 4 locations | 4 locations | 22 locations | 22 locations | -| **Private Locations** | *Uptime* | No | No | Yes | Yes | -| | *Synthetics* | No | No | Yes | Yes | -| **Setup & Teardown** | *Uptime (HTTP)* | No | No | No | No | -| | *Synthetics (API)* | Yes | Yes | Yes | Yes | - -## Common Validation Errors - -### Scheduling Strategy Conflicts - -**Error:** "Parallel scheduling is not supported for uptime monitors on your current plan." - -**Solution:** - -- If your group contains uptime monitors and you're on a Hobby, Starter, or Team plan, change the scheduling strategy to "Round robin" -- Alternatively, separate uptime monitors into a different group -- Upgrade to Enterprise plan - -### Retry Configuration Conflicts - -**Error:** "Advanced retry settings are not supported for uptime monitors on your current plan." - -**Solution:** - -- On Hobby and Starter plans: Remove retry configuration for groups containing uptime monitors -- On Team plans: Limit retries to 1 for groups containing uptime monitors -- Alternatively, separate uptime monitors into a different group -- Upgrade to Enterprise plan - -### Location and Private Location Restrictions - -**Error:** "Some of the selected locations are not available on your current plan." - -**Solution:** - -- Ensure you're only using locations available on your plan tier -- Upgrade to Team or Enterprise plan - -**Error:** "Private locations are not supported on your current plan." - -**Solution:** - -- Upgrade to Team or Enterprise plan - -## Resolving Validation Errors - -### For New Groups - -When creating a new group, validation occurs in real-time. If you encounter errors: - -1. [**Check your plan tier**](https://app.checklyhq.com/settings/account/billing) and review the [supported features table](/docs/groups/troubleshoot/#affected-properties-by-plan-tier) above -2. **Consider the check types** you plan to add to the group -3. **Adjust group settings** to match the lowest common denominator of supported features -4. **Separate check types** into different groups if you need advanced features for synthetic checks - -### For Existing Groups - -Existing groups that have invalid rules will show errors when you attempt to save changes. To resolve these issues: - -1. **Review the specific error message** to identify the conflicting setting -2. **Update group configuration** to use only supported features for your plan and check types -3. **Move checks to separate groups** if you need different configurations for different check types - -> [!WARNING] -> When downgrading your plan (e.g., from Team to Starter), existing groups with advanced features will show validation errors. You'll need to update the group configuration to match your new plan's limitations before you can save any changes. - -## API Check Defaults - -API check defaults defined at the group level (including request config, assertions, and setup/teardown scripts) are only applied to API checks within the group. These settings don't apply to URL monitors, even if some properties like base URL or status code assertions could technically be used. - -If you need similar defaults for URL monitors, consider creating separate groups or configure these settings individually at the check level. - -## Best Practices - -To avoid validation issues: - -- **Plan your group structure** based on check types and required features -- **Use separate groups** for uptime monitors and synthetic checks if you need advanced features -- **Start with basic configurations** and add advanced features only when all checks in the group support them -- **Review plan limitations** before configuring group overrides -- **Test group settings** with a single check before adding multiple checks to the group \ No newline at end of file From 79c61b5a85f70212efa597eed71c2a8f417bbf55 Mon Sep 17 00:00:00 2001 From: Paula Mallol Date: Thu, 18 Sep 2025 15:45:44 +0200 Subject: [PATCH 03/10] docs: update retry strategies section to add single retry --- site/content/docs/alerting-and-retries/retries.md | 15 +++++++++------ site/content/docs/cli/constructs-reference.md | 3 ++- 2 files changed, 11 insertions(+), 7 deletions(-) diff --git a/site/content/docs/alerting-and-retries/retries.md b/site/content/docs/alerting-and-retries/retries.md index e1c2f635c..450d14440 100644 --- a/site/content/docs/alerting-and-retries/retries.md +++ b/site/content/docs/alerting-and-retries/retries.md @@ -28,14 +28,15 @@ Click **Edit check** or **Edit group** on the 3-dot menu on your [Checkly Home p There are three distinct retry strategies based on the time between retry attempts, and each one comes with different retry/backoff characteristics. +- **Retry once** — a single retry after a fixed interval, e.g. 5s. - **Fixed** — a fixed time between retries, e.g. 5s, 5s, 5s etc. - **Linear** — a linearly increasing time between retries, e.g. 5s, 10s, 15s etc. - **Exponential** — an exponentially increasing time between retries, e.g. 5s, 25s, 125s (2m and 5s) etc. On top of the time between attempts, you can also set: -* **maximum number of retries** - the maximum number of retries for this check or check group. -* **maximum total retry duration** - the maximum time a check can be in a retrying state. +- **maximum number of retries** - the maximum number of retries for this check or check group. +- **maximum total retry duration** - the maximum time a check can be in a retrying state. This is a timeout to ensure the check finishes on a timely manner. > Make sure to include the time your check needs to run when setting the **maximum total retry duration**. For example, if you set a maximum to 2 minutes, and your check takes 1.5 minutes, you have 30 seconds left for retries. @@ -57,8 +58,8 @@ Of course, picking the right strategy depends on your use case, tolerance for in ### Location-based check retries -You can decide if a check should be retried from the same location or not with the checkbox: -**Always retry from the same location the check failed in** +You can decide if a check should be retried from the same location or not with the checkbox "**Always retry from the same location the check failed in**": + - If enabled, a check that fails will be retried in the same location. - If disabled, a check that fails will be retried in a different location, from the locations your check runs at. @@ -72,8 +73,9 @@ There are some tradeoffs to consider: For API checks & URL monitors, you can enable network retries to automatically retry a check run only if it fails due to a network error—such as a timeout, DNS resolution issue, or connection reset. When network retries are enabled: -* The check will retry on: ECONNRESET, ENOTFOUND, ETIMEDOUT, EAI_AGAIN, ECONNREFUSED, and similar network errors. -* The check will not retry on: Any HTTP response that includes a status code (4xx or 5xx), failed assertions, or any other type of check failure. + +- The check will retry on: `ECONNRESET`, `ENOTFOUND`, `ETIMEDOUT`, `EAI_AGAIN`, `ECONNREFUSED`, and similar network errors. +- The check will not retry on: Any HTTP response that includes a status code (4xx or 5xx), failed assertions, or any other type of check failure. ## Test sessions retries @@ -112,6 +114,7 @@ All retry attempts are be visible on the web interface at Checkly and in your co ``` ### Test session retries in your CI/CD pipeline + Use the ``--reporter=ci`` flag to run test session retries from your CI/CD pipeline. The `ci` reporter will print out all retry attempts in the prompt output, instead of live-updating the prompt. For example: diff --git a/site/content/docs/cli/constructs-reference.md b/site/content/docs/cli/constructs-reference.md index c6899a8c1..ab11590c9 100644 --- a/site/content/docs/cli/constructs-reference.md +++ b/site/content/docs/cli/constructs-reference.md @@ -1057,7 +1057,7 @@ new ApiCheck('local-api-1', { ## `RetryStrategy` `RetryStrategy` objects can be used to configure retries for failed check runs. -Retry strategies can be set at the [check](#check), [check group](#checkgroup), and [project](#project) levels. +Retry strategies can be set at the [check](#synthetic-checks) and [monitor](#uptime-monitors), [check group](#checkgroupv2), and [project](#project) levels. [Learn more about retry strategies](/docs/alerting-and-retries/retries/#retry-strategies). To build `RetryStrategy` objects you should use the `RetryStrategyBuilder`, which provides helper methods for configuring retries. @@ -1083,6 +1083,7 @@ new ApiCheck('retrying-check', { `RetryStrategyBuilder` supports the following helper methods: - `noRetries()`: No retries are performed. +- `singleStrategy(options)`: A single retry is performed after a fixed interval, e.g. 5s and 5s. - `fixedStrategy(options)`: A fixed time between retries, e.g. 5s, 5s, 5s etc. - `linearStrategy(options)`: A linearly increasing time between retries, e.g. 5s, 10s, 15s, etc. - `exponentialStrategy(options)`: An exponentially increasing time between retries, e.g. 5s, 25s, 125s (2m and 5s) etc. From df920489059ea4566244af85b404216e58f0874e Mon Sep 17 00:00:00 2001 From: Paula Mallol Date: Thu, 18 Sep 2025 16:47:16 +0200 Subject: [PATCH 04/10] fix: tweak example for single retry strategy MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Susa Tünker <74345218+sujaya-sys@users.noreply.github.com> --- site/content/docs/cli/constructs-reference.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/site/content/docs/cli/constructs-reference.md b/site/content/docs/cli/constructs-reference.md index ab11590c9..ea704cf59 100644 --- a/site/content/docs/cli/constructs-reference.md +++ b/site/content/docs/cli/constructs-reference.md @@ -1083,7 +1083,7 @@ new ApiCheck('retrying-check', { `RetryStrategyBuilder` supports the following helper methods: - `noRetries()`: No retries are performed. -- `singleStrategy(options)`: A single retry is performed after a fixed interval, e.g. 5s and 5s. +- `singleStrategy(options)`: A single retry is performed after a fixed interval, e.g. 5s - `fixedStrategy(options)`: A fixed time between retries, e.g. 5s, 5s, 5s etc. - `linearStrategy(options)`: A linearly increasing time between retries, e.g. 5s, 10s, 15s, etc. - `exponentialStrategy(options)`: An exponentially increasing time between retries, e.g. 5s, 25s, 125s (2m and 5s) etc. From 13438a617486acfe56960a9661ed5b494c2ce31c Mon Sep 17 00:00:00 2001 From: Paula Mallol Date: Thu, 18 Sep 2025 16:48:06 +0200 Subject: [PATCH 05/10] fix: apply suggestion from @sujaya-sys MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Susa Tünker <74345218+sujaya-sys@users.noreply.github.com> --- site/content/docs/groups/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/site/content/docs/groups/_index.md b/site/content/docs/groups/_index.md index 727a4710a..ecc4cfe3f 100644 --- a/site/content/docs/groups/_index.md +++ b/site/content/docs/groups/_index.md @@ -92,7 +92,7 @@ As you can see, groups in their current incarnation are mostly handy configurati When you purchase a plan in Checkly, it comes with certain feature entitlements, which you can review on our [pricing page](https://www.checklyhq.com/pricing/). These entitlements differ by monitor type: -* Synthetic checks (API, Multi-step API, Browser, Playwright Check Suites) +* Synthetic checks (e.g. API, Multistep, Browser, Playwright Check Suites) * Uptime monitors (URL, TCP, DNS) This means monitors on the same plan may not all have access to the same features. For example: Synthetic checks might support `parallel` scheduling, while Uptime monitors on the same plan only allow `round-robin` scheduling. From b17687a90dde690e55c7b118c3e1145f1a415103 Mon Sep 17 00:00:00 2001 From: Paula Mallol Date: Thu, 18 Sep 2025 16:48:28 +0200 Subject: [PATCH 06/10] fix: apply suggestion from @sujaya-sys in synthetic checks MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Susa Tünker <74345218+sujaya-sys@users.noreply.github.com> --- site/content/docs/groups/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/site/content/docs/groups/_index.md b/site/content/docs/groups/_index.md index ecc4cfe3f..d76a6920e 100644 --- a/site/content/docs/groups/_index.md +++ b/site/content/docs/groups/_index.md @@ -93,7 +93,7 @@ As you can see, groups in their current incarnation are mostly handy configurati When you purchase a plan in Checkly, it comes with certain feature entitlements, which you can review on our [pricing page](https://www.checklyhq.com/pricing/). These entitlements differ by monitor type: * Synthetic checks (e.g. API, Multistep, Browser, Playwright Check Suites) -* Uptime monitors (URL, TCP, DNS) +* Uptime monitors (e.g. URL, TCP, DNS) This means monitors on the same plan may not all have access to the same features. For example: Synthetic checks might support `parallel` scheduling, while Uptime monitors on the same plan only allow `round-robin` scheduling. From 40eb4f519f28918e1594f5bf5c978871e057d27d Mon Sep 17 00:00:00 2001 From: Paula Mallol Date: Thu, 18 Sep 2025 16:49:23 +0200 Subject: [PATCH 07/10] refactor: apply suggestion from @sujaya-sys in example of troubleshoot MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Susa Tünker <74345218+sujaya-sys@users.noreply.github.com> --- site/content/docs/groups/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/site/content/docs/groups/_index.md b/site/content/docs/groups/_index.md index d76a6920e..666254284 100644 --- a/site/content/docs/groups/_index.md +++ b/site/content/docs/groups/_index.md @@ -95,7 +95,7 @@ When you purchase a plan in Checkly, it comes with certain feature entitlements, * Synthetic checks (e.g. API, Multistep, Browser, Playwright Check Suites) * Uptime monitors (e.g. URL, TCP, DNS) -This means monitors on the same plan may not all have access to the same features. For example: Synthetic checks might support `parallel` scheduling, while Uptime monitors on the same plan only allow `round-robin` scheduling. +This means checks and monitors on the same plan may not all have access to the same features. For example: An API check might support `parallel` scheduling, while a TCP monitor only allows for `round-robin` scheduling. Groups let you organize any type of checks/monitors together and define shared settings. If those shared settings aren’t supported by all monitors in the group, Checkly will throw a validation error asking you to either adjust the setting or remove the incompatible monitor. From 757d6895c57e4315ec3bc50a63e862d8493cffd0 Mon Sep 17 00:00:00 2001 From: Paula Mallol Date: Tue, 23 Sep 2025 12:06:49 +0200 Subject: [PATCH 08/10] refactor: update title for validation of groups Co-authored-by: Sergii Bezliudnyi --- site/content/docs/cli/constructs-reference.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/site/content/docs/cli/constructs-reference.md b/site/content/docs/cli/constructs-reference.md index ea704cf59..e0e6b9237 100644 --- a/site/content/docs/cli/constructs-reference.md +++ b/site/content/docs/cli/constructs-reference.md @@ -533,7 +533,7 @@ new ApiCheck('check-group-api-check-1', { > Note that you can configure two different `frequency` properties for API and Browser checks in a `CheckGroup` separately. > The CLI follows a fallback logic using `Check->CheckGroup->Project` configurations. -### Troubleshooting validation +### How overrides work for mixed groups Group validation ensures that all checks within a group can support the selected configuration settings. Since uptime monitors and synthetic checks have different feature limitations based on your plan tier, Checkly validates group settings against the lowest common denominator of supported features to prevent configuration conflicts. From 4969915ec354fe45c89564334b1d2db57d0fdbf5 Mon Sep 17 00:00:00 2001 From: Paula Mallol Date: Tue, 23 Sep 2025 12:48:36 +0200 Subject: [PATCH 09/10] docs: update section header for mixing different monitor types in a group --- site/content/docs/groups/_index.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/site/content/docs/groups/_index.md b/site/content/docs/groups/_index.md index 666254284..9b1937f9b 100644 --- a/site/content/docs/groups/_index.md +++ b/site/content/docs/groups/_index.md @@ -86,9 +86,7 @@ variables, script and alerting channels. Here are the rules: As you can see, groups in their current incarnation are mostly handy configuration buckets for common properties. In the future we will expand the group features to make them smarter. -## Troubleshoot validation - -### Mixing Different Monitor Types in a Group +## Mixing Different Monitor Types in a Group When you purchase a plan in Checkly, it comes with certain feature entitlements, which you can review on our [pricing page](https://www.checklyhq.com/pricing/). These entitlements differ by monitor type: From 44fcf5d1e9ee0350e57ea664246fdc5cc660f210 Mon Sep 17 00:00:00 2001 From: Paula Mallol Date: Tue, 23 Sep 2025 17:21:13 +0200 Subject: [PATCH 10/10] docs: update link text for troubleshooting guidance on monitor types in a group --- site/content/docs/cli/constructs-reference.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/site/content/docs/cli/constructs-reference.md b/site/content/docs/cli/constructs-reference.md index e0e6b9237..4c3ab77c9 100644 --- a/site/content/docs/cli/constructs-reference.md +++ b/site/content/docs/cli/constructs-reference.md @@ -537,7 +537,7 @@ new ApiCheck('check-group-api-check-1', { Group validation ensures that all checks within a group can support the selected configuration settings. Since uptime monitors and synthetic checks have different feature limitations based on your plan tier, Checkly validates group settings against the lowest common denominator of supported features to prevent configuration conflicts. -For detailed troubleshooting guidance, see [Troubleshooting guide](/docs/groups/#troubleshooting-mixing-different-monitor-types-in-a-group). +For detailed guidance, see [Mixing Different Monitor Types in a Group](/docs/groups/#mixing-different-monitor-types-in-a-group). ## `CheckGroup` (deprecated)