add explicit Node.js version info to runtimes (#1085)

* add node version

* fix

Author: benben

site/content/docs/runtimes/_index.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/runtimes/specs.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 %}}

site/layouts/shortcodes/runtimes.html

@@ -11,8 +11,10 @@
     This runtime will be available until {{ .runtimeEndOfLife }}. Please update your checks' runtimes and account settings
     to avoid failures due to automatic change to the next supported runtime.
   {{ end }}
-  {{ .description }}
 
+  Node.js Version: `{{ .nodeJsVersion }}`
+
+  {{ .description }}
 
   {{ range $key, $value := .dependencies }}
   - [{{ $key }}](https://npmjs.com/package/{{ $key }}/v/{{ $value }}) {{ $value }}