Update and add more content to groups overview page (#1195)

* feat: update group editor image on groups overview page

* feat: elaborate on different parts of check groups

* fix: missing number label in group editor image

* feat: add smaller details about check groups

* feat: tweak wording and remove unecessary info

* feat: remove redundant info and add more images

* fix: broken URL and misc improvements on groups overview page

site/content/docs/groups/_index.md

@@ -13,37 +13,64 @@ aliases:
 
 ---
 
-Groups allow you to organize your checks and centralize settings like base URL's, headers, variables and other properties
+Groups allow you to organize your checks and centralize settings like base URLs, headers, variables and other properties
 a collection of checks can share. 
 
+![Check group screenshot](/docs/images/groups/group-in-dashboard.png)
+
 Example use cases for groups are organizing your checks around:
 
 - A common URL endpoint
 - A specific team
 - 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. 
+> Group-level configurations, such as the runtime, activated & muted state, tags, and alert channels, will override check-level configurations. 
 
-## Key features
+> [!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*.
 
-The screenshot below gives a quick overview of the groups' key features.
+## Creating a check group
 
 ![Check group editor screenshot](/docs/images/groups/group-editor.png)
 
-1. **Activate and mute** all checks in a group
-2. Configure **shared settings** for all checks in the group
-    1. API check defaults like headers, assertions and setup & teardown scripts
-    2. Environment variables
-    3. Data center locations
-    4. Alert setting and alert channels
-    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    
+### Name and tags
+Pick a meaningful name for your group. A meaningful name will not only help you and others identify your group within Checkly, but it will help provide a better alerting experience if checks in this group fall into an alert state. Tags can relate your groups together, they also determine which checks are shown on your [dashboards](/docs/dashboards/).  
+
+### Checks
+Add new or existing checks to this group. If you add an existing check, the group configuration will overwrite certain check configurations, like run locations, retries, and alerting. 
+
+For example, if you create a check that runs in `eu-west-1` but then add it to a group running in `us-east-1`, then the check will run from `us-east-1` only. 
+
+### API checks defaults
+You can set [API check defaults](/docs/groups/api-check-defaults/), including a common base URL, request information, [assertions](/docs/api-checks/assertions/), and [setup & teardown scripts](/docs/api-checks/setup-teardown-scripts/), to help manage API checks.
+
+### Variables
+For configuration information commonly used by checks in this group, create [group environment variables and secrets](/docs/groups/variables/). When checks are scheduled, these will be merged with environment variables at the check and global levels.
+
+### Scheduling & locations
+Pick from our list of [public](/docs/monitoring/global-locations/) locations or from your [private](/docs/private-locations/) ones. This will override the scheduling strategy (i.e. parallel or round-robin) and location settings for checks in this group. 
+
+Checks still run on their own scheduling intervals, but you can specify a default at the group level with the `frequency` property via the [CLI](/docs/cli/constructs-reference/#checkgroup).
+
+### Retries & alerting
+
+Select your preferred [retry strategy](/docs/alerting-and-retries/retries/) for failed checks. This will override retry settings for checks in this group.
+
+You can configure [alert channels](/docs/alerting-and-retries/alert-channels) for checks in this group. If we don’t provide your preferred alert method, use [webhooks](/docs/alerting-and-retries/webhooks/) to configure your alert flow. Like with retries, this will override alert settings for checks in this group.
 
 > [!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*.
+> Make sure to select an alert channel, otherwise checks in this group *will not alert*.
+
+> Note that some alerting channels, like [SMS](/docs/alerting-and-retries/sms-delivery/) and [Phone call](/docs/alerting-and-retries/phone-calls/) are only available on our [Team and Enterprise plans](https://www.checklyhq.com/pricing/#feature-overview)
+
+### Testing
+
+You can run checks in this group as [E2E tests](/docs/testing) locally or from your CI/CD pipeline to validate your freshly deployed application. Use the Checkly CLI, or configure integrations with Vercel and GitHub.
+
+### Runtimes
+
+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.
 
 ## How we run grouped checks