Merge branch 'main' into semicolon

Author: Dgiordano33

__checks__/docs-visual.spec.ts-snapshots/homepage-visual-comparison-1-chromium-linux.png

@@ -47,5 +47,5 @@ Configuring alert channels is mostly self explanatory except for our [advanced w
 After adding the channels, you either **edit** or **delete** them, or change which checks are subscribed to that specific channel.
 
 {{<info >}}
-If you are using [Terraform](/docs/terraform-provider/), you will need to specify alert channel subscriptions _explicitly_ for each check / group.
+If you are using [Terraform](/docs/terraform-provider/) or the [CLI](/docs/cli/), you will need to specify alert channel subscriptions _explicitly_ for each check / group.
 {{</info >}}

site/content/docs/alerting-and-retries/alert-channels.md

@@ -250,7 +250,7 @@ For more information about the `global` options you can check playwright officia
 
 | Option               | Supported |
 |----------------------|-----------|
-| `baseURL`            | ❌         |
+| `baseURL`            | ✅         |
 | `colorScheme`        | ✅         |
 | `geolocation`        | ✅         |
 | `locale`             | ✅         |

site/content/docs/analytics/img.png

@@ -109,8 +109,13 @@ test('my user agent test', async ({ page }) => {
 
 ## Filtering Google Analytics
 
-If you want to filter Checkly traffic in Google Analytics to prevent Checkly browser checks from skewing your
-numbers, here is one way to do it:
+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.
+
+### Older Google Analytics versions
+
+If you want to filter Checkly traffic in older Google Analytics versions, here is one way to do it:
 
 1. Add a UTM source tag to the URLs your requesting, i.e.:
 

site/content/docs/browser-checks/playwright-test.md

@@ -0,0 +1,65 @@
+---
+title: Managing false positives
+weight: 4
+menu:
+  platform:
+    parent: "Monitoring"
+---
+
+Effective monitoring stands and falls with its accuracy. You want to be alerted-and, if it comes to it, woken up in the middle of the night-only when there's a real issue. However, the reality is that false positives can occur for various reasons. A check might be affected by a harmless glitch in the network connection between Checkly and your check target, causing your site to be flagged as slow or unreachable, when, in fact, it is running perfectly fine.
+
+The public internet, with its millions of networks and nodes, can be unpredictable, making occasional hiccups unavoidable. Thankfully, many of these are just isolated incidents that resolve on their own, and there are ways to protect your monitoring setup from them. At Checkly, we aim to help you achieve the lowest false positive rate in the market, ensuring you are alerted only when it truly matters.
+
+In this guide, we’ll dive into common causes of performance variations and provide strategies to minimize false positives.
+
+## Common Causes of Performance Variations
+
+When setting up your monitoring strategy, it's important to consider a few common factors that can affect networking performance:
+
+- **Network Latency:** The time it takes for data to travel between points. This can vary due to distance, routing, or congestion.
+- **Packet Loss:** Sometimes data packets don’t reach their destination and need to be resent, leading to delays.
+- **Server Response Time:** Servers might occasionally take longer to respond, or load balancers and backend services could be at capacity.
+- **Infrastructure Issues:** Temporary issues like routing errors, server load spikes, or scheduled maintenance can also impact performance.
+- **Security-Related Blockages:** Firewalls, DDoS protection, or other security measures might prevent Checkly’s monitoring traffic from reaching your servers if flagged as suspicious. This can disrupt checks and result in false positives.
+
+While these factors are generally well-managed, they can’t be completely avoided. However, you can take steps to make your monitoring setup more resilient.
+
+## Best Practices to Minimize False Positives
+
+False positives can lead to unnecessary alerts, but you can keep them under control by following these best practices:
+
+### Use Retries
+
+Retries are your first line of defense against transient issues. By setting up retries, your checks can automatically try again if the first attempt fails because of a temporary glitch. This reduces the impact of brief disruptions and helps prevent false positives.
+
+While you might want to adjust based on specific use cases, we suggest implementing retries for checks with a high escalation impact as a standard best practice.
+
+Learn more about implementing retries: [Retries at Checkly](https://www.checklyhq.com/docs/alerting-and-retries/retries/#retries).
+
+### Optimize Your Regional Monitoring
+
+Running checks from a specific region is important when you need to monitor your app’s performance in that area. To identify localized failures, implementing retries can help confirm whether the issue is temporary or persistent. However, if you want to understand whether an issue is more widespread, running checks from multiple regions can help you determine if it’s a broader problem with your app.
+
+Depending on your use case, we recommend running checks from at least two different regions to more accurately differentiate between a regional network issue and a genuine application problem.
+
+Learn more about setting up multi-location checks: [Global Location and Scheduling Strategies](https://www.checklyhq.com/docs/monitoring/global-locations/).
+
+### Fine-Tune Your Alerting
+
+Adjust your alert settings to avoid unnecessary notifications. For example, you can require failures in multiple regions or after several retries before firing off an alert. This helps you avoid alerts for short-lived, isolated failures that don’t need immediate attention.
+
+A good starting point is to set alerts to trigger only after a check has failed at least twice (or after two intervals) and has failed in more than one region.
+
+Learn more about fine-tuning your alerts: [Alert Settings at Checkly](https://www.checklyhq.com/docs/alerting-and-retries/alert-settings/).
+
+### Allowlist Checkly Traffic
+
+In some cases, firewalls, load balancers, or security solutions might inadvertently block Checkly's monitoring traffic, which could interfere with running checks successfully. This can happen if your system detects Checkly’s requests as suspicious or treats them as unwanted traffic.
+
+To prevent this, we recommend reviewing your security settings to ensure that Checkly’s IP ranges are included in your allowlist.
+
+You can find Checkly’s current IP ranges here: [Allowlisting & filtering traffic](https://www.checklyhq.com/docs/monitoring/allowlisting/#ip-range-allowlisting).
+
+## Need Help?
+
+If you’re not sure what’s going on or if an issue keeps popping up without a clear reason, don’t hesitate to reach out. Our support team is here to help you troubleshoot any unusual check performance. You can contact us at [email protected].

site/content/docs/monitoring/allowlisting.md

@@ -1,6 +1,6 @@
 ---
 title: How we store data
-weight: 4
+weight: 5
 menu:
   platform:
     parent: "Monitoring"

site/content/docs/monitoring/false-positives.md

@@ -10,73 +10,60 @@ aliases:
 cli: true
 ---
 
-Checkly allows you to use JavaScript code in your [Browser checks](/docs/browser-checks/) and in the optional 
-[setup & teardown scripts](/docs/api-checks/setup-teardown-scripts/) you can add to your API checks.
+Checkly allows you to use JavaScript code in your [Browser checks](/docs/browser-checks/) and in the optional [setup & teardown scripts](/docs/api-checks/setup-teardown-scripts/) you can add to your API checks.
 
-This JavaScript code executes in a runtime environment that is managed by Checkly. This environment has access to specific 
-Node.js versions and NPM packages, like the "latest Playwright version on Node 14". We call these environments **runtimes**.
+This JavaScript code executes in a runtime environment that is managed by Checkly. This environment has access to specific Node.js versions and NPM packages, like the "latest Playwright version on Node 14". We call these environments **runtimes**.
 
 ## Using runtimes
 
 It's pretty easy. You don't have to do anything most of the time.
 
 1. View all the available runtimes on the [runtimes tab in the account section](https://app.checklyhq.com/settings/account/runtimes/). See the screenshot below.
 2. There is always one runtime marked as **active**. This is the runtime all checks use, unless you decide to override this at the check or group level.
-4. Runtimes have a simple `YYYY.MM` name, e.g. `2021.06` Newer dates hold newer dependencies.   
+4. Runtimes have a simple `YYYY.MM` name, e.g. `2021.06` Newer dates hold newer dependencies.
 3. Pick the runtime you want and click "Save settings". This runtime now applies to all of your checks and any new checks you create.
 
 ![runtimes](/docs/images/monitoring/[email protected])
 
-Note that one runtime version, e.g. `2021.6` holds all dependencies for all check types. There is no separate runtime for
-different types of checks.
+Note that one runtime version, e.g. `2021.06` holds all dependencies for all check types. There is no separate runtime for different types of checks.
 
 ## Overriding runtimes for specific checks
 
-Before updating your Checkly account to a new runtime, you can enable a newer runtime just for one check or check group.
-This is a very powerful way to make sure your checks are compatible with a new runtime.
+Before updating your Checkly account to a new runtime, you can enable a newer runtime just for one check or check group. This is a very powerful way to make sure your checks are compatible with a new runtime.
 
 You can:
 
 - Select a specific runtime in the **Browser check** editor.
 - Select a specific runtime in the "Setup & teardown" tab for each **API check**.
 - Select a specific runtime on the "Runtimes" tab for each **check group**.
 
-> Overriding the global, account level runtime for a handful of checks is **the recommended way to check for any compatibility issues**
- before committing to a new, global runtime. Note the hierarchy: **check** runtime trumps **group** runtime trumps **global account** runtime.
- 
+> Overriding the global, account level runtime for a handful of checks is **the recommended way to check for any compatibility issues** before committing to a new, global runtime. Note the hierarchy: **check** runtime trumps **group** runtime trumps **global account** runtime.
+
 ## How we update and release new runtimes
 
 We ship new runtimes with a regular cadence. This is what you can expect from us:
 
 **1. Major & minor version upgrades of core packages and Node.js versions**
-  
-We aim to release a new runtime that holds the major and minor upgrades of Playwright and Node.js **every quarter**.
-This will result in a new, named runtime e.g. `2023.03` available in the Checkly webapp and in our API.
+
+We aim to release a new runtime that holds the major and minor upgrades of Playwright and Node.js **every quarter**. This will result in a new, named runtime e.g. `2023.03` available in the Checkly webapp and in our API.
 
 **2. Patch releases and security patches**
 
-We reserve the right to **update an existing runtime** with critical security patches if deemed necessary. We will only do
-this if there are no known backwards compatibility issues.
+We reserve the right to **update an existing runtime** with critical security patches if deemed necessary. We will only do this if there are no known backwards compatibility issues.
 
 ## Why are runtimes important?
 
-We introduced the concept of runtimes so customers can upgrade their JavaScript enhanced checks to more recent Node package versions
-in a controlled fashion; and roll back if anything breaks! Before, this was a more risky "big bang" migration.
+We introduced the concept of runtimes so customers can upgrade their JavaScript enhanced checks to more recent Node package versions in a controlled fashion; and roll back if anything breaks! Before, this was a more risky "big bang" migration.
 
 ## Why can't I import any NPM package or other 3rd party dependencies?
 
-Currently, Checkly is not a full-blown CI system, where a user has full control over the Node.js version and the packages 
-installed in the `node_modules` directory. To help you navigate this tradeoff, we want to show you exactly what happens under
-the hood.
+Currently, Checkly is not a full-blown CI system, where a user has full control over the Node.js version and the packages installed in the `node_modules` directory. To help you navigate this tradeoff, we want to show you exactly what happens under the hood.
 
 1. We bundle all your user code when using the [Checkly CLI](/docs/cli) or GitHub Sync before storing your Check in our database.
-2. Your Check is scheduled to our 20+ global locations via a message bus that has a 256kb file size limit. This is in 99% 
+2. Your Check is scheduled to our 20+ global locations via a message bus that has a 256kb file size limit. This is in 99%
 of the cases more than enough for any user code and included file dependencies you may include. However, it is not enough for potentially unlimited
 NPM dependencies living in `node_modules`.
-3. The Checkly Runtime prepackages common 3rd party NPM modules and defines the Node.js version to avoid building, transferring and caching
-potentially each Check across multiple Node.js versions, greatly reducing complexity.
+3. The Checkly Runtime prepackages common 3rd party NPM modules and defines the Node.js version to avoid building, transferring and caching potentially each Check across multiple Node.js versions, greatly reducing complexity.
 4. Our provided Runtime packages are tested with our sandboxing for extra runtime security.
 
-If you want to see a package included in the Checkly Runtime, [please add a post on our feedback board](https://feedback.checklyhq.com/)
-with a package name, and your use case. 
-
+If you want to see a package included in the Checkly Runtime, [please add a post on our feedback board](https://feedback.checklyhq.com/) with a package name, and your use case.

site/content/docs/monitoring/how-we-store-data.md

@@ -12,12 +12,9 @@ cli: true
 By default, all our runners have their timezone set to UTC, regardless of their location.
 
 ## Resource limitations
-Each Browser and Multistep check can use up to `2.9 GiB` of memory and `2 CPU` cores. 
-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. 
+Each Browser and Multistep check can use up to `2.9 GiB` of memory and `2 vCPU` cores. 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.
 
-> When the memory limit is exceeded, 
-the check will automatically fail with a relevant error message, for example: `Your check has reached the maximum memory usage of 2.9 GiB`.
+> When the memory limit is exceeded, the check will automatically fail with a relevant error message, for example: `Your check has reached the maximum memory usage of 2.9 GiB`.
 
 ## Built-in Node.js modules
 
@@ -37,19 +34,16 @@ the check will automatically fail with a relevant error message, for example: `Y
 - util
 - zlib
 
-See the built-in module documentation on the official Node.js site:
+See the built-in module documentation on the official Node.js site (please see below which runtime includes what NodeJS version):
 
 - [18.x](https://nodejs.org/dist/latest-v18.x/docs/api/)
 - [16.x](https://nodejs.org/dist/latest-v16.x/docs/api/)
-- [14.x](https://nodejs.org/dist/latest-v14.x/docs/api/)
 
 ## NPM packages
 
 These are the currently available runtimes and the included external NPM dependencies.
 
-> The packages below are included for **setup and teardown scripts** as well, with the exclusion of Playwright and Mocha.
-
-> We are planning to deprecate `mocha` in the future. Please use `@playwright/test` as a test framework instead.
-
+> The packages below are included for **setup and teardown scripts** as well, with the exclusion of Playwright and `mocha`.
+> `mocha` is deprecated. Please use `@playwright/test` as a test framework instead.
 
 {{% runtimes %}}