Add clarification around how group and check configurations interact (#…

…1156)

* Add clarification around how group and check configurations interact

* make verbiage more explicit

* docs: highlight warnings on groups with no alert channels

---------

Co-authored-by: ragog <[email protected]>

site/content/docs/cli/constructs-reference.md

@@ -309,11 +309,12 @@ This brings the following benefits:
 
 1. Your Checks are organized in a folder in the Checkly web UI.
 2. You can trigger all Checks in a group from the web UI and via a command line trigger.
-3. You can manage group-level configuration like the runtime, activated & muted-state, tags and alert channels that trickle
-   down to all the Checks in the group.
+3. You can manage group-level configuration like the runtime, activated & muted-state, tags and alert channels that trickle down to all the Checks in the group.
 
-> 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.
+> [!WARNING]
+> Adding a check to a group means having it _only_ alert through the group's alert channels. Make sure your group has connected alert channels, or you might miss out on important alerts!
+
+> 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
 
@@ -370,7 +371,7 @@ new ApiCheck('check-group-api-check-1', {
 
 > When adding checks to a group using `testMatch`, the CLI searches for files using the corresponding [check file](/docs/cli/using-check-test-match/#checkscheckmatch) as a base path.
 
-> Note that you can configure two different `frequency` properties for API and Browser checks in a `CheckGroup` separatelly.
+> 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.
 
 ## `AlertChannel`

site/content/docs/groups/_index.md

@@ -23,6 +23,8 @@ Example use cases for groups are organizing your checks around:
 - A specific feature in your app
 - A test suite; trigger all checks after a deployment
 
+> When using groups, any group-level configurations such as the runtime, activated & muted state, tags, and alert channels are inherited by all Checks in the group. 
+
 ## Key features
 
 The screenshot below gives a quick overview of the groups' key features.
@@ -38,7 +40,10 @@ The screenshot below gives a quick overview of the groups' key features.
     5. CI/CD triggers
 3. **Run all checks in one go** with a configurable concurrency.
 4. Tweak checks in the inline "mini editor" to **quickly build up a group of similar checks**
-5. Use a **common base URL** for your API checks      
+5. Use a **common base URL** for your API checks    
+
+> [!WARNING]
+> Alert settings being controlled at group level means that a check that is part of a group that has no connected alert channels *will not alert*.
 
 ## How we run grouped checks