diff --git a/.circleci/config.yml b/.circleci/config.yml
new file mode 100644
index 0000000000..32d19f8095
--- /dev/null
+++ b/.circleci/config.yml
@@ -0,0 +1,110 @@
+version: 2
+
+defaults: &defaults
+ docker:
+ - image: circleci/node:10.19.0
+ environment:
+ JOBS: 1
+ working_directory: ~/k6-docs
+
+jobs:
+ build:
+ <<: *defaults
+ steps:
+ - checkout
+ - restore_cache:
+ keys:
+ - v1-dependencies-{{ checksum "package.json" }}
+ # fallback to using the latest cache if no exact match is found
+ - v1-dependencies-
+ - run: npm install
+ - save_cache:
+ paths:
+ - node_modules
+ key: v1-dependencies-{{ checksum "package.json" }}
+ - persist_to_workspace:
+ root: .
+ paths:
+ - .
+
+ deploy-to-staging:
+ <<: *defaults
+ steps:
+ - attach_workspace:
+ at: .
+ - run:
+ name: Setup Environment Variables
+ command: |
+ echo "export GATSBY_GOOGLE_API_KEY=${GATSBY_GOOGLE_API_KEY_STAG}" > $BASH_ENV
+ echo "export GATSBY_DRIFT_API=${GATSBY_DRIFT_API_STAG}" >> $BASH_ENV
+ echo "export GATSBY_DEFAULT_MAIN_URL=https://${MAIN_URL_STAG}" >> $BASH_ENV
+ echo "export GATSBY_DEFAULT_DOC_URL=https://${MAIN_URL_STAG}/docs" >> $BASH_ENV
+ echo "export GATSBY_DEFAULT_BLOG_URL=https://${MAIN_URL_STAG}/blog" >> $BASH_ENV
+ echo "export GATSBY_DEFAULT_APP_URL=https://app.${MAIN_URL_STAG}" >> $BASH_ENV
+ echo "export BUCKET_NAME=${BUCKET_NAME_STAG}" >> $BASH_ENV
+ echo "export BUCKET_REGION=${BUCKET_REGION_STAG}" >> $BASH_ENV
+ echo "export AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID_STAG}" >> $BASH_ENV
+ echo "export AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY_STAG}" >> $BASH_ENV
+ echo "export AWS_CLOUDFRONT_DISTRIBUTION_ID=${AWS_CLOUDFRONT_DISTRIBUTION_ID_STAG}" >> $BASH_ENV
+ echo "export GATSBY_ALGOLIA_APP_ID=${GATSBY_ALGOLIA_APP_ID_STAG}" >> $BASH_ENV
+ echo "export GATSBY_ALGOLIA_INDEX_NAME=${GATSBY_ALGOLIA_INDEX_NAME_STAG}" >> $BASH_ENV
+ echo "export GATSBY_ALGOLIA_SEARCH_ONLY_KEY=${GATSBY_ALGOLIA_SEARCH_ONLY_KEY_STAG}" >> $BASH_ENV
+ echo "export ALGOLIA_ADMIN_KEY=${ALGOLIA_ADMIN_KEY_STAG}" >> $BASH_ENV
+ - run: sudo apt-get update && sudo apt-get -y install python-pip python-dev
+ - run: sudo pip install awscli
+ - run: npm run build:gatsby
+ - run: npm run deploy
+
+
+ deploy-to-production:
+ <<: *defaults
+ steps:
+ - attach_workspace:
+ at: .
+ - run:
+ name: Setup Environment Variables
+ command: |
+ echo "export GATSBY_GOOGLE_API_KEY=${GATSBY_GOOGLE_API_KEY_PROD}" > $BASH_ENV
+ echo "export GATSBY_DRIFT_API=${GATSBY_DRIFT_API_PROD}" >> $BASH_ENV
+ echo "export GATSBY_DEFAULT_MAIN_URL=https://k6.io" >> $BASH_ENV
+ echo "export GATSBY_DEFAULT_DOC_URL=https://k6.io/docs" >> $BASH_ENV
+ echo "export GATSBY_DEFAULT_BLOG_URL=https://k6.io/blog" >> $BASH_ENV
+ echo "export GATSBY_DEFAULT_APP_URL=https://app.k6.io" >> $BASH_ENV
+ echo "export BUCKET_NAME=${BUCKET_NAME_PROD}" >> $BASH_ENV
+ echo "export BUCKET_REGION=${BUCKET_REGION_PROD}" >> $BASH_ENV
+ echo "export AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID_PROD}" >> $BASH_ENV
+ echo "export AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY_PROD}" >> $BASH_ENV
+ echo "export AWS_CLOUDFRONT_DISTRIBUTION_ID=${AWS_CLOUDFRONT_DISTRIBUTION_ID_PROD}" >> $BASH_ENV
+ echo "export GATSBY_ALGOLIA_APP_ID=${GATSBY_ALGOLIA_APP_ID_PROD}" >> $BASH_ENV
+ echo "export GATSBY_ALGOLIA_INDEX_NAME=${GATSBY_ALGOLIA_INDEX_NAME_PROD}" >> $BASH_ENV
+ echo "export GATSBY_ALGOLIA_SEARCH_ONLY_KEY=${GATSBY_ALGOLIA_SEARCH_ONLY_KEY_PROD}" >> $BASH_ENV
+ echo "export ALGOLIA_ADMIN_KEY=${ALGOLIA_ADMIN_KEY_PROD}" >> $BASH_ENV
+ - run: sudo apt-get update && sudo apt-get -y install python-pip python-dev
+ - run: sudo pip install awscli
+ - run: npm run build:gatsby
+ - run: npm run deploy
+
+
+
+workflows:
+ version: 2
+ build-deploy:
+ jobs:
+ - build:
+ filters:
+ branches:
+ only:
+ - master
+ - develop
+ - deploy-to-staging:
+ requires:
+ - build
+ filters:
+ branches:
+ only: develop
+ - deploy-to-production:
+ requires:
+ - build
+ filters:
+ branches:
+ only: master
\ No newline at end of file
diff --git a/.env.example b/.env.example
new file mode 100644
index 0000000000..078cd4de90
--- /dev/null
+++ b/.env.example
@@ -0,0 +1,13 @@
+GATSBY_DEFAULT_BLOG_URL=https://k6.io/blog
+GATSBY_DEFAULT_DOC_URL=http://localhost:8000
+GATSBY_DEFAULT_MAIN_URL=https://k6.io
+
+GATSBY_ALGOLIA_APP_ID=
+GATSBY_ALGOLIA_SEARCH_ONLY_KEY=
+GATSBY_ALGOLIA_INDEX_NAME=
+ALGOLIA_ADMIN_KEY=
+GATSBY_DRIFT_API=
+
+# leave empty to disable
+# true to enable
+GATSBY_FEATURE_EDIT_ARTICLE_BTN=
\ No newline at end of file
diff --git a/.eslintignore b/.eslintignore
new file mode 100644
index 0000000000..1011d5498d
--- /dev/null
+++ b/.eslintignore
@@ -0,0 +1,3 @@
+.cache/
+public/
+node_modules/
diff --git a/.eslintrc b/.eslintrc
new file mode 100644
index 0000000000..bea3dfb489
--- /dev/null
+++ b/.eslintrc
@@ -0,0 +1,63 @@
+{
+ "parser": "babel-eslint",
+ "env": {
+ "browser": true,
+ "node": true
+ },
+ "rules": {
+ "prettier/prettier": ["error"],
+ "camelcase": 0,
+ "object-curly-newline": 0,
+ "operator-linebreak": 0,
+ "no-shadow": 0,
+ "max-len": [2, 120],
+ "react/prop-types": 0,
+ "react/jsx-curly-brace-presence": [
+ 2,
+ {
+ "props": "always",
+ "children": "never"
+ }
+ ],
+ "react/jsx-tag-spacing": [
+ 2,
+ {
+ "closingSlash": "never",
+ "beforeSelfClosing": "never",
+ "afterOpening": "never",
+ "beforeClosing": "never"
+ }
+ ],
+ "react/jsx-filename-extension": [
+ 2,
+ {
+ "extensions": [".js"]
+ }
+ ],
+ "react/no-array-index-key": 0,
+ "react/jsx-one-expression-per-line": 0,
+ "react/jsx-props-no-spreading": 0,
+ "react/jsx-wrap-multilines": 0,
+ "import/order": 0, // TODO: Come up with a solution for this
+ "import/no-unresolved": [
+ 2,
+ {
+ "ignore": [
+ "components",
+ "images",
+ "layouts",
+ "pages",
+ "templates",
+ "styles",
+ "svg",
+ "utils"
+ ]
+ }
+ ],
+ "import/prefer-default-export": 0,
+ "jsx-a11y/html-has-lang": 0, // We use react-helmet for that
+ "jsx-a11y/control-has-associated-label": 0
+ },
+ "extends": ["airbnb", "prettier"],
+ "plugins": ["prettier"]
+}
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000000..fa75705108
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,78 @@
+# Logs
+logs
+*.log
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+
+# Runtime data
+pids
+*.pid
+*.seed
+*.pid.lock
+
+# Directory for instrumented libs generated by jscoverage/JSCover
+lib-cov
+
+# Coverage directory used by tools like istanbul
+coverage
+
+# nyc test coverage
+.nyc_output
+
+# Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files)
+.grunt
+
+# Bower dependency directory (https://bower.io/)
+bower_components
+
+# node-waf configuration
+.lock-wscript
+
+# Compiled binary addons (http://nodejs.org/api/addons.html)
+build/Release
+
+# Dependency directories
+node_modules/
+jspm_packages/
+
+# Packages
+yarn.lock
+
+# Typescript v1 declaration files
+typings/
+
+# Optional npm cache directory
+.npm
+
+# Optional eslint cache
+.eslintcache
+
+# Optional REPL history
+.node_repl_history
+
+# Output of 'npm pack'
+*.tgz
+
+# dotenv environment variables file
+.env.development
+.env.production
+
+# gatsby files
+.cache/
+public
+
+# Mac files
+.DS_Store
+
+# Yarn
+yarn-error.log
+.pnp/
+.pnp.js
+# Yarn Integrity file
+.yarn-integrity
+
+.idea/
+
+.vscode/snipsnap.code-snippets
+output
\ No newline at end of file
diff --git a/.prettierignore b/.prettierignore
new file mode 100644
index 0000000000..29d9d485ea
--- /dev/null
+++ b/.prettierignore
@@ -0,0 +1,3 @@
+# disable formatting for code snippets
+src/data/home-examples/*
+src/data/native-automation-instruction/*
\ No newline at end of file
diff --git a/.prettierrc b/.prettierrc
new file mode 100644
index 0000000000..4ff2b8b359
--- /dev/null
+++ b/.prettierrc
@@ -0,0 +1,4 @@
+{
+ "singleQuote": true,
+ "trailingComma": "all"
+}
\ No newline at end of file
diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
new file mode 100644
index 0000000000..d0bed32106
--- /dev/null
+++ b/CODE_OF_CONDUCT.md
@@ -0,0 +1,74 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+ address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+ professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting Robin: robin@loadimpact.com. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000000..e6e3370451
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,22 @@
+Contributing to the k6 documentation
+====================================
+
+Thank you for your interest in contributing to k6!
+
+(ﾉ◕ヮ◕)ﾉ*:・ﾟ✧
+
+Before you begin, make sure to familiarize yourself with the [Code of Conduct](CODE_OF_CONDUCT.md). If you've previously contributed to other open source project, you may recognize it as the classic [Contributor Covenant](https://contributor-covenant.org/).
+
+If you want to chat with the team or the community, you can join the [k6 Slack](https://k6.io/slack/) or post a question on the [k6 community forum](https://community.k6.io/).
+
+## Writing
+
+The k6 documentation is a Gatsby application using React components and markdown files for the content of the different pages.
+
+There are two types of pages: Welcome Pages and Documentation articles.
+
+[Welcome Pages](src/templates/docs) are the pages shown on the header menu: `Guides`, `Javascript API`, `Cloud Docs`, `Integration`, and `Examples`. They are made as separate React Components for maximum customisation.
+
+Documentation articles are markdown files structured under the [`src/data/markdown/docs`](src/data/markdown/docs) folder.
+
+If you want to know more about how to edit these pages, read more about the [File format](CONTRIBUTING_FILE_FORMAT.md)
\ No newline at end of file
diff --git a/CONTRIBUTING_FILE_FORMAT.md b/CONTRIBUTING_FILE_FORMAT.md
new file mode 100644
index 0000000000..15eec2b42b
--- /dev/null
+++ b/CONTRIBUTING_FILE_FORMAT.md
@@ -0,0 +1,245 @@
+Contributing File Formats
+====================================
+
+The k6 documentation is a Gatsby application using React components and markdown files for the content of the different pages.
+
+There are two types of pages: Welcome Pages and Documentation articles.
+
+[Welcome Pages](src/templates/docs) are the pages shown on the header menu: `Guides`, `Javascript API`, `Cloud Docs`, `Integration`, and `Examples`. They are made as separate React Components for maximum customisation.
+
+Documentation articles are markdown files structured under the [`src/data/markdown/docs`](src/data/markdown/docs) folder.
+
+### Folder structure
+
+Root folders represent main categories at the top of the page.
+Use numbers in front of the folder name to set the order.
+
+Pattern: {number}{space}{page name}
+
+Example: 02 Hello world
+
+
+
+The same pattern used to define orders not only root folderы but also pages(md files) inside the category.
+
+
+
+## Headers
+
+Use typical ## markdown definition to format headers.
+
+ ## Making HTTP requests
+
+Make sure you are using '##' which stands for a h2 tag - h1 i*s reserved for the title of a page*, that gets parsed from the frontmatter. Also the navigation box that is being dynamically created on each page based on h2 tags.
+
+
+
+Use h2 *and only h2 as landmarks*. h3 tag is designed to be used in your blockquote heading, like that:
+
+
+
+And h4,h5,h6 have no specified styles, therefore will be rendered by default very similar to h1, so you probably do not want to use them, but if there are use cases, please, let us know.
+
+## Images
+Default image syntax for markdown files
+
+ 
+
+You have to store images in src/images folder and access them from md files by using relative path. This way allows image-sharp-plugin process your image: compressing, converting and lazy loading.
+
+If you really have to put there some remote picture, write it like that:
+
+ 
+
+But keep in mind the size of an image on the other side of a link to prevent page overweighting.
+
+
+## Blockquotes
+
+Here things are getting a bit hairy. It is still default md, so it is perfectly fine to write blockquotes like:
+
+ > ### Docker syntax
+ >
+ > When using the `k6` docker image, you can't just give the script name since
+ > the script file will not be available to the container as it runs. Instead
+ > you must tell k6 to read `stdin` by passing the file name as `-`. Then you
+ > pipe the actual file into the container with `<` or equivalent. This will
+ > cause the file to be redirected into the container and be read by k6.
+ >
+ > **Note**: If your script imports other files (JS modules), piping like this
+ > will not work since the extra files will not be visible inside the container.
+ > To use modules you need to first mount your host/local directory into the
+ > Docker container, see [Modules with Docker](https://docs.k6.io/v1.0/docs/modules#section-using-local-modules-with-docker)."
+
+And you'll get a fine quote block:
+
+
+
+And, in case of a 'warning' mod for a blockquote, you just add an ⚠️ emoji, like this:
+
+ > ### ⚠️ Docker syntax
+ >
+ > When using the `k6` docker image, you can't just give the script name since
+ > the script file will not be available to the container as it runs. Instead
+ > you must tell k6 to read `stdin` by passing the file name as `-`. Then you
+ > pipe the actual file into the container with `<` or equivalent. This will
+ > cause the file to be redirected into the container and be read by k6.
+ >
+ > **Note**: If your script imports other files (JS modules), piping like this
+ > will not work since the extra files will not be visible inside the container.
+ > To use modules you need to first mount your host/local directory into the
+ > Docker container, see [Modules with Docker](https://docs.k6.io/v1.0/docs/modules#section-using-local-modules-with-docker)."
+
+*Pay attention to those empty lines between md block and a wrapper, they are required to correctly parsing.*
+
+And our default blockquote will take a form of:
+
+
+
+At the moment there are only two mods available, default (no wrapper needed) and warning. If you need more, let us know.
+
+## Code blocks
+
+So, there are basically three types of code blocks, small ones, headerless ones and headerfull ones,
+
+that last two have one possible modification - line numbers.
+
+### Small
+
+No hardwork required, just wrap your small stuff like keywords in backticks:
+
+ `API_VARIABLE` should be stored under a pillow
+
+and you are good to go
+
+
+
+### Headerless
+
+We are going to write them a bit differently, half-native md, just like blockquotes:
+
+
+
+ ```javascript
+ for (var id = 1; id <= 100; id++) {
+ http.get(http.url`http://example.com/posts/${id}`)
+ }
+
+ // tags.name="http://example.com/posts/${}",
+ // tags.name="http://example.com/posts/${}"
+ ```
+
+
+
+And, as a result:
+
+
+
+If we want line numbers to be rendered, we shall adjust our data-props to:
+
+
+
+ ```javascript
+ for (var id = 1; id <= 100; id++) {
+ http.get(http.url`http://example.com/posts/${id}`)
+ }
+
+ // tags.name="http://example.com/posts/${}",
+ // tags.name="http://example.com/posts/${}"
+ ```
+
+
+
+Here you go:
+
+
+
+### Headerfull
+
+Pretty much the same routine as with headerless ones, but one difference in data-props, labels field, but I bet, you already got that:
+
+
+
+ ```javascript
+ for (var id = 1; id <= 100; id++) {
+ http.get(http.url`http://example.com/posts/${id}`)
+ }
+
+ // tags.name="http://example.com/posts/${}",
+ // tags.name="http://example.com/posts/${}"
+ ```
+
+
+
+
+
+### Multiple tabs
+
+To be able to switch between different code tabs, we have to repeat the headerfull routine, but extend labels and md code blocks:
+
+
+
+ ```javascript
+ for (var id = 1; id <= 100; id++) {
+ http.get(http.url`http://example.com/posts/${id}`)
+ }
+
+ // tags.name="http://example.com/posts/${}",
+ // tags.name="http://example.com/posts/${}"
+ ```
+
+ ```javascript
+ for (var id = 1; id <= 100; id++) {
+ http.get(http.url`http://example.com/posts/${id}`)
+ }
+
+ // tags.name="http://example.com/posts/${}",
+ // tags.name="http://example.com/posts/${}"
+ ```
+
+ ```javascript
+ for (var id = 1; id <= 100; id++) {
+ http.get(http.url`http://example.com/posts/${id}`)
+ }
+
+ // tags.name="http://example.com/posts/${}",
+ // tags.name="http://example.com/posts/${}"
+ ```
+
+
+
+
+ );
+};
diff --git a/src/components/pages/doc-welcome/cloud/index.js b/src/components/pages/doc-welcome/cloud/index.js
new file mode 100644
index 0000000000..ce920c1853
--- /dev/null
+++ b/src/components/pages/doc-welcome/cloud/index.js
@@ -0,0 +1 @@
+export * from './cloud.view.js';
\ No newline at end of file
diff --git a/src/components/pages/doc-welcome/features/doc-welcome-features.module.scss b/src/components/pages/doc-welcome/features/doc-welcome-features.module.scss
new file mode 100644
index 0000000000..7ee4c20242
--- /dev/null
+++ b/src/components/pages/doc-welcome/features/doc-welcome-features.module.scss
@@ -0,0 +1,21 @@
+.container {
+ @include doc-section-spacing;
+}
+
+.title {
+ margin-bottom: 15px;
+}
+
+.description {
+ font-size: $font-size-lg;
+ line-height: $line-height-lg;
+ margin: 0 0 20px;
+}
+
+.trait {
+ margin-left: 20px;
+}
+
+.trait + .trait {
+ margin-top: 8px;
+}
diff --git a/src/components/pages/doc-welcome/features/doc-welcome-features.view.js b/src/components/pages/doc-welcome/features/doc-welcome-features.view.js
new file mode 100644
index 0000000000..b0174f152b
--- /dev/null
+++ b/src/components/pages/doc-welcome/features/doc-welcome-features.view.js
@@ -0,0 +1,44 @@
+import * as React from 'react';
+
+import { Heading } from 'components/shared/heading';
+import { Trait } from 'components/shared/trait';
+import { Link } from 'gatsby';
+
+import styles from './doc-welcome-features.module.scss';
+
+export const Features = () => (
+
+
+ Key features
+
+
+ k6 is packed with features, which you can learn all about in the documentation.
+ Key features include:
+
+
+
+
+
+ CLI tool with developer-friendly APIs.
+
+
+
+ Scripting in JavaScript ES2015/ES6 - with support for{' '}
+
+ local and remote modules
+
+
+
+
+ Checks
+ {' '}
+ and{' '}
+
+ Thresholds
+ {' '}
+ - for goal-oriented, automation-friendly load testing
+
+
+
+
+);
diff --git a/src/components/pages/doc-welcome/features/index.js b/src/components/pages/doc-welcome/features/index.js
new file mode 100644
index 0000000000..f46b484736
--- /dev/null
+++ b/src/components/pages/doc-welcome/features/index.js
@@ -0,0 +1 @@
+export { Features } from './doc-welcome-features.view';
diff --git a/src/components/pages/doc-welcome/help/doc-welcome-help-image.png b/src/components/pages/doc-welcome/help/doc-welcome-help-image.png
new file mode 100644
index 0000000000..99ae4e31d9
Binary files /dev/null and b/src/components/pages/doc-welcome/help/doc-welcome-help-image.png differ
diff --git a/src/components/pages/doc-welcome/help/doc-welcome-help.module.scss b/src/components/pages/doc-welcome/help/doc-welcome-help.module.scss
new file mode 100644
index 0000000000..38f022b9cc
--- /dev/null
+++ b/src/components/pages/doc-welcome/help/doc-welcome-help.module.scss
@@ -0,0 +1,16 @@
+.container {
+ li + li {
+ margin-top: 5px;
+ }
+}
+
+.title {
+ margin-bottom: 15px;
+}
+
+.description {
+ font-size: $font-size-lg;
+ line-height: $line-height-lg;
+ color: $color-secondary;
+ margin: 0 0 20px;
+}
diff --git a/src/components/pages/doc-welcome/help/doc-welcome-help.view.js b/src/components/pages/doc-welcome/help/doc-welcome-help.view.js
new file mode 100644
index 0000000000..ad2c59faca
--- /dev/null
+++ b/src/components/pages/doc-welcome/help/doc-welcome-help.view.js
@@ -0,0 +1,54 @@
+import * as React from 'react';
+
+import { Heading } from 'components/shared/heading';
+import styles from './doc-welcome-help.module.scss';
+
+export const Help = () => (
+
+
+
+
+ Need help or want to contribute to k6?
+
+
+ Types of questions and where to ask:
+
+
+
+
+ How do I? - Stack Overflow (use
+ tags: k6, javascript, load-testing)
+
+
+ How do I? Get k6 community support -{' '}
+ Community Forum
+
+
+ I got this error, why? -{' '}
+ Stack Overflow
+
+
+ I got this error and I'm sure it's a bug -{' '}
+ file an issue
+
+
+ I have an idea/request -{' '}
+ file an issue
+
+
+ Why do you? - Slack
+
+
+ When will you? - Slack
+
+
+ I want to contribute/help with development -{' '}
+ Start here, then{' '}
+ Slack and{' '}
+ issues
+
+
+
+
+
+);
diff --git a/src/components/pages/doc-welcome/help/index.js b/src/components/pages/doc-welcome/help/index.js
new file mode 100644
index 0000000000..5bf7bcf76b
--- /dev/null
+++ b/src/components/pages/doc-welcome/help/index.js
@@ -0,0 +1 @@
+export { Help } from './doc-welcome-help.view';
diff --git a/src/components/pages/doc-welcome/index.js b/src/components/pages/doc-welcome/index.js
new file mode 100644
index 0000000000..0220d91c36
--- /dev/null
+++ b/src/components/pages/doc-welcome/index.js
@@ -0,0 +1,9 @@
+export * from './cloud';
+export * from './features';
+export * from './help';
+export * from './page-info';
+export * from './quickstart';
+export * from './showcase';
+export * from './what-is';
+export * from './whats-new';
+export * from './manifesto';
diff --git a/src/components/pages/doc-welcome/k6-does-not/index.js b/src/components/pages/doc-welcome/k6-does-not/index.js
new file mode 100644
index 0000000000..1d5e4293f0
--- /dev/null
+++ b/src/components/pages/doc-welcome/k6-does-not/index.js
@@ -0,0 +1 @@
+export { K6DoesNot } from './k6-does-not.component';
diff --git a/src/components/pages/doc-welcome/k6-does-not/k6-does-not.component.js b/src/components/pages/doc-welcome/k6-does-not/k6-does-not.component.js
new file mode 100644
index 0000000000..1e3afb24e2
--- /dev/null
+++ b/src/components/pages/doc-welcome/k6-does-not/k6-does-not.component.js
@@ -0,0 +1,57 @@
+import React from 'react';
+import { Link } from 'gatsby';
+import { Heading } from 'components/shared/heading';
+import styles from './k6-does-not.module.scss';
+
+export const K6DoesNot = ({ style }) => (
+
+
+ What k6 does not
+
+
+ k6 is a high-performing load testing tool, scriptable in JavaScript. The
+ architectural design to have these capabilities brings some trade-offs:
+
+
+
+
+ Does not run in a browser
+
+
+ As a result, k6 does not render webpages the same way a browser does.
+ This also means that libraries relying on browser APIs won't be
+ compatible. By skipping the browser, the consumption of system
+ resources are dramatically decreased, making the tool significantly
+ more performant.
+
+
+ k6 can still be used for website load testing. It even has a{' '}
+
+ Session Recorder
+
+ , enabling you to generate tests from a website session.
+
+
+
+
+ Does not run in NodeJS
+
+
+
+ JavaScript is not generally well suited for high performance. To
+ achieve maximum performance, the tool itself is written in Go,
+ embedding a JavaScript runtime allowing for easy test scripting.
+
+
+ If you want to import npm modules or libraries using NodeJS APIs, you
+ can bundle npm modules with browserify or webpack and import them in
+ your tests. Read more about{' '}
+
+ npm Modules
+
+ .
+
+
+
+
+);
diff --git a/src/components/pages/doc-welcome/k6-does-not/k6-does-not.module.scss b/src/components/pages/doc-welcome/k6-does-not/k6-does-not.module.scss
new file mode 100644
index 0000000000..3d15598e0e
--- /dev/null
+++ b/src/components/pages/doc-welcome/k6-does-not/k6-does-not.module.scss
@@ -0,0 +1,7 @@
+.container {
+ margin-bottom: 60px;
+}
+
+.title {
+ margin-bottom: 15px;
+}
diff --git a/src/components/pages/doc-welcome/manifesto/index.js b/src/components/pages/doc-welcome/manifesto/index.js
new file mode 100644
index 0000000000..fbeffd1b35
--- /dev/null
+++ b/src/components/pages/doc-welcome/manifesto/index.js
@@ -0,0 +1 @@
+export { Manifesto } from './manifesto.component';
diff --git a/src/components/pages/doc-welcome/manifesto/manifesto.component.js b/src/components/pages/doc-welcome/manifesto/manifesto.component.js
new file mode 100644
index 0000000000..14d4a1b3c0
--- /dev/null
+++ b/src/components/pages/doc-welcome/manifesto/manifesto.component.js
@@ -0,0 +1,50 @@
+import React from 'react';
+import { Heading } from 'components/shared/heading';
+import styles from './manifesto.module.scss';
+import { main } from 'utils/urls';
+
+const bullets = [
+ {
+ title: 'Simple testing is better than no testing',
+ url: `${main}/our-beliefs/#simple-testing-is-better-than-no-testing`,
+ },
+ {
+ title: 'Load testing should be goal oriented',
+ url: `${main}/our-beliefs/#load-testing-should-be-goal-oriented`,
+ },
+ {
+ title: 'Load testing by developers',
+ url: `${main}/our-beliefs/#load-testing-by-developers`,
+ },
+ {
+ title: 'Developer experience is super important',
+ url: `${main}/our-beliefs/#developer-experience-is-super-important`,
+ },
+ {
+ title: 'Load test in a pre-production environment',
+ url: `${main}/our-beliefs/#load-test-in-a-pre-production-environment`,
+ },
+];
+
+export const Manifesto = () => {
+ return (
+
+
+ Load Testing Manifesto
+
+ Our load testing manifesto is the result of having spent years hip deep in
+ the trenches, doing performance- and load testing. We’ve created it to be
+ used as guidance, helping you in getting your performance testing on the
+ right track!
+
+ k6 users are typically Developers, QA Engineers, and DevOps. They use k6
+ for testing the performance of APIs, microservices, and websites. Common
+ k6 use cases are:
+
+
+
+
+ Load Testing
+
+
+ k6 is optimized for minimal consumption of system resources. It’s a
+ high-performance tool designed for running tests with high load. You
+ can use it for running tests with a high load (spike, stress,
+ endurance tests) in pre-production and QA environments.
+
+
+
+
+ Performance monitoring
+
+
+ k6 provides great primitives for code modularization, performance
+ thresholds, and automation. These features make it an excellent
+ choice for performance monitoring. You could run tests with a small
+ amount of load to continuously monitor the performance of your
+ production environment.
+
+ k6 is a developer-centric, free and open-source load testing tool built
+ for making performance testing a productive and enjoyable experience.
+
+
+ Using k6, you'll be able to catch performance regression and problems
+ earlier, allowing you to build resilient systems and robust
+ applications.
+
+ );
+};
diff --git a/src/components/shared/code/index.js b/src/components/shared/code/index.js
new file mode 100644
index 0000000000..6d9faa42c0
--- /dev/null
+++ b/src/components/shared/code/index.js
@@ -0,0 +1,3 @@
+export { Code } from './code.view';
+export { highlightCodeInRef } from './code.utils';
+export { default as styles } from './code.module.scss';
diff --git a/src/components/shared/cookie-consent/cookie-consent.js b/src/components/shared/cookie-consent/cookie-consent.js
new file mode 100644
index 0000000000..2778454127
--- /dev/null
+++ b/src/components/shared/cookie-consent/cookie-consent.js
@@ -0,0 +1,29 @@
+import React from 'react';
+import styles from './cookie-consent.module.scss';
+import { Button } from '../button';
+
+import { main } from 'utils/urls';
+
+const CookieConsent = ({ onAccept }) => (
+
+
+
+ This site uses cookies. Using k6.io means you agree to use of our
+ cookies. Please, feel free read our{' '}
+
+ Privacy Policy
+ {' '}
+ for further information.
+
+
+
+);
diff --git a/src/components/templates/doc-page/doc-page-content/index.js b/src/components/templates/doc-page/doc-page-content/index.js
new file mode 100644
index 0000000000..320f41aa75
--- /dev/null
+++ b/src/components/templates/doc-page/doc-page-content/index.js
@@ -0,0 +1 @@
+export { DocPageContent } from './doc-page-content.view';
diff --git a/src/components/templates/doc-page/doc-page-content/svg/anchor.inline.svg b/src/components/templates/doc-page/doc-page-content/svg/anchor.inline.svg
new file mode 100644
index 0000000000..bab85765d2
--- /dev/null
+++ b/src/components/templates/doc-page/doc-page-content/svg/anchor.inline.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/src/components/templates/doc-page/doc-page.module.scss b/src/components/templates/doc-page/doc-page.module.scss
new file mode 100644
index 0000000000..dc5a206a0d
--- /dev/null
+++ b/src/components/templates/doc-page/doc-page.module.scss
@@ -0,0 +1,37 @@
+.container {
+ margin-top: 115px;
+ @include lg-down {
+ margin-top: 185px;
+ }
+ @include md-down {
+ margin-top: 225px;
+ }
+ @include sm-down {
+ margin-top: 250px;
+ width: 540px;
+ margin-left: auto;
+ margin-right: auto;
+ }
+ @include xs-down {
+ width: 100%;
+ padding: 0 20px;
+ }
+}
+
+.main-doc-content {
+ padding-right: 37.5px; // keeping spacing of 50px
+ @include md-down {
+ padding-right: 12.5px; // reverting back after hiding table of contents
+ }
+}
+
+.section-list {
+ list-style: none;
+ padding: 0;
+ margin-top: 50px;
+ li {
+ &:not(:last-child) {
+ margin-bottom: 15px;
+ }
+ }
+}
diff --git a/src/data/doc-examples/links.json b/src/data/doc-examples/links.json
new file mode 100644
index 0000000000..8c99ef4450
--- /dev/null
+++ b/src/data/doc-examples/links.json
@@ -0,0 +1,144 @@
+{
+ "examples": [
+ {
+ "title": "Single Request",
+ "description": "Example of one HTTP GET request.",
+ "url": "",
+ "to": "/examples/single-request"
+ },
+ {
+ "title": "HTTP Authentication and authorization",
+ "description": "Scripting examples on how to use different authentication or authorization methods in your load test.",
+ "url": "",
+ "to": "/examples/http-authentication"
+ },
+ {
+ "title": "Correlating Tokens and Dynamic Data",
+ "description": "Scripting examples to correlate dynamic data in your test script.",
+ "url": "",
+ "to": "/examples/correlation-and-dynamic-data"
+ },
+ {
+ "title": "Data Parameterization",
+ "description": "Scripting examples on how to parameterize data in a test script.",
+ "url": "",
+ "to": "/examples/data-parameterization"
+ },
+ {
+ "title": "Filling and Submitting HTML Forms",
+ "description": "Scripting example on how to handle HTML forms in a load test.",
+ "url": "",
+ "to": "/examples/html-forms"
+ },
+ {
+ "title": "Cookies",
+ "description": "Scripting examples on how you can interact with cookies during your load test, if required.",
+ "url": "",
+ "to": "/examples/cookies-example"
+ },
+ {
+ "title": "Data Uploads",
+ "description": "Scripting examples on how to execute a load test that will upload a file to the System Under Test(SUT).",
+ "url": "",
+ "to": "/examples/data-uploads"
+ },
+ {
+ "title": "Advanced API example",
+ "description": "This example covers the usage of different k6 APIs for API load testing.",
+ "url": "",
+ "to": "/examples/advanced-api-flow"
+ },
+ {
+ "title": "Generating UUIDs",
+ "description": "Scripting example on how to generate UUIDs in your load test.",
+ "url": "",
+ "to": "/examples/generating-uuids"
+ },
+ {
+ "title": "HTTP2",
+ "description": "Information on how to load test HTTP/2.",
+ "url": "",
+ "to": "/examples/http2"
+ },
+ {
+ "title": "Websockets",
+ "description": "Scripting example on how to test websocket APIs.",
+ "url": "",
+ "to": "/examples/websockets"
+ },
+ {
+ "title": "SOAP",
+ "description": "Load Testing SOAP API.",
+ "url": "",
+ "to": "/examples/soap"
+ },
+ {
+ "title": "Transport Layer Security (TLS)",
+ "description": "TLS is the mechanism through which encrypted connections can be established between clients and servers on the web and through which data can flow with integrity intact.",
+ "url": "",
+ "to": "/examples/transport-layer-security-tls"
+ },
+ {
+ "title": "Generating realistic data using faker.js",
+ "description": "Reference project demonstrating how to generate data with realistic traits at runtime using faker.js.",
+ "url": "https://github.com/k6io/example-data-generation",
+ "to": ""
+ },
+ {
+ "title": "Crawl a web page",
+ "description": "Stack overflow answer demonstrating how to crawl a web page.",
+ "url": "https://stackoverflow.com/questions/60927653/downloading-whole-websites-with-k6/",
+ "to": ""
+ },
+ {
+ "title": "Bundling and transpilation",
+ "description": "Reference project demonstrating how to use webpack and babel to bundle node modules or transpile code to ES5.1+ for usage in k6 tests.",
+ "url": "https://github.com/k6io/k6-es6",
+ "to": ""
+ }
+ ],
+ "tutorials": [
+ {
+ "title": "How to use Datadog alerts and Thresholds to fail your load test",
+ "description": "This article will show how to use Datadog alerts and Thresholds to fail your load test.",
+ "to": "",
+ "url": "https://k6.io/blog/datadog-alerts-fail-load-test"
+ },
+ {
+ "title": "Load Testing Your API with Postman",
+ "description": "How to use postman collections in k6?",
+ "to": "",
+ "url": "https://k6.io/blog/load-testing-with-postman-collections"
+ },
+ {
+ "title": "Performance monitoring with cron and k6",
+ "description": "This tutorial will show you how to schedule k6 tests with cron to monitor the performance of your system.",
+ "to": "",
+ "url": "https://k6.io/blog/performance-monitoring-with-cron-and-k6"
+ },
+ {
+ "title": "Integrating k6 with Apache Kafka",
+ "description": "How to send k6 output to Apache Kafka?",
+ "to": "",
+ "url": "https://k6.io/blog/integrating-k6-with-apache-kafka"
+ },
+ {
+ "title": "Load testing GraphQL with k6",
+ "description": "The popularity and adoption of GraphQL have been impressive in the last years, this post provides an example using k6 to load testing a GraphQL service.",
+ "to": "",
+ "url": "https://k6.io/blog/load-testing-graphql-with-k6"
+ },
+ {
+ "title": "Load Testing RESTful APIs with k6",
+ "description": "Let's take a look at how we can use the k6 open source load testing tool to performance test REST API endpoints.",
+ "to": "",
+ "url": "https://k6.io/blog/load-testing-restful-apis-with-k6"
+ },
+ {
+ "title": "How to control a live k6 test, with these built-in commands",
+ "description": "This article takes a look at the k6 pause/resume/scale/stats/status commands, and how to use them to control and query a remote k6 instance running a test.",
+ "to": "",
+ "url": "https://k6.io/blog/how-to-control-a-live-k6-test"
+ }
+ ]
+}
diff --git a/src/data/markdown/docs/01 guides/01 Getting started/01 Welcome.md b/src/data/markdown/docs/01 guides/01 Getting started/01 Welcome.md
new file mode 100644
index 0000000000..fe8446c061
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/01 Getting started/01 Welcome.md
@@ -0,0 +1,6 @@
+---
+title: "Welcome"
+excerpt: ""
+---
+
+The `Getting Started/Welcome` option of the sidebar menu must redirect to the root path (`GUIDES`).
diff --git a/src/data/markdown/docs/01 guides/01 Getting started/02 Installation.md b/src/data/markdown/docs/01 guides/01 Getting started/02 Installation.md
new file mode 100644
index 0000000000..0bac3dc7bc
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/01 Getting started/02 Installation.md
@@ -0,0 +1,51 @@
+---
+title: 'Installation'
+---
+
+## Linux (deb and rpm packages)
+
+
+
+## Windows (MSI installer)
+
+Download the k6 installer: [https://dl.bintray.com/loadimpact/windows/k6-latest-amd64.msi](https://dl.bintray.com/loadimpact/windows/k6-latest-amd64.msi)
+
+## Binaries
+
+Grab a prebuilt binary from our Releases page.
+Install the binary in your `PATH` to run **k6** from any location.
+
+## Docker
+
+
+
+```shell
+docker pull loadimpact/k6
+```
+
+
diff --git a/src/data/markdown/docs/01 guides/01 Getting started/03 Running k6.md b/src/data/markdown/docs/01 guides/01 Getting started/03 Running k6.md
new file mode 100644
index 0000000000..d90a43149b
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/01 Getting started/03 Running k6.md
@@ -0,0 +1,283 @@
+---
+title: 'Running k6'
+excerpt: ''
+---
+
+## Running k6 the first time
+
+This will run a very simple k6 sample script from github (click on the _Docker_ tab
+if you prefer using the k6 [Docker image](https://en.wikipedia.org/wiki/Docker_%28software%29)):
+
+
+
+```shell
+$ k6 run github.com/loadimpact/k6/samples/http_get.js
+```
+
+```shell
+$ docker run loadimpact/k6 run github.com/loadimpact/k6/samples/http_get.js
+```
+
+
+
+You should see `k6` download the sample script and run it with a single virtual user (VU).
+
+## Executing local scripts
+
+Next, let's try to run a local script. Copy the code below, paste it into your
+favourite editor, and save it as "script.js":
+
+
+
+```shell
+$ k6 run script.js
+```
+
+```shell
+$ docker run -i loadimpact/k6 run -
+
+### Docker syntax
+
+When using the `k6` docker image, you can't just give the script name since
+the script file will not be available to the container as it runs. Instead
+you must tell k6 to read `stdin` by passing the file name as `-`. Then you
+pipe the actual file into the container with `<` or equivalent. This will
+cause the file to be redirected into the container and be read by k6.
+
+> ### ⚠️ Note
+>
+> If your script imports other files (JS modules), piping like this
+> will not work since the extra files will not be visible inside the container.
+> To use modules you need to first mount your host/local directory into the
+> Docker container, see [Modules with Docker](/using-k6/modules#using-local-modules-with-docker).
+
+## Adding more VUs
+
+Now we'll try running a _real_ load test, with more than 1 virtual user and a slightly longer duration:
+
+
+
+```shell
+k6 run --vus 10 --duration 30s script.js
+```
+
+```shell
+docker run -i loadimpact/k6 run --vus 10 --duration 30s -
+
+_Running a 30-second, 10-VU load test_
+
+k6 works with the concept of virtual users (VUs), which run scripts - they're essentially
+glorified, parallel `while(true)` loops. Scripts are written using JavaScript, as ES6 modules,
+which allows you to break larger tests into smaller pieces, or make reusable pieces as you like.
+
+Scripts must contain, at the very least, a `default` function - this defines the entry point for
+your VUs, similar to the `main()` function in many other languages:
+
+
+
+```javascript
+export default function() {
+ // do things here...
+}
+```
+
+
+
+## The init context and the default function
+
+"Why not just run my script normally, from top to bottom", you might ask - the answer is: we do,
+but code inside and outside your default function can do different things.
+
+Code _inside_ `default` is called "VU code", and is run over and over for as long as the test is
+running. Code _outside_ of it is called "init code", and is run only once per VU.
+
+VU code can make HTTP requests, emit metrics, and generally do everything you'd expect a load test
+to do - with a few important exceptions: you can't load anything from your local filesystem, or
+import any other modules. This all has to be done from init-code.
+
+There are two reasons for this. The first is, of course: performance.
+
+If you read a file from disk on every single script iteration, it'd be needlessly slow; even if
+you cache the contents of the file and any imported modules, it'd mean the _first run_ of the
+script would be much slower than all the others. Worse yet, if you have a script that imports
+or loads things based on things that can only be known at runtime, you'd get slow iterations
+thrown in every time you load something new.
+
+But there's another, more interesting reason. By forcing all imports and file reads into the
+init context, we design for distributed execution. We know which files will be needed, so we
+distribute only those files. We know which modules will be imported, so we can bundle them up
+from the get-go. And, tying into the performance point above, the other nodes don't even need
+writable filesystems - everything can be kept in-memory.
+
+As an added bonus, you can use this to reuse data between iterations (but only for the same VU):
+
+
+
+## Using options
+
+If you want to avoid having to type `--vus 10` and `--duration 30s` all the time, you can include
+those settings inside your JavaScript file also:
+
+
+
+Then you just run the script without those parameters on the command line:
+
+
+
+```shell
+$ k6 run script.js
+```
+
+```shell
+$ docker run -i loadimpact/k6 run -
+
+## Stages: ramping up/down VUs
+
+You can also have the VU level ramp up and down during the test. The `options.stages` property
+allows you to configure ramping behaviour.
+
+
+
+## Using checks
+
+Maybe we want to verify that an HTTP transaction worked and that the transaction time stayed below some acceptable value. We can use the [check()](/javascript-api/k6/check-val-sets-tags) function for this:
+
+
+
+```javascript
+import http from 'k6/http';
+import { check, sleep } from 'k6';
+
+export let options = {
+ vus: 10,
+ duration: '30s',
+};
+
+export default function() {
+ let res = http.get('http://test.k6.io');
+ check(res, {
+ 'status was 200': r => r.status == 200,
+ 'transaction time OK': r => r.timings.duration < 200,
+ });
+ sleep(1);
+}
+```
+
+
+
+_Using check() to verify that transactions work and are fast enough_
+
+The above will generate a couple of extra output lines after the test, telling you if your check conditions succeeded or failed during the test. If the check conditions never failed, you will see this:
+
+
+
+```shell
+done [==========================================================] 30s / 30s
+
+✓ status was 200 OK
+✓ transaction time OK
+
+```
+
+
+
+And if a check condition fails, it will instead look like this:
+
+
+
+```shell
+done [==========================================================] 30s / 30s
+
+✗ status was 200
+↳ 0% — ✓ 0 / ✗ 150
+✓ transaction time OK
+```
+
+
+
+If you are using [k6 Cloud Insights](/cloud/analyzing-results/overview) you can also see how a given check has failed or passed during the test run:
+
+
diff --git a/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output.md b/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output.md
new file mode 100755
index 0000000000..93bbfd880e
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output.md
@@ -0,0 +1,216 @@
+---
+title: 'Results Output'
+excerpt: ''
+---
+
+## Overview
+
+By default, k6 will print runtime information and general results to `stdout` while the test is running, and a summary after the test has ended.
+
+## Runtime output to stdout
+
+
+
+By default, k6 sends its output to stdout only. When started up, it will display a very tasteful ASCII splash screen with the k6 logo and version information, plus details about the test and options active. We will go through the things one by one here:
+
+- `execution: local` k6 is not being used to control another k6 instance (distributed execution).
+- `output: -` Output is sent to stdout only.
+- `script: group.js (js)` Shows what script we are running. The `(js)` at the end indicates that k6 thinks this file contains JavaScript code (that should be executed by the VUs).
+- `duration: 0s, iterations: 1` The VUs in the test will only perform one single script iteration (calling the default function once) each, and there is no time limit set.
+- `vus: 1, max: 1` Simulate 1 VU (virtual user), allocate resources for a "max" of 1 VU (meaning we can't scale up the load level in this case).
+- `done [==============] 800ms / 800ms` This is the progress bar that updates while the test is running, to indicate how far the test has come and how much time has passed.
+- `█ my user scenario` is the name of a group we have created in our JS script.
+- `█ front page` is the name of a sub-group that was created inside the previously mentioned group ("my user scenario").
+- `✓ 100.00% - status code is 200` is the result from a check() that was executed inside the "front page" group. Note how this check result is indented, to indicate that it belongs to the "front page" group. The "front page" group name, in turn, is indented to indicate it belongs to its parent group ("my user scenario").
+- `█ features page` is another group that belongs to the parent group "my user scenario".
+- `✓ 100.00% - status code is 200` and `✓ 100.00% - h1 message is correct` are two more checks that belong to the "features page" group.
+- `checks................: 100.00%` tells us the percentage of our checks that passed.
+
+And then comes the HTTP timing information. There are several metrics being reported here, and percentiles etc. for each of them:
+
+- `http_req_blocked` The time VUs spent waiting to be allocated a TCP connection from the connection pool.
+- `http_req_connecting` The time VUs spent performing TCP handshakes (setting up TCP connections to the remote host).
+- `http_req_looking_up` The time spent performing DNS lookups.
+- `http_req_sending` The time spent transmitting HTTP requests to the remote host.
+- `http_req_waiting` The time spent waiting for a response to come back from the remote host (after having sent a request).
+- `http_req_receiving` The time spent receiving a reply from the remote host.
+- `http_req_duration` Total time for the request. It's equal to `http_req_sending + http_req_waiting + http_req_receiving` (i.e. how long did the remote server take to process the request and respond, without the initial DNS lookup/connection times).
+
+All of these are metrics of the Trend type, which means you can extract max, min, [percentile](https://en.wikipedia.org/wiki/Percentile), average values from them. On stdout they are printed like this:
+
+
+
+After the HTTP timing metrics, there will be a few final lines of output:
+
+- `http_reqs........: 2` The total number of HTTP requests made during the whole load test.
+- `iterations........: 1` The total number of times all VUs in the test managed to run through the default() function.
+- `vus.................: 1` How many VUs the test was configured to simulate.
+- `vus_max........: 1` The number of pre-allocated VU slots the test was configured for (vus_max allows you to scale up the number of VUs in the test to max that number).
+
+## Output result data
+
+k6 may also output more granular result data using special output plugins. Currently, there are a few plugins that can output data:
+
+- [JSON](/getting-started/results-output/json) plugin that writes data in JSON format to a file
+- Plugins that push the metrics to:
+ - [Apache Kafka](/getting-started/results-output/apache-kafka)
+ - [Datadog](/getting-started/results-output/datadog)
+ - [InfluxDB](/getting-started/results-output/influxdb)
+ - [StatsD](/getting-started/results-output/statsd)
+- [Cloud](/getting-started/results-output/cloud) plugin that streams your test results to the k6 Cloud platform
+
+To know more about the metrics k6 collects, please see the [Metrics management page](/using-k6/metrics)
+
+## Multiple outputs
+
+You can simultaneously send the emitted metrics to several outputs by using the CLI `--out` flag multiple times, for example:
+
+
+
+## Summary export
+
+> _New in v0.26.0_
+
+It's also possible to export the end-of-test summary report to a JSON
+file that includes data for all test metrics, checks and thresholds.
+This is useful to get the aggregated test results in a
+machine-readable format, for integration with dashboards, external
+alerts, etc.
+
+### Example
+
+Running `k6 run --summary-export=export.json github.com/loadimpact/k6/samples/stages.js`
+would generate the following file:
+
+
+
+You can also specify the message `format` k6 will use. By default, it will be the same as the JSON output, but you can also use the InfluxDB line protocol for direct "consumption" by InfluxDB:
+
+
+
diff --git a/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output/Cloud.md b/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output/Cloud.md
new file mode 100755
index 0000000000..4ef7ea704e
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output/Cloud.md
@@ -0,0 +1,30 @@
+---
+title: 'Cloud'
+excerpt: ''
+---
+
+You can also stream your test results in real time to the k6 Cloud.
+
+[k6 Cloud](/cloud) provides support to automatically interpret and visualize your results.
+
+
+
+> ### `K6CLOUD_TOKEN` is now `K6_CLOUD_TOKEN`
+>
+> Starting with v0.18.0 `K6CLOUD_TOKEN` has been renamed `K6_CLOUD_TOKEN`. The old spelling will still work in v0.18.0 but a deprecation message will be printed to the terminal.
+
+
+
+After running the command, the console shows the URL to access your test results.
+
+
+
+You can read more about [k6 Cloud](/cloud)
diff --git a/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output/DataDog.md b/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output/DataDog.md
new file mode 100755
index 0000000000..771798e3a7
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output/DataDog.md
@@ -0,0 +1,88 @@
+---
+title: "Datadog"
+excerpt: "The Datadog integration allows visualizing load test results and correlating performance testing metrics in Datadog."
+---
+
+k6 can send performance testing metrics to [Datadog](https://www.datadoghq.com/). That allows visualizing and correlating performance testing metrics with other monitored metrics in Datadog.
+
+This article outlines the instructions of the Datadog integration:
+
+- Run the Datadog Agent
+- Run the k6 test
+- Visualize in Datadog
+
+## Run the Datadog Agent
+
+To get k6 metrics into Datadog, k6 has to send metrics to the Datadog Agent that will collect, aggregate, and forward the metrics to the Datadog platform.
+
+You can run the Datadog Agent service as a Docker container with this command:
+
+
+
+
+Remember that you have to replace `` with your [Datadog API key](https://app.datadoghq.com/account/settings#api).
+
+Also note that if your account is registered with Datadog EU, the value of `DD_SITE` should be `datadoghq.eu`.
+
+
+
+### DogStatsD
+
+The Datadog agent includes the [DogStatsD](https://docs.datadoghq.com/developers/dogstatsd/) service to collect and aggregate metrics. DogStatsD implements the [StatsD](https://github.com/etsy/statsd) protocol with some extensions. For example, [DogStatsD tagging](https://docs.datadoghq.com/tagging/) allows to collect k6 metrics with tags to distinguish between requests for different URLs, response statuses, groups, etc.
+
+The instruction above runs the `DogStatsD` service using the [Docker container](https://docs.datadoghq.com/developers/dogstatsd/?tab=containeragent#agent), but there are other alternatives like the [Host Agent](https://docs.datadoghq.com/developers/dogstatsd/?tab=hostagent#agent), [Kubernetes](https://docs.datadoghq.com/developers/dogstatsd/?tab=kubernetes#agent), and [Helm](https://docs.datadoghq.com/developers/dogstatsd/?tab=helm#agent).
+
+## Run the k6 test
+
+Once the Datadog Agent service is running, you can run the k6 test and send the metrics to the agent with:
+
+
+
+```shell
+k6 run --out datadog script.js
+```
+
+
+
+
+The environment variables for the command are:
+
+| Name | Value |
+| ------------- | ------------- |
+| `K6_DATADOG_ADDR` | Address of the DogsStatsD service, currently only UDP is supported. The default value is `localhost:8125`. |
+| `K6_DATADOG_NAMESPACE` | The namespace used as a prefix for all the metric names. The default value is `k6.` |
+| `K6_DATADOG_PUSH_INTEVAL` | Configure how often data batches are sent. The default value is `1s`. |
+| `K6_DATADOG_BUFFER_SIZE` | The buffer size. The default value is `20`. |
+| `K6_DATADOG_TAG_BLACKLIST` | This is a comma-separated list of tags that should NOT be sent to Datadog. For example, "tag1, tag2". The default value is empty. |
+
+
+## Visualize in Datadog
+
+While running the test, k6 send metrics periodically to DataDog. By default, these metrics have **`k6.`** as name prefix. Like other metrics, you can visualize them in realtime at the [Datadog Metrics Explorer](https://docs.datadoghq.com/metrics/explorer/).
+
+
+
+
+
+To learn more about all the types of k6 metrics, read the k6 Metrics guide.
+
+
+Because Datadog handles k6 metrics as regular metrics, you could also use additional Datadog features like creating [monitors](https://docs.datadoghq.com/monitors/) or [custom dashboards](https://docs.datadoghq.com/graphing/dashboards/) for your performance testing metrics.
\ No newline at end of file
diff --git a/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output/InfluxDB.md b/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output/InfluxDB.md
new file mode 100755
index 0000000000..3633f7e1a8
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output/InfluxDB.md
@@ -0,0 +1,21 @@
+---
+title: "InfluxDB"
+excerpt: ""
+---
+
+Detailed statistics can also be sent directly to an [InfluxDB](https://github.com/influxdata/influxdb) instance:
+
+
+
+
+```shell
+k6 run --out influxdb=http://localhost:8086/k6 script.js
+````
+
+
+
+The above will make k6 connect to an InfluxDB instance listening to port 8086 on localhost, and insert all test results data into a database named "k6" (which will be created if it doesn't exist).
+
+Then you can use some other tool like [Grafana](https://grafana.com/) to visualize the data.
+
+Read more in this [Tutorial about using k6 with InfluxDB and Grafana](https://k6.io/blog/k6-loves-grafana/).
diff --git a/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output/JSON.md b/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output/JSON.md
new file mode 100755
index 0000000000..3d9726738a
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output/JSON.md
@@ -0,0 +1,97 @@
+---
+title: 'JSON'
+excerpt: ''
+---
+
+You can also make k6 output detailed statistics in JSON format by using the `--out/-o` option for `k6 run`, like this:
+
+
+
+```shell
+k6 run --out json=my_test_result.json script.js
+```
+
+
+
+The JSON file will contain lines like these:
+
+
+
+Each line will either contain information about a metric, or log a data point (sample) for a metric. Lines consist of three items:
+
+- `type` - can have the values [Metric](#metric) or [Point](#point) where `Metric` means the line is declaring a metric, and `Point` is an actual data point (sample) for a metric.
+- `data` - is a dictionary that contains lots of stuff, varying depending on the `"type"` above.
+- `metric` - the name of the metric.
+
+## Metric
+
+This line contains information about the nature of a metric. Here, `"data"` will contain the following:
+
+- `"type"` - the metric type ("gauge", "rate", "counter" or "trend")
+- `"contains"` - information on the type of data collected (can e.g. be "time" for timing metrics)
+- `"tainted"` - has this metric caused a threshold to fail?
+- `"threshold"` - are there any thresholds attached to this metric?
+- `"submetrics"` - any derived metrics created as a result of adding a threshold using tags.
+
+## Point
+
+This line contains actual data samples. Here, `"data"` will contain these fields:
+
+- `"time"` - timestamp when the sample was collected
+- `"value"` - the actual data sample; time values are in milliseconds
+- `"tags"` - dictionary with tagname-tagvalue pairs that can be used when filtering results data
+
+## Processing JSON output
+
+We recommend using [jq][jq_url] to process the k6 JSON output. [jq][jq_url] is a lightweight and flexible command-line JSON processor.
+
+You can quickly create [filters][jq_filters_url] to return a particular metric of the JSON file:
+
+
+
+```shell
+jq '. | select(.type=="Point" and .metric == "http_req_duration" and .data.tags.status >= "200")' myscript-output.json
+```
+
+
+
+And calculate an aggregated value of any metric:
+
+
+
+```shell
+jq '. | select(.type=="Point" and .metric == "http_req_duration" and .data.tags.status >= "200") | .data.value' myscript-output.json | jq -s min
+```
+
+
+
+
+
+```shell
+jq '. | select(.type=="Point" and .metric == "http_req_duration" and .data.tags.status >= "200") | .data.value' myscript-output.json | jq -s max
+```
+
+
+
+For more advanced cases, check out the [jq Manual][jq_manual_url]
+
+[jq_url]: https://stedolan.github.io/jq/ 'jq_url'
+[jq_filters_url]: https://stedolan.github.io/jq/manual/#Basicfilters 'jq_filters_url'
+[jq_manual_url]: https://stedolan.github.io/jq/manual/ 'jq_manual_url'
diff --git a/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output/StatsD.md b/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output/StatsD.md
new file mode 100755
index 0000000000..ff24e6cb8c
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output/StatsD.md
@@ -0,0 +1,23 @@
+---
+title: "StatsD"
+excerpt: ""
+---
+
+k6 can also push the metrics to a [StatsD](https://github.com/statsd/statsd) service like:
+
+
+
+```shell
+k6 run --out statsd script.js
+```
+
+
+
+The following options can be configured:
+
+| Name | Value |
+| ------------- | ------------- |
+| `K6_STATSD_ADDR` | Address of the statsd service, currently only UDP is supported. The default value is `localhost:8125`. |
+| `K6_STATSD_NAMESPACE` | The namespace used as a prefix for all the metric names. The default value is `k6`. |
+| `K6_STATSD_PUSH_INTERVAL` | Configure how often data batches are sent. The default value is `1s`. |
+| `K6_STATSD_BUFFER_SIZE` | The buffer size. The default value is `20`. |
diff --git a/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output/images/cloud-output.png b/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output/images/cloud-output.png
new file mode 100644
index 0000000000..a4643b25a9
Binary files /dev/null and b/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output/images/cloud-output.png differ
diff --git a/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output/images/datadog-performance-testing-metrics.png b/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output/images/datadog-performance-testing-metrics.png
new file mode 100644
index 0000000000..be1a6226a2
Binary files /dev/null and b/src/data/markdown/docs/01 guides/01 Getting started/04 Results Output/images/datadog-performance-testing-metrics.png differ
diff --git a/src/data/markdown/docs/01 guides/01 Getting started/05 Community.md b/src/data/markdown/docs/01 guides/01 Getting started/05 Community.md
new file mode 100644
index 0000000000..3da0568d36
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/01 Getting started/05 Community.md
@@ -0,0 +1,62 @@
+---
+title: Community
+excerpt: ''
+---
+
+On this page, you will find information about where you can ask your k6 questions,
+discuss about k6 and how you could contribute to the project.
+
+Before we start, please read our [Code of Conduct](https://github.com/loadimpact/k6/blob/master/CODE_OF_CONDUCT.md).
+k6 has adopted the [Contributor Covenant](https://www.contributor-covenant.org/), and we expect all
+community members to adhere to it.
+
+## Questions and discussions
+
+The [community forum](https://community.k6.io/) is the primary support channel of the
+k6 community. It’s the place to discuss features, recommendations and support type of
+questions.
+
+Use [Stack Overflow](https://stackoverflow.com/questions/tagged/k6) to ask code-level questions or if you
+encountered a particular error. Start out by searching using the `k6` tag, and if
+you find no prior answers, just create a new question using the `k6` and `load-testing` tags.
+
+## Feature Requests and Ideas
+
+The [community forum](https://community.k6.io/) is a great place for discussions. Open
+a conversation if you want to discuss a rough idea, features, architecture and best
+practices.
+
+If you already have a well-formulated idea of your feature request, we recommend filing
+a new issue, if there isn’t an open one already.
+
+## Reporting bugs
+
+If you find a bug in k6, [file an issue](https://github.com/loadimpact/k6/issues).
+Please search that it hasn’t previously reported.
+
+If you have found a bug on this documentation site, please let us know in the `#documentation`
+channel on [Slack](https://k6.io/slack/).
+
+## Contributing
+
+Interested in contributing to the k6 project? We're super-excited to have you! 🥳
+There are multiple ways in which you could contribute to the project, you'll find
+some ideas below:
+
+- Report bugs and features.
+- Contributing to the development through open issues on Github If the issue is complex,
+ it's usually a good idea to discuss your approach in the issue before you start writing
+ code. We have issues labeled as good first issue that have a limited scope.
+- Blog about k6. Contact us on [Slack](https://k6.io/slack/) if you would like your post to
+ be promoted. It's also nice if you mention `@k6` if you publish any links on twitter.
+- Give a talk about k6. Let us know on [Slack](https://k6.io/slack/) to see how we may help you.
+
+## Cheat Sheet
+
+| Type of question | Channel |
+| ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
+| How do I? | [Stack Overflow](https://stackoverflow.com), use the tags `k6`, `javascript`, and `load-testing`. The [Community Forum](https://community.k6.io) |
+| I got this error, why? | [Stack Overflow](https://stackoverflow.com) |
+| I got this error and I'm sure it's a bug | [File an issue](https://github.com/loadimpact/k6/issues) |
+| Why do you? When will you? | [Slack](https://k6.io/slack/) |
+| I want to contribute/help with development | Start here, then proceed to [Slack](https://k6.io/slack/) and [issues](https://github.com/loadimpact/k6/issues) |
diff --git a/src/data/markdown/docs/01 guides/01 Getting started/06 k6 Cloud.md b/src/data/markdown/docs/01 guides/01 Getting started/06 k6 Cloud.md
new file mode 100644
index 0000000000..2dcd59ea15
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/01 Getting started/06 k6 Cloud.md
@@ -0,0 +1,4 @@
+---
+title: 'k6 Cloud'
+redirect: 'https://k6.io/docs/cloud'
+---
diff --git a/src/data/markdown/docs/01 guides/01 Getting started/images/check-output.png b/src/data/markdown/docs/01 guides/01 Getting started/images/check-output.png
new file mode 100644
index 0000000000..7f82208b97
Binary files /dev/null and b/src/data/markdown/docs/01 guides/01 Getting started/images/check-output.png differ
diff --git a/src/data/markdown/docs/01 guides/01 Getting started/images/cloud-insights-checks.png b/src/data/markdown/docs/01 guides/01 Getting started/images/cloud-insights-checks.png
new file mode 100644
index 0000000000..235a0666b3
Binary files /dev/null and b/src/data/markdown/docs/01 guides/01 Getting started/images/cloud-insights-checks.png differ
diff --git a/src/data/markdown/docs/01 guides/01 Getting started/images/counter-output.png b/src/data/markdown/docs/01 guides/01 Getting started/images/counter-output.png
new file mode 100644
index 0000000000..3686c3efc4
Binary files /dev/null and b/src/data/markdown/docs/01 guides/01 Getting started/images/counter-output.png differ
diff --git a/src/data/markdown/docs/01 guides/01 Getting started/images/custom-metrics.png b/src/data/markdown/docs/01 guides/01 Getting started/images/custom-metrics.png
new file mode 100644
index 0000000000..0b6c119223
Binary files /dev/null and b/src/data/markdown/docs/01 guides/01 Getting started/images/custom-metrics.png differ
diff --git a/src/data/markdown/docs/01 guides/01 Getting started/images/gauge-output.png b/src/data/markdown/docs/01 guides/01 Getting started/images/gauge-output.png
new file mode 100644
index 0000000000..4a0df61c30
Binary files /dev/null and b/src/data/markdown/docs/01 guides/01 Getting started/images/gauge-output.png differ
diff --git a/src/data/markdown/docs/01 guides/01 Getting started/images/multiple-checks-output.png b/src/data/markdown/docs/01 guides/01 Getting started/images/multiple-checks-output.png
new file mode 100644
index 0000000000..9edb7704fc
Binary files /dev/null and b/src/data/markdown/docs/01 guides/01 Getting started/images/multiple-checks-output.png differ
diff --git a/src/data/markdown/docs/01 guides/01 Getting started/images/output-to-stdout.png b/src/data/markdown/docs/01 guides/01 Getting started/images/output-to-stdout.png
new file mode 100644
index 0000000000..1f949d205b
Binary files /dev/null and b/src/data/markdown/docs/01 guides/01 Getting started/images/output-to-stdout.png differ
diff --git a/src/data/markdown/docs/01 guides/01 Getting started/images/rate-output.png b/src/data/markdown/docs/01 guides/01 Getting started/images/rate-output.png
new file mode 100644
index 0000000000..d29023a4e9
Binary files /dev/null and b/src/data/markdown/docs/01 guides/01 Getting started/images/rate-output.png differ
diff --git a/src/data/markdown/docs/01 guides/01 Getting started/images/threshold-results.png b/src/data/markdown/docs/01 guides/01 Getting started/images/threshold-results.png
new file mode 100644
index 0000000000..838c83d51a
Binary files /dev/null and b/src/data/markdown/docs/01 guides/01 Getting started/images/threshold-results.png differ
diff --git a/src/data/markdown/docs/01 guides/01 Getting started/images/trend-output.png b/src/data/markdown/docs/01 guides/01 Getting started/images/trend-output.png
new file mode 100644
index 0000000000..996357e2d8
Binary files /dev/null and b/src/data/markdown/docs/01 guides/01 Getting started/images/trend-output.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/01 HTTP requests.md b/src/data/markdown/docs/01 guides/02 Using k6/01 HTTP requests.md
new file mode 100644
index 0000000000..6c1e358613
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/01 HTTP requests.md
@@ -0,0 +1,198 @@
+---
+title: 'HTTP Requests'
+excerpt: ''
+---
+
+## Making HTTP Requests
+
+When creating a new load test, the first thing you'll often do is define the HTTP requests that will be used to test
+your system. A simple example that just performs a GET request looks like this:
+
+
+
+## Available methods
+
+Use the [http module](/javascript-api/k6-http) to perform all kinds of HTTP requests in your load tests.
+
+| Name | Value |
+| ------------------------------------------------------------------ | ------------------------------------------------------------------------- |
+| [batch()](/javascript-api/k6-http/batch-requests) | Issue any type of HTTP request. |
+| [del()](/javascript-api/k6-http/del-url-body-params) | Issue an HTTP DELETE request. |
+| [get()](/javascript-api/k6-http/get-url-params) | Issue an HTTP GET request. |
+| [options()](/javascript-api/k6-http/options-url-body-params) | Issue an HTTP OPTIONS request. |
+| [patch()](/javascript-api/k6-http/patch-url-body-params) | Issue an HTTP PATCH request. |
+| [post()](/javascript-api/k6-http/post-url-body-params) | Issue an HTTP POST request. |
+| [put()](/javascript-api/k6-http/put-url-body-params) | Issue an HTTP PUT request. |
+| [request()](/javascript-api/k6-http/request-method-url-body-params) | Issue multiple HTTP requests in parallel (like e.g. browsers tend to do). |
+
+## HTTP Request Tags
+
+k6 will automatically apply [tags](/using-k6/tags-and-groups#section-tags) to your HTTP requests. These tags allow you to filter your results during analysis.
+
+| Name | Description |
+| ------ | ------------------------------------------ |
+| name | Defaults to URL requested |
+| method | Request method (`GET`, `POST`, `PUT` etc.) |
+| status | response status |
+| url | defaults to URL requested |
+
+Below you can see how a test result data point (the duration of an HTTP request) is logged, in JSON format, including the various tags mentioned above:
+
+
+
+## URL Grouping
+
+By default, requests report the name tag with the value of the request URL. For URLs that contain dynamic parts, this might not be desirable since it can
+introduce a large number of unique URLs in the metrics stream. The below code shows a situation when you'll access 100 different URLs but may want them
+all reported using one single metric:
+
+
+
+Note how the `name` is the same for the two data samples related to two different URLs. Filtering the results on tag `name: PostsItemURL` will give you a result set including all the data points from all the 100 different URLs.
+
+Additionally, you can use the `http.url` (v0.16.0) wrapper to set the name tag with a string template value:
+
+
+
+## Inside k6 Cloud Results
+
+[k6 Cloud Results's HTTP Table](/cloud/analyzing-results/http-tab) will show all the requests, on an aggregated level per URL.
+
+
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/02 Metrics.md b/src/data/markdown/docs/01 guides/02 Using k6/02 Metrics.md
new file mode 100644
index 0000000000..114fb4e14f
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/02 Metrics.md
@@ -0,0 +1,218 @@
+---
+title: 'Metrics'
+excerpt: ''
+---
+
+This section covers the important aspect of metrics management in k6. How and what kind of metrics k6 collects automatically (_built-in_ metrics), and what custom metrics you can make k6 collect.
+
+## Built-in metrics
+
+The _built-in_ metrics are the ones you can see output to stdout when you run the simplest possible k6 test, e.g. `k6 run github.com/loadimpact/k6/samples/http_get.js` which will output something like the below:
+
+
+
+All the `http_req_...` lines and the ones after them are _built-in_ metrics that get written to stdout at the end of a test.
+
+The following _built-in_ metrics will **always** be collected by k6:
+
+| Metric Name | Type | Description |
+| ------------- | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `vus` | Gauge | Current number of active virtual users |
+| `vus_max` | Gauge | Max possible number of virtual users (VU resources are preallocated, to ensure performance will not be affected when scaling up the load level) |
+| `iterations` | Counter | The aggregate number of times the VUs in the test have executed the JS script (the `default` function). |
+| `iteration_duration` | Trend | The time it took to complete one full iteration of the default/main function. |
+| `data_received` | Counter | The amount of received data. |
+| `data_sent` | Counter | The amount of data sent. |
+| `checks` | Rate | Number of failed checks |
+
+## HTTP-specific built-in metrics
+
+There are also _built-in_ metrics that will only be generated when/if HTTP requests are made:
+
+| Metric Name | Type | Description |
+| ------------------------ | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `http_reqs` | Counter | How many HTTP requests has k6 generated, in total. |
+| `http_req_blocked` | Trend | Time spent blocked (waiting for a free TCP connection slot) before initiating the request. `float` |
+| `http_req_connecting` | Trend | Time spent establishing TCP connection to the remote host. `float` |
+| `http_req_tls_handshaking` | Trend | Time spent handshaking TLS session with remote host |
+| `http_req_sending` | Trend | Time spent sending data to the remote host. `float` |
+| `http_req_waiting` | Trend | Time spent waiting for response from remote host (a.k.a. \"time to first byte\", or \"TTFB\"). `float` |
+| `http_req_receiving` | Trend | Time spent receiving response data from the remote host. `float` |
+| `http_req_duration` | Trend | Total time for the request. It's equal to `http_req_sending + http_req_waiting + http_req_receiving` (i.e. how long did the remote server take to process the request and respond, without the initial DNS lookup/connection times). `float` |
+
+### Accessing HTTP timings from a script
+
+If you want to access the timing information from an individual HTTP request, the _built-in_ HTTP timing metrics are also available in the [HTTP Response](/javascript-api/k6-http/response-k6-http) object:
+
+
+
+```js
+import http from 'k6/http';
+export default function() {
+ var res = http.get('http://httpbin.org');
+ console.log('Response time was ' + String(res.timings.duration) + ' ms');
+}
+```
+
+
+
+In the above snippet, `res` is an [HTTP Response](/javascript-api/k6-http/response-k6-http) object containing:
+
+| Property | Description |
+| ----------------------------- | --------------------------------------------------------------------- |
+| `res.body` | `string` containing the HTTP response body |
+| `res.headers` | `object` containing header-name/header-value pairs |
+| `res.status` | `integer` contaning HTTP response code received from server |
+| `res.timings` | `object` containing HTTP timing information for the request in **ms** |
+| `res.timings.blocked` | = `http_req_blocked` |
+| `res.timings.connecting` | = `http_req_connecting` |
+| `res.timings.tls_handshaking` | = `http_req_tls_handshaking` |
+| `res.timings.sending` | = `http_req_sending` |
+| `res.timings.waiting` | = `http_req_waiting` |
+| `res.timings.receiving` | = `http_req_receiving` |
+| `res.timings.duration` | = `http_req_duration` |
+
+## Custom metrics
+
+You can also create your own metrics, that are reported at the end of a load test, just like HTTP timings:
+
+
+
+```js
+import http from 'k6/http';
+import { Trend } from 'k6/metrics';
+
+let myTrend = new Trend('waiting_time');
+
+export default function() {
+ let r = http.get('https://httpbin.org');
+ myTrend.add(r.timings.waiting);
+}
+```
+
+
+
+The above code will create a Trend metric named “waiting_time” and referred to in the code using the variable name myTrend.
+Custom metrics will be reported at the end of a test. Here is how the output might look:
+
+
+
+## Metric types
+
+All metrics (both the _built-in_ ones and the custom ones) have a type. There are four different metrics types:
+
+- [Counter](/javascript-api/k6-metrics/counter-k6-metrics)
+- [Gauge](/javascript-api/k6-metrics/gauge-k6-metrics)
+- [Rate](/javascript-api/k6-metrics/rate-k6-metrics) and
+- [Trend](/javascript-api/k6-metrics/trend-k6-metrics)
+
+### Counter _(cumulative metric)_
+
+
+
+The above code will generate the following output:
+
+
+
+The value of `my_counter` will be 3 (if you run it one single iteration - i.e. without specifying --iterations or --duration).
+
+Note that there is currently no way of accessing the value of any custom metric from within JavaScript. Note also that counters that have value zero (`0`) at the end of a test are a special case - they will **NOT** be printed to the stdout summary.
+
+### Gauge _(keep the latest value only)_
+
+
+
+The above code will result in an output like this:
+
+
+The value of `my_gauge` will be 2 at the end of the test. As with the Counter metric above, a Gauge with value zero (`0`) will **NOT** be printed to the stdout summary at the end of the test.
+
+### Trend _(collect trend statistics (min/max/avg/percentiles) for a series of values)_
+
+
+
+The above code will make k6 print output like this:
+
+
+
+A trend metric is a container that holds a set of sample values, and which we can ask to output statistics (min, max, average, median or percentiles) about those samples.
+By default, k6 will print average, min, max, median, 90th percentile, and 95th percentile.
+
+### Rate _(keeps track of the percentage of values in a series that are non-zero)_
+
+
+
+The above code will make k6 print output like this:
+
+
+The value of `my_rate` at the end of the test will be 50%, indicating that half of the values
+added to the metric were non-zero.
+
+### Notes
+
+- custom metrics are only collected from VU threads at the end of a VU iteration, which means that
+ for long-running scripts, you may not see any custom metrics until a while into the test.
+
+## Metric graphs in k6 Cloud Results
+
+If you use [k6 Cloud's Cloud Insights](/cloud/analyzing-results/overview), you have access to all test
+metrics within the [Analysis Tab](/cloud/analyzing-results/analysis-tab). You can use this tab to further analyze and
+compare test result data, to look for meaningful correlations in your data.
+
+
+
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/03 Checks.md b/src/data/markdown/docs/01 guides/02 Using k6/03 Checks.md
new file mode 100644
index 0000000000..d5f9e539cb
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/03 Checks.md
@@ -0,0 +1,121 @@
+---
+title: "Checks"
+excerpt: ""
+---
+
+## What is a check?
+
+Checks are like asserts but differ in that they don't halt the execution, instead, they just
+store the result of the check, pass or fail, and let the script execution continue. Take a look at
+[thresholds](/using-k6/thresholds) for a way to halt the execution. Checks are great for
+codifying assertions relating to HTTP requests/responses, making sure the response code is 2xx
+for example:
+
+
+
+```js
+import { check } from "k6";
+import http from "k6/http";
+
+export default function() {
+ let res = http.get("http://test.k6.io/");
+ check(res, {
+ "is status 200": r => r.status === 200
+ });
+}
+```
+
+
+
+In the above example, one check was specified but you can add as many as you need in a call to
+[`check()`](/javascript-api/k6/check-val-sets-tags). When the above script is run you can see
+how k6 displays the results of the check calls in the following output:
+
+
+
+In the output above you can see that our check "is status 200" was successful 100% of the times it was called.
+
+You may also add multiple checks within a single check() statement, like this:
+
+
+
+```js
+import { check } from "k6";
+import http from "k6/http";
+
+export default function() {
+ let res = http.get("http://test.k6.io/");
+ check(res, {
+ "is status 200": r => r.status === 200,
+ "body size is 1176 bytes": r => r.body.length == 1176
+ });
+}
+```
+
+
+
+
+
+## Using checks in a CI setting
+
+One important thing to understand regarding checks is that a failed check *will not fail the whole
+load test*.
+
+Checks help to keep your code organized and easy to read, but when you're running a load test in
+a CI test suite you may want to check for error conditions that fail the whole load test. In this
+case you may want to combine checks with [thresholds](/using-k6/thresholds) to
+get what you want:
+
+
+
+```js
+import http from "k6/http";
+import { check } from "k6";
+import { Rate } from "k6/metrics";
+
+export let errorRate = new Rate("errors");
+export let options = {
+ thresholds: {
+ errors: ["rate<0.1"] // <10% errors
+ }
+};
+
+export default function() {
+ const res = http.get("http://httpbin.org");
+ const result = check(res, {
+ "status is 200": r => r.status == 200
+ });
+ errorRate.add(!result);
+}
+```
+
+
+
+The above script declares a custom [Rate](/javascript-api/k6-metrics/rate-k6-metrics)
+metric (called "errors") to hold information about the errors we have seen during the test, then
+it uses a threshold on that custom metric to fail the test when it encounters too many errors.
+If we replace the "http://httpbin.org" URL with one that will generate an error, k6 will exit with
+a nonzero exit value, indicating a FAIL result to e.g. a CI system that may have executed it:
+
+
+
+As you can see above, the exit code generated by k6 after this run was `99`. Any nonzero exit code
+is commonly interpreted by Un*x shells, CI servers, and monitoring systems as a "failure".
+
+Note also the expression `check() || errorRate.add(1)`. When any one of the check conditions
+inside a check() call fails, check() returns false, which causes the code after `||` to be
+executed. In this case, it means we add one data point to our Rate metric. Only if *all* check
+conditions pass will check() return true.
+
+See [check()](/javascript-api/k6/check-val-sets-tags) in the script API reference for
+more details on how check() works.
+
+## Checks in k6 Cloud Results
+
+In [k6 Cloud Results](/cloud/analyzing-results/overview) `Checks` are available in their [own tab](/cloud/analyzing-results/checks-tab) for analysis.
+
+
+Here we can quickly see what checks are failing, and upon clicking on any check, see the count of passes/failures
+at given points in the test. You can also add the check to the analysis tab, for further comparison with other metrics.
+
+
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/04 Thresholds.md b/src/data/markdown/docs/01 guides/02 Using k6/04 Thresholds.md
new file mode 100644
index 0000000000..b50113bfc2
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/04 Thresholds.md
@@ -0,0 +1,352 @@
+---
+title: 'Thresholds'
+excerpt: ''
+---
+
+## What are thresholds?
+
+Thresholds are a pass/fail criteria used to specify the performance expectations of the system under test.
+
+Example expectations (Thresholds):
+ - System doesn't produce more than 1% errors
+ - Response time for 95% of requests should be below 200ms.
+ - Response time for 99% of requests should be below 400ms.
+ - Specific endpoint must always respond within 300ms.
+
+Thresholds analyze the performance metrics and determine the final test result (pass/fail).
+Thresholds are a essential for [load-testing automation](/testing-guides/automated-performance-testing).
+
+Here is a sample script that specifies two thresholds, one using a custom [Rate metric](/javascript-api/k6-metrics/rate-k6-metrics), and one using a standard `http_req_duration` metric.
+
+
+
+```JavaScript
+import http from 'k6/http';
+import { Rate } from 'k6/metrics';
+
+const myFailRate = new Rate('failed requests');
+
+export let options = {
+ thresholds: {
+ 'failed requests': ['rate<0.1'], // threshold on a custom metric
+ 'http_req_duration': ['p(95)<500'] // threshold on a standard metric
+ }
+};
+
+export default function() {
+ let res = http.get('https://test-api.k6.io/public/crocodiles/1/');
+ myFailRate.add(res.status !== 200);
+}
+```
+
+
+
+The `failed requests` threshold specifies that we want our load test to be considered a failure
+(resulting in k6 exiting with a nonzero exit code) if 10% or more of requests resulted in the server
+returning anything else than a 200-response. The `http_req_duration` threshold specifies that
+95% of requests must complete within 500ms.
+
+In other words, you specify the `pass` criteria when defining your threshold, and if that
+expression evaluates to `false` at the end of the test, the whole test will be considered a `fail`.
+
+When executing that script, k6 will output something similar to this:
+
+
+- In the above case, criteria for both thresholds were met. The whole load test is considered
+ to be a `pass`, which means that k6 will exit with exit code zero.
+
+- If any of the thresholds had failed, the little green checkmark
+✓ next to the threshold name
+ (`failed requests`, `http_req_duration`) would have been a red cross ✗ instead, and k6 would have generated a non-zero exit code.
+
+
+## Copy-paste Threshold examples
+
+The quickest way to start with thresholds is to use the [standard, built-in k6 metrics](/using-k6/metrics#http-specific-built-in-metrics).
+
+Here are a few copy-paste examples that you can start using right away.
+
+
+
+```JavaScript
+import http from 'k6/http';
+import { sleep } from 'k6';
+
+export let options = {
+ thresholds: {
+ // 90% of requests must finish within 400ms.
+ 'http_req_duration': ['p(90) < 400'],
+ }
+};
+
+export default function() {
+ let res1 = http.get('https://test-api.k6.io/public/crocodiles/1/');
+ sleep(1);
+}
+```
+
+
+
+### Multiple thresholds on a single metric
+
+
+```JavaScript
+import http from 'k6/http';
+import { sleep } from 'k6';
+
+export let options = {
+ thresholds: {
+ // 90% of requests must finish within 400ms, 95% within 800, and 99.9% within 2s.
+ 'http_req_duration': ['p(90) < 400', 'p(95) < 800', 'p(99.9) < 2000'],
+ }
+};
+
+export default function() {
+ let res1 = http.get('https://test-api.k6.io/public/crocodiles/1/');
+ sleep(1);
+}
+```
+
+
+
+### Threshold on a group duration
+
+
+
+```JavaScript
+import http from "k6/http";
+import { check, group } from "k6";
+import { sleep } from 'k6';
+
+export let options = {
+ thresholds: {
+ // This group must finish in 400ms, at least 90% of the time.
+ 'group_duration{group:::publicCrocodiles}': ['p(90) < 400'],
+ }
+};
+
+export default function() {
+ group("publicCrocodiles", function() {
+ let inside1 = http.get('https://test-api.k6.io/public/crocodiles/1/');
+ let inside2 = http.get('https://test-api.k6.io/public/crocodiles/2/');
+ });
+
+ let outside = http.get('https://test-api.k6.io/public/crocodiles/3/');
+
+ sleep(1);
+}
+```
+
+
+
+You can find more specific threshold examples on the [Counter](/javascript-api/k6-metrics/counter-k6-metrics#counter-usage-in-thresholds), [Gauge](/javascript-api/k6-metrics/gauge-k6-metrics#gauge-usage-in-thresholds), [Trend](/javascript-api/k6-metrics/trend-k6-metrics#trend-usage-in-thresholds) and [Rate](/javascript-api/k6-metrics/rate-k6-metrics#rate-usage-in-thresholds) pages.
+
+
+## Threshold Syntax
+
+Thresholds can be specified in a short or full format.
+
+
+
+```js
+export let options = {
+ thresholds: {
+ metric_name1: [ 'eval1', ... ], // short format
+ metric_name1: [ { threshold: 'eval1', abortOnFail: boolean, delayAbortEval: string }, ], // full format
+ }
+};
+```
+
+
+
+The above declaration inside a k6 script means that there will be a threshold configured for
+the metric `metric_name1`. To determine if the threshold has failed or passed, the string `'eval1'`
+will be executed by the JavaScript runtime. This means that `'eval1'` should be a valid JavaScript
+expression.
+
+A threshold expression `'eval1'` is a snippet of JS code that is expected to evaluate to `true` or `false`.
+Every time a threshold is being evaluated, k6 injects one or more variables into the JS context.
+There are four metric types in k6, and each metric type provides its own set of variables that are injected and which can be used in threshold expressions.
+
+
+| Metric type | Threshold expression variables |
+| -------------- | ------- |
+| Counter | `count` and `rate` |
+| Gauge | `value` |
+| Rate | `rate` |
+| Trend | `avg`, `min`, `max`, `med` and `p(N)` where `N` is a number between 0.0 and 100.0 meaning the percentile value to look at, eg. `p(99.99)` means the 99.99th percentile. The unit of these variables and functions are all in milliseconds. |
+
+
+Here is a (slightly contrived) sample script that uses all different types of metrics, and sets
+different types of thresholds for them:
+
+
+
+```js
+import http from 'k6/http';
+import { Trend, Rate, Counter, Gauge } from 'k6/metrics';
+import { sleep } from 'k6';
+
+export let TrendRTT = new Trend('RTT');
+export let RateContentOK = new Rate('Content OK');
+export let GaugeContentSize = new Gauge('ContentSize');
+export let CounterErrors = new Counter('Errors');
+export let options = {
+ thresholds: {
+ 'RTT': ['p(99)<300', 'p(70)<250', 'avg<200', 'med<150', 'min<100'],
+ 'Content OK': ['rate>0.95'],
+ 'ContentSize': ['value<4000'],
+ 'Errors': ['count<100'],
+ }
+};
+
+export default function() {
+ let res = http.get('https://test-api.k6.io/public/crocodiles/1/');
+ let contentOK = res.json('name') === "Bert";
+
+ TrendRTT.add(res.timings.duration);
+ RateContentOK.add(contentOK);
+ GaugeContentSize.add(res.body.length);
+ CounterErrors.add(!contentOK);
+
+ sleep(1);
+}
+```
+
+
+
+We have these thresholds:
+
+- A trend metrics that is fed with response time samples, and which has the following threshold
+ criteria:
+ - 99th percentile response time must be below 300 ms
+ - 70th percentile response time must be below 250 ms
+ - Average response time must be below 200 ms
+ - Median response time must be below 150 ms
+ - Minimum response time must be below 100 ms
+- A rate metric that keeps track of how often the content returned was OK. This metric has one
+ success criteria: content must have been OK more than 95% of the time.
+- A gauge metric that contains the latest size of the returned content. The success criteria for
+ this metric is that the returned content must be smaller than 4000 bytes.
+- A counter metric that keeps track of the total number of times content returned was **not** OK.
+ The success criteria here implies that content can't have been bad more than 99 times.
+
+
+## Thresholds on sub-metrics (tagged metrics)
+
+It's often useful to specify thresholds only on a single URL or a specific tag.
+In k6, tagged requests create sub-metrics that can be used in thresholds as shown below.
+
+```javascript
+export let options = {
+ thresholds: {
+ "metric_name{tag_name:tag_value}": ["eval1"],
+ }
+}
+```
+
+And here's a full example.
+
+
+
+```javascript
+import http from 'k6/http';
+import { sleep } from 'k6';
+import { Rate } from 'k6/metrics';
+
+export let options = {
+ thresholds: {
+ "http_req_duration{type:API}": ["p(95)<500"], // threshold on API requests only
+ "http_req_duration{type:staticContent}": ["p(95)<200"], // threshold on static content only
+ }
+};
+
+export default function() {
+ let res1 = http.get('https://test-api.k6.io/public/crocodiles/1/', {tags: {'type': 'API'} } );
+ let res2 = http.get('https://test-api.k6.io/public/crocodiles/2/', {tags: {'type': 'API'} } );
+
+ let responses = http.batch([
+ ['GET', 'https://test-api.k6.io/static/favicon.ico', null, { tags: { type: 'staticContent' } }],
+ ['GET', 'https://test-api.k6.io/static/css/site.css', null, { tags: { type: 'staticContent' } }],
+ ]);
+
+ sleep(1);
+}
+
+```
+
+
+
+## Aborting a test when a threshold is crossed
+
+If you want to abort a test as soon as a threshold is crossed, before the test has completed,
+there's an extended threshold specification format that looks like this:
+
+
+
+As you can see in the example above the threshold specification has been extended to alternatively
+support a JS object with parameters to control the abort behavior. The fields are as follows:
+
+| Name | Type | Description |
+| -------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| threshold | string | This is the JS expression string specifying the threshold condition to evaluate. |
+| abortOnFail | boolean | Whether to abort the test if the threshold is evaluated to false before the test has completed. |
+| delayAbortEval | string | If you want to delay the evaluation of the threshold for some time, to allow for some metric samples to be collected, you can specify the amount of time to delay using relative time strings like `10s`, `1m` and so on. |
+
+> ### ⚠️ Evaluation delay in the cloud
+>
+> When k6 runs in the cloud, thresholds are evaluated every 60 seconds, therefore the "abortOnFail"
+> feature may be delayed by up to 60 seconds.
+
+
+## Failing a load test using checks
+
+[Checks](/using-k6/checks) are nice for codifying assertions, but unlike thresholds,
+checks will not affect the exit status of k6. This means a script that only uses checks to
+verify that things work as expected, will not be able to fail the whole test run based on the
+results of that/those checks. It can often be useful to combine checks and thresholds, to get
+the best of both:
+
+
+
+```js
+import http from 'k6/http';
+import { check } from 'k6';
+import { Rate } from 'k6/metrics';
+
+export let Rate500 = new Rate('500 errors');
+export let options = { thresholds: { '500 errors': ['rate<0.1'] } }; // 10%
+
+export default function() {
+ const result = check(http.get('http://httpbin.org'), {
+ 'status is 500': r => r.status == 500,
+ });
+
+ Rate500.add(result);
+}
+```
+
+
+
+
+## Thresholds in k6 Cloud Results
+
+In [k6 Cloud Results](/cloud/analyzing-results/overview) `Thresholds` are available in
+their [own tab](/cloud/analyzing-results/threshold-tab) for analysis.
+
+You can also see how the underlying metric compares to a specific threshold throughout the test.
+The threshold can be added to the analysis tab for further comparison against other metrics.
+
+
+
+Learn more about analyzing results in the [k6 Cloud Results docs](/cloud/analyzing-results/overview).
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/05 Modules.md b/src/data/markdown/docs/01 guides/02 Using k6/05 Modules.md
new file mode 100644
index 0000000000..fd072154f2
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/05 Modules.md
@@ -0,0 +1,379 @@
+---
+title: 'Modules'
+excerpt: ''
+---
+
+## Importing modules
+
+While writing test scripts, it's common to import different modules, or part of modules, for
+usage throughout the script. In k6, it is possible to import three different kinds of modules:
+
+### Built-in modules
+These modules are provided through the k6 core, and gives access to the functionality built
+into k6. This could, for instance, be the `http` client used for making requests against the
+system under test. For a full list of built-in modules, see `the api documentation`.
+
+```js
+import http from 'k6/http';
+```
+
+### Local filesystem modules
+These modules are stored on the local filesystem, and accessed either through relative
+or absolute filesystem paths. For a module residing in the local filesystem to be compatible
+with k6, the module itself may only use relative or absolute filesystem imports to access it's
+dependencies.
+
+```js
+import { someHelper } from './some.helper.js';
+```
+
+### Remote HTTP(S) modules
+These modules are accessed over HTTP(S), from a source like [the k6 jslib](#the-jslib-repository) or
+from any publicly accessible web server. The imported modules will be downloaded and executed at
+runtime, making it extremely important to **make sure the code is legit and trusted before including
+it in a test script**.
+
+```js
+import { randomItem } from "https://jslib.k6.io/k6-utils/1.0.0/index.js";
+```
+
+## Bundling node modules
+
+> ### Using the k6-es6 starter
+> A ready-to-use Webpack and Babel starter is available in the [examples section](/examples), or directly
+[on GitHub](https://github.com/k6io/k6-es6).
+
+In a javascript project running NodeJS, modules are imported using either `import` or `require()`,
+using the node module resolution algorithm. This means that the developer can import modules
+by name, without providing the full filesystem path to the module. For instance:
+
+```js
+import { ClassInAModule} from 'cool-module'
+```
+
+would be automatically resolved by the node resolution algorithm by searching:
+
+- The current directory
+- Any `node_modules` folder in the directory
+- Any `node_modules` folder in a parent directory, up to the closest `package.json` file.
+
+As the implementation of `import` in k6 lacks support for the node module resolution algorithm,
+node modules that resolve external dependencies will first needto be transformed into a self-contained,
+isolated, bundle.
+
+This is done with the help of a bundling tool, like Webpack, which analyses the test script,
+identifies all external dependencies, and then continues to create a self-contained bundle including
+everything necessary to run the script.
+
+If the test script has no external dependencies, already has them vendored in a k6 compatible way,
+or only uses ES5.1+ features, using a bundler will not be necessary.
+
+### Picking a bundler
+
+It is possible to use any bundler that supports transpilation. Popular ones include, but are not
+limited to, [webpack](https://github.com/webpack/webpack),
+[parcel](https://github.com/parcel-bundler/parcel), [rollup](https://github.com/rollup/rollup)
+and [browserify](https://github.com/browserify/browserify).
+
+Due to its flexibility, ease of use, relatively low resource consumption, and known compatibility
+with k6, it is recommended to use [webpack](https://github.com/webpack/webpack) unless you have a
+specific reason to choose something else.
+
+### Things to consider
+In general, all external modules added to a test project have a negative impact on performance, as they further increase the memory footprint and CPU usage.
+
+Usually, this is not a big problem as each application only allocates these resources once. In k6, however, every VU has a separate javascript virtual machine, duplicating the resource usage once each.
+
+By running code requiring additional features on top of ES5.1, we also need additional extensions to the javascript vm, further boosting the resource usage. This is the default mode of k6.
+
+When bundling using the configuration described in this article, babel and corejs automatically adds the features needed, thus allowing us to run our script without these extensions, using `--compatibility-mode=base`. For more details on the performance bnefits of running in the base compability mode, see [this article]((/using-k6/javascript-compatibility-mode#performance-comparison)).
+
+## Setting up the bundler
+Setting up a Babel and Webpack project from scratch might sound like a big undertaking, but
+is usually accomplished within minutes. Start by creating a project folder and initializing
+npm:
+
+
+
+| Package | Usage |
+| ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| [webpack](https://github.com/webpack/webpack) | The bundler part of Webpack |
+| [webpack-cli](https://github.com/webpack/webpack-cli) | The CLI part of Webpack, which allows us to use it from the terminal |
+| [k6](https://github.com/loadimpact/k6) | A dummy package used to provide typeahead in VSCode and similar |
+| [babel-loader](https://github.com/babel/babel-loader) | A loader used by Webpack to leverage babel functionality while bundling |
+| [@babel/core](https://github.com/babel/babel/tree/master/packages/babel-core) | The core functionality of Babel |
+| [@babel/preset-env](https://github.com/babel/babel/tree/master/packages/babel-preset-env) | A smart preset using [browserlist](https://github.com/browserslist/browserslist), [compat-table](https://github.com/kangax/compat-table) and [electron-to-chromium](https://github.com/Kilian/electron-to-chromium) to determine what code to transpile and polyfill. |
+| [core-js](https://github.com/zloirock/core-js) | A modular standard library for JS including polyfills |
+
+### Configuring Webpack
+
+Once these packages have been added, the next step will be to set up a `webpack.config.js` file:
+
+
+
+**Mode**
+
+Tells Webpack to automatically use the optimizations associated with the `mode`.
+Additional details available in [the webpack docs](https://webpack.js.org/configuration/mode/).
+
+**Entry**
+
+The files Webpack will use as its entry points while performing the bundling. From these points,
+Webpack will automatically traverse all imports recursively until every possible dependency path has
+been exhausted. For instance:
+
+
+
+```js
+// login.test.js
+
+import { SomeService } from './some.service.js';
+
+const svc = new SomeService();
+```
+
+
+
+and
+
+
+
+```js
+// some.service.js
+
+import * as lodash from 'lodash'
+
+export class SomeService {
+ constructor() {
+ this._ = lodash;
+ }
+}
+```
+
+
+
+would result in Webpack bundling `login.test.js`, `some.service.js` and all upstream dependencies
+utilized by `lodash`.
+
+**Output**
+
+The `path` key takes an absolute path which is where the finished bundle will be placed. In
+this example, `path.resolve` is used to concatenate `__dirname` and `'dist'` into an absolute
+path.
+
+The `libraryTarget` key configures how the library will be exposed. Setting it to `commonjs`
+will result in it being exported using `module.exports`. Additional details available in [the
+Webpack docs](https://webpack.js.org/configuration/output/#outputlibrarytarget).
+
+The `filename` key, as the name suggests, configures the name of the finished bundles. In this
+example, the [template string](https://webpack.js.org/configuration/output/#template-strings) `[name]`
+is used to add a dynamic part to the output filename.
+
+### Adding a bundle command
+
+Open the `package.json` file and add a new script entry, used for running the bundling process.
+
+```diff
+{
+ "name": "bundling-example",
+ "description": "",
+ "version": "0.1.0",
+ "private": true,
+ "scripts": {
++ "bundle": "webpack"
+ }
+ ...
+}
+```
+
+## Running the bundling
+
+Running webpack will now output two different test bundles, that may be executed independently:
+
+
+
+## The JSLib repository
+A repository of libraries that are known to play nicely with k6 is available at https://jslib.k6.io/.
+
+These libraries can either be downloaded and included with the test project or loaded directly using HTTP imports as shown [here](#remote-https-modules).
+
+## Using local modules with Docker
+
+When running k6 in a Docker container you must make sure to mount the necessary folders from the host into the container, using [Docker volumes](https://docs.docker.com/engine/admin/volumes/volumes/), so that k6 can see all the JS modules it needs to import.
+
+For example, say you have the following structure on your host machine:
+
+- `/home/k6/example/src/index.js`
+- `/home/k6/example/src/modules/module.js`
+
+
+
+To run index.js and make the modules available for import we execute the following Docker command with the `/home/k6/example/src` host folder mounted at `/src` in the container:
+
+
+
+```shell
+$ docker run -v /home/k6/example/src:/src -i loadimpact/k6 run /src/index.js
+```
+
+
+
+Note that on Windows, you also need to make sure that your drive in question, say `C:\`,
+has been marked for sharing in the Docker settings:
+
+
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/06 Tags and Groups.md b/src/data/markdown/docs/01 guides/02 Using k6/06 Tags and Groups.md
new file mode 100644
index 0000000000..16cc0c3db4
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/06 Tags and Groups.md
@@ -0,0 +1,196 @@
+---
+title: 'Tags and Groups'
+excerpt: ''
+---
+
+The analysis of your load results is a required step to find performance issues; a load test
+usually targets a service involving different subsystems and resources, making it hard to find
+the issue/s degrading your performance.
+
+k6 provides two scripting APIs to help you during the analysis and easily visualize, sort and
+filter your test results.
+
+- Groups: organize your load script around common logic.
+- Tags: categorize your checks, thresholds, custom metrics and requests with tags for in-depth filtering.
+
+## Groups
+
+Groups are optional, and it allows you to “group” your load script. Groups can be nested,
+allowing you the BDD-style of testing.
+
+
+
+Your test results will be grouped based on your group names for easy visualization. Each
+execution of the supplied `group()` function also emits a `group_duration`
+[metric](/using-k6/metrics) that contains the total time it took to execute that group
+function. This, combined with the metric tags described below, enables very flexible performance
+monitoring of different groups in your test suite.
+
+## Tags
+
+Tags are a simple and powerful way to categorize your k6 entities for later results filtering.
+
+k6 provides two types of tags:
+
+- User-defined tags: the ones you've added when writing your script.
+- System tags: tags automatically assigned by k6.
+
+### System tags
+
+Currently, k6 automatically creates the following tags by default:
+
+| Tag | Description |
+| ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `proto` | the used protocol name (e.g. `HTTP/1.1`) |
+| `subproto` | the subprotocol name (used by websockets) |
+| `status` | the HTTP status code (e.g. `200`, `404`, etc.) |
+| `method` | the HTTP method name (e.g. `GET`, `POST`, etc.) |
+| `url` | the HTTP request URL |
+| `name` | the HTTP [request name](/using-k6/http-requests#url-grouping) |
+| `group` | the full [group](#groups) path |
+| `check` | the [Check](/using-k6/checks) name |
+| `error` | a string with a non-HTTP error message (e.g. network or DNS error) |
+| `error_code` | added in k6 v0.24.0, this is a number that is unique for different error types; a list of current error codes can be found at the [Error Codes](/javascript-api/error-codes) page |
+| `tls_version` | the [TLS](/using-k6/ssl-tls) version |
+
+If you choose, you could disable some of the above tags by using the `systemTags`
+[option](/using-k6/options), just keep in mind that some data collectors (e.g. `cloud`)
+may require that certain tags be present. Also, you can enable some additional system tags, if
+you need them:
+
+| Tag | Description |
+| ------------- | ----------------------------------------------------------------------------------------------------------------------- |
+| `vui`iu099u | the ID of the virtual user that executed the request |
+| `iter` | the iteration number |
+| `ip` | The IP address of the remote server |
+| `ocsp_status` | the [Online Certificate Status Protocol (OCSP)](/using-k6/ssl-tls/online-certificate-status-protocol-ocsp) HTTPS status |
+
+### User-defined tags
+
+User-defined tags allow you to categorize k6 entities based on your logic. The following entities
+can be tagged:
+
+- checks
+- thresholds
+- custom metrics
+- requests
+
+
+
+```js
+import http from 'k6/http';
+import { Trend } from 'k6/metrics';
+import { check } from 'k6';
+
+let myTrend = new Trend('my_trend');
+
+export default function() {
+ // Add tag to request metric data
+ let res = http.get('http://httpbin.org/', {
+ tags: {
+ my_tag: "I'm a tag",
+ },
+ });
+
+ // Add tag to check
+ check(
+ res,
+ { 'status is 200': r => r.status === 200 },
+ { my_tag: "I'm a tag" },
+ );
+
+ // Add tag to custom metric
+ myTrend.add(res.timings.connecting, { my_tag: "I'm a tag" });
+}
+```
+
+
+
+## Test wide tags
+
+Besides attaching tags on requests, checks and custom metrics you can set test wide tags that
+will be set across all metrics. You can either set the tags on the CLI using one or more
+`--tag NAME=VALUE` flags or in the script:
+
+
+
+Read more about the [k6 results output syntax](/getting-started/results-output/json) to
+see how tags affect your test result output.
+
+## Tags and Groups in k6 Cloud Results
+
+In [k6 Cloud Results](/cloud/analyzing-results/overview) you can see groups
+in the [result tabs](/cloud/analyzing-results/overview#result-tabs).
+
+When using Groups, [Checks](/using-k6/checks) and [HTTP Requests](/using-k6/http-requests)
+can be view by group, as shown below. You can switch between the group and list layout by changing the "view as"
+selection in the top right.
+
+
+
+Additionally you can filter the results in the in [analysis tab](/cloud/analyzing-results/analysis-tab)
+by tags as shown below:
+
+
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/07 Environment variables.md b/src/data/markdown/docs/01 guides/02 Using k6/07 Environment variables.md
new file mode 100644
index 0000000000..ab46604a24
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/07 Environment variables.md
@@ -0,0 +1,94 @@
+---
+title: 'Environment variables'
+excerpt: ''
+---
+
+## k6 and environment variables
+
+There are two ways in which environment variables can be used with k6:
+
+- You can access any environment variables from your k6 script code, and use this to supply your
+ VUs with configuration information.
+- There are also a couple of environment variables that k6 will automatically try to read upon
+ startup, and which will affect its behavior.
+
+## Accessing environment variables from a script
+
+A lot of the time, scripts will only need minor tweaking to be reusable in different
+contexts. Rather than having to create several separate scripts for these different
+contexts or environments, you can use environment variables to make parts of your
+script tweakable.
+
+In k6, the environment variables are exposed through a global `__ENV` variable, a JS
+object. The source of the environment variables can be twofold. They could come from
+the local system and/or be explicitly passed to k6 using one or more `-e NAME=VALUE`
+CLI flags.
+
+The primary difference between the two is that only `k6 run` passes the actual system
+environment variables to the script code by default, while `k6 archive`, `k6 cloud` and
+`k6 inspect` do not. So unless you explicitly specify `--include-system-env-vars`, only
+the variables passed using the `-e` CLI flag will be persisted when creating an archive
+(`k6 archive script.js`). You can also disable the default passing of system environment
+variables when running scripts by using `--include-system-env-vars=false`.
+
+An environment variable could, for example, be specified like this on the command line:
+
+
+
+```shell
+$ MY_HOSTNAME=test.k6.io k6 run script.js
+```
+
+```powershell
+c:\\k6> set MY_HOSTNAME=\"test.k6.io\"\nc:\\k6> k6 run script.js
+```
+
+```powershell
+c:\\k6> $env:MY_HOSTNAME = \"test.k6.io\"\nc:\\k6> k6 run script.js
+```
+
+
+
+or using an `-e` CLI flag (which will be the same for all platforms):
+
+
+
+The environment variable could then be used as follows in a script:
+
+
+
+```js
+import { check, sleep } from 'k6';
+import http from 'k6/http';
+
+export default function() {
+ var r = http.get(`http://${__ENV.MY_HOSTNAME}/`);
+ check(r, {
+ 'status is 200': r => r.status === 200,
+ });
+ sleep(5);
+}
+```
+
+
+
+Environment variables specified with the `-e` CLI flag takes precedence over (overwrite) actual
+system environment variables with the same name.
+
+## Environment variables k6 will read automatically
+
+k6 will also try to read some specific environment variables that the user can set to change the
+behavior of k6:
+
+| Name | Description |
+| -------------------- | ---------------------------------------------------------------------------------------------------------------------- |
+| `K6_CLOUD_HOST` | A URL to connect to, when the --out=cloud results output option is specified. |
+| `K6_CLOUD_TOKEN` | An authentication token to use in API calls to the cloud service, when the --cloud results output option is specified. |
+| `K6_NO_USAGE_REPORT` | Define this to disable [usage reports](/misc/usage-reports). |
+| `K6_OUT` | Specify results output, same as --out command-line option. |
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/08 Options.md b/src/data/markdown/docs/01 guides/02 Using k6/08 Options.md
new file mode 100644
index 0000000000..52b583645e
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/08 Options.md
@@ -0,0 +1,1127 @@
+---
+title: 'Options'
+excerpt: ''
+---
+
+## Using Options
+
+Options allow you to configure how k6 will behave during test execution. They can be a part of the
+script code so that they can be version controlled. They can also be specified with command-line
+flags, environment variables or via a config file. Please refer to the list of available options
+below for more details.
+
+The order of precedence is: defaults < config file < exported script options < environment
+variables < command-line flags. Options from each subsequent level can be used to overwrite the
+options from the previous levels, with the CLI flags having the highest priority.
+
+For example, you can define the duration in 4 different ways:
+
+- set the `duration: "10s"` option in the config file
+- set the `duration: "10s"` option in the script
+- define `K6_DURATION` as an environment variable
+- use the command-line flag `-d 10s`
+
+The following JS snippet shows how to specify options in the script:
+
+
+
+Or set some of the previous options via environment variables and command-line flags:
+
+
+
+```shell
+$ K6_NO_CONNECTION_REUSE=true K6_USER_AGENT="MyK6UserAgentString/1.0" k6 run ~/script.js
+
+$ k6 run ---no-connection-reuse --user-agent "MyK6UserAgentString/1.0" ~/script.js
+```
+
+
+
+
+
+Below, you'll find details on all available options that can be specified within a script. It also
+documents the equivalent command line flag, environment variables or option when executing `k6 run ...`
+and `k6 cloud ...` that can be used to override options specified in the code.
+
+## TLS Cipher Suites
+
+A list of cipher suites allowed to be used by in SSL/TLS interactions with a server.
+For a full listing of available ciphers go [here](https://golang.org/pkg/crypto/tls/#pkg-constants).
+
+| Env | CLI | Code / Config file |
+| --- | --- | ------------------ |
+| N/A | N/A | `tlsCipherSuites` |
+
+### Default
+
+`null` - Allow all suites
+
+### Example
+
+
+
+## Duration
+
+A string specifying the total duration a test run should be run for. During this time each
+VU will execute the script in a loop. Available in `k6 run` and `k6 cloud` commands.
+
+| Env | CLI | Code / Config file |
+| ------------- | ------------------ | ------------------ |
+| `K6_DURATION` | `--duration`, `-d` | `duration` |
+
+### Default
+
+null
+
+### Example
+
+
+
+## Extension Options
+
+An object used to set configuration options for third-party collectors, like plugins.
+
+| Env | CLI | Code / Config file |
+| --- | --- | ------------------ |
+| N/A | N/A | `ext` |
+
+### Default
+
+null
+
+### Example
+
+This is an example of how to specify the test name (test runs/executions with the same name will be
+logically grouped for trending and comparison) when streaming results to
+[k6 Cloud Insights](/cloud/analyzing-results/performance-insights).
+
+
+
+## Hosts
+
+An object with overrides to DNS resolution, similar to what you can do with `/etc/hosts` on
+Linux/Unix or `C:\\Windows\\System32\\drivers\\etc\\hosts` on Windows. For instance, you could set
+up an override which routes all requests for `test.k6.io` to `1.2.3.4`.
+
+> ### ⚠️ Keep in mind!
+>
+> This does not modify the actual HTTP `Host` header, but rather where it will be routed.
+
+| Env | CLI | Code / Config file |
+| --- | --- | ------------------ |
+| N/A | N/A | `hosts` |
+
+### Default
+
+null
+
+### Example
+
+
+
+## Iterations
+
+A number specifying a fixed number of iterations to execute of the script, as opposed to specifying
+a duration of time during which the script would run in a loop.
+\*Note: The number of iterations
+is split between all VUs. Available in `k6 run` command (not yet supported for cloud executed
+tests using the `k6 cloud` command).
+
+| Env | CLI | Code / Config file |
+| --------------- | -------------------- | ------------------ |
+| `K6_ITERATIONS` | `--iterations`, `-i` | `iterations` |
+
+### Default
+
+1
+
+### Example
+
+
+
+## Thresholds
+
+A collection of threshold specifications to configure under what condition(s) a test is considered
+successful or not, when it has passed or failed, based on metric data. To learn more, have a look
+at the [Thresholds](/using-k6/thresholds) documentation. Available in `k6 run` commands.
+
+| Env | CLI | Code / Config file |
+| --- | --- | ------------------ |
+| N/A | N/A | `thresholds` |
+
+### Default
+
+null
+
+### Example
+
+
+
+## No Thresholds
+
+Disables threshold execution. Available in the `k6 run` command.
+
+| Env | CLI | Code / Config file |
+| ------------------ | ----------------- | ------------------ |
+| `K6_NO_THRESHOLDS` | `--no-thresholds` | N/A |
+
+### Default
+
+false
+
+### Example
+
+
+
+```shell
+$ k6 run --no-thresholds ~/script.js
+```
+
+
+
+## Max Redirects
+
+The maximum number of HTTP redirects that k6 will follow before giving up on a request and
+erroring out. Available in both the `k6 run` and the `k6 cloud` commands.
+
+| Env | CLI | Code / Config file |
+| ------------------ | ----------------- | ------------------ |
+| `K6_MAX_REDIRECTS` | `--max-redirects` | `maxRedirects` |
+
+### Default
+
+10
+
+### Example
+
+
+
+## Batch
+
+The maximum number of simultaneous/parallel connections in total that an
+[`http.batch()`](/javascript-api/k6-http/batch-requests) call in a VU can make. If you have a
+`batch()` call that you've given 20 URLs to and `--batch` is set to 15, then the VU will make 15
+requests right away in parallel and queue the rest, executing them as soon as a previous request is
+done and a slot opens. Available in both the `k6 run` and the `k6 cloud` commands
+
+| Env | CLI | Code / Config file |
+| ---------- | --------- | ------------------ |
+| `K6_BATCH` | `--batch` | `batch` |
+
+### Default
+
+10
+
+### Example
+
+
+
+## No Usage Report
+
+A boolean, true or false. By default, k6 sends a usage report each time it is run, so that we can
+track how often people use it. If this option is set to true, no usage report will be made. To
+learn more, have a look at the [Usage reports](/misc/usage-reports) documentation. Available in
+`k6 run` commands.
+
+| Env | CLI | Code / Config file |
+| -------------------- | ------------------- | ------------------ |
+| `K6_NO_USAGE_REPORT` | `--no-usage-report` | `noUsageReport` |
+
+### Default
+
+false
+
+### Example
+
+
+
+## RPS
+
+The maximum number of requests to make per second, in total across all VUs. Available in `k6 run`
+and `k6 cloud` commands.
+
+| Env | CLI | Code / Config file |
+| -------- | ------- | ------------------ |
+| `K6_RPS` | `--rps` | `rps` |
+
+### Default
+
+0 (unlimited)
+
+### Example
+
+
+
+## Stages
+
+A list of VU `{ target: ..., duration: ... }` objects that specify the target number of VUs to
+ramp up or down to for a specific period. Available in `k6 run` and `k6 cloud` commands,
+
+| Env | CLI | Code / Config file |
+| ----------- | ------------------------------------------------------- | ------------------ |
+| `K6_STAGES` | `--stage :`, `-s :` | `stages` |
+
+### Default
+
+Based on `vus` and `duration`.
+
+### Example
+
+
+
+```js
+// The following config would have k6 ramping up from 1 to 10 VUs for 3 minutes,
+// then staying flat at 10 VUs for 5 minutes, then ramping up from 10 to 35 VUs
+// over the next 10 minutes before finally ramping down to 0 VUs for another
+// 3 minutes.
+
+export let options = {
+ stages: [
+ { duration: '3m', target: 10 },
+ { duration: '5m', target: 10 },
+ { duration: '10m', target: 35 },
+ { duration: '3m', target: 0 },
+ ],
+};
+```
+
+```shell
+$ k6 run --stage 5s:10,5m:20,10s:5 ~/script.js
+
+# or...
+
+$ K6_STAGES="5s:10,5m:20,10s:5" k6 run ~/script.js
+```
+
+
+
+## Summary export
+
+> _New in v0.26.0_
+
+Output the end-of-test summary report to a JSON file that includes
+data for all test metrics, checks and thresholds. This is useful to
+get the aggregated test results in a machine-readable format, for
+integration with dashboards, external alerts, etc.
+
+Available in the `k6 run` command.
+
+| Env | CLI | Code / Config file |
+|---------------------|-------------------------------|--------------------|
+| `K6_SUMMARY_EXPORT` | `--summary-export ` | N/A |
+
+### Default
+
+null
+
+### Example
+
+
+
+```shell
+$ k6 run --summary-export export.json ~/script.js
+
+# or...
+
+$ K6_SUMMARY_EXPORT="export.json" k6 run ~/script.js
+```
+
+
+
+See an example file on the [Results Output](https://k6.io/docs/getting-started/results-output#summary-export) page.
+
+
+## Tags
+
+Specify tags that should be set test wide across all metrics. If a tag with the same name has
+been specified on a request, check or custom metrics it will have precedence over a test wide
+tag. Available in `k6 run` and `k6 cloud` commands.
+
+| Env | CLI | Code / Config file |
+| --- | ------------------ | ------------------ |
+| N/A | `--tag NAME=VALUE` | `tags` |
+
+### Default
+
+null
+
+### Example
+
+
+
+## Include System Env Vars
+
+Pass the real system environment variables to the runtime. Available in `k6 run` and `k6 cloud`
+commands.
+
+| Env | CLI | Code / Config file |
+| --- | --------------------------- | ------------------ |
+| N/A | `--include-system-env-vars` | N/A |
+
+### Default
+
+true for `k6 run`, but false for all other commands to prevent inadvertent sensitive data leaks.
+
+### Example
+
+
+
+```shell
+$ k6 run --include-system-env-vars ~/script.js
+```
+
+
+
+## Supply Env Var
+
+Add/override environment variable with VAR=value. Available in `k6 run` and `k6 cloud` commands.
+
+| Env | CLI | Code / Config file |
+| --- | ------------- | ------------------ |
+| N/A | `--env`, `-e` | N/A |
+
+### Default
+
+### Example
+
+
+
+## Results Output
+
+Specify the results output. Please go to [Results ouput](/getting-started/results-output) for more information
+on all output plugins available and how to configure them. Since version 0.21, this option can be
+specified multiple times. Available in `k6 run` command.
+
+| Env | CLI | Code / Config file |
+| --- | ------------- | ------------------ |
+| N/A | `--out`, `-o` | N/A |
+
+### Default
+
+null
+
+### Example
+
+
+
+## Skip TLS Verification
+
+A boolean, true or false. When this option is enabled (set to true), all of the verifications that
+would otherwise be done to establish trust in a server provided TLS certificate will be ignored.
+Available in `k6 run` and `k6 cloud` commands
+
+| Env | CLI | Code / Config file |
+| ----------------------------- | ---------------------------- | ----------------------- |
+| `K6_INSECURE_SKIP_TLS_VERIFY` | `--insecure-skip-tls-verify` | `insecureSkipTLSVerify` |
+
+### Default
+
+false
+
+### Example
+
+
+
+## TLS Version
+
+Either a string representing the only SSL/TLS version allowed to be used in interactions with a
+server, or an object specifying the "min" and "max" versions allowed to be used.
+
+| Env | CLI | Code / Config file |
+| --- | --- | ------------------ |
+| N/A | N/A | `tlsVersion` |
+
+### Default:
+
+`null` - Allow all versions
+
+### Example:
+
+
+
+## VUs
+
+A number specifying the number of VUs to run concurrently. If you'd like more control look at
+the [`stages`](#stages) option. Available in `k6 run` and `k6 cloud` commands.
+
+| Env | CLI | Code / Config file |
+| -------- | ------------- | ------------------ |
+| `K6_VUS` | `--vus`, `-v` | `vus` |
+
+### Default
+
+1
+
+### Example
+
+
+
+## VUs Max
+
+A number specifying max number of virtual users, if more than `vus`. This option is typically
+used when the intent is to dynamically scale the amount of VUs up and down during the test using
+the `k6 scale` command. Since instantiating a VU is an expensive operation in k6 this option
+is used to preallocate `vusMax` number of VUs. Available in `k6 run` and `k6 cloud` commands.
+
+| Env | CLI | Code / Config file |
+| ------------ | ------------- | ------------------ |
+| `K6_VUS_MAX` | `--max`, `-m` | `vusMax` |
+
+### Default
+
+0
+
+### Example
+
+
+
+## System Tags
+
+Specify which [System Tags](/using-k6/tags-and-groups#section-system-tags) will be in the collected
+metrics. Some collectors like the `cloud` one may require that certain system tags be used.
+You can specify the tags as an array from the JS scripts or as a comma-separated list via the
+CLI. Available in `k6 run` and `k6 cloud` commands
+
+| Env | CLI | Code / Config file |
+| ---------------- | --------------- | ------------------ |
+| `K6_SYSTEM_TAGS` | `--system-tags` | `systemTags` |
+
+### Default
+
+`proto`, `subproto`, `status`, `method`, `url`, `name`, `group`, `check`, `error`, `tls_version`
+
+### Example
+
+
+
+## Setup Timeout
+
+Specify how long the `setup()` function is allow to run before it's terminated and the test fails.
+
+| Env | CLI | Code / Config file |
+| ------------------ | --- | ------------------ |
+| `K6_SETUP_TIMEOUT` | N/A | `setupTimeout` |
+
+### Default
+
+`10s`
+
+### Example
+
+
+
+## Teardown Timeout
+
+Specify how long the `teardown()` function is allowed to run before it's terminated and the test
+fails.
+
+| Env | CLI | Code / Config file |
+| --------------------- | --- | ------------------ |
+| `K6_TEARDOWN_TIMEOUT` | N/A | `teardownTimeout` |
+
+### Default
+
+`10s`
+
+### Example
+
+
+
+## Config
+
+Specify the config file in JSON format to read the `options` values. If the config file is not
+specified, k6 will look for `config.json` in the `loadimpact/k6` directory inside the regular
+directory for configuration files on the operating system.
+
+For example in Linux/BSDs, it will look for `config.json` inside `${HOME}/.config/loadimpact/k6`.
+Available in `k6 run` and `k6 cloud` commands
+
+| Env | CLI | Code / Config file |
+| --- | ------------------------------ | ------------------ |
+| N/A | `--config `, `-c ` | N/A |
+
+### Default
+
+null
+
+## Discard Response Bodies
+
+Specify if response bodies should be discarded by changing the default value of
+[responseType](/javascript-api/k6-http/params-k6-http) to `none` for all HTTP requests. Highly recommended to be set
+to `true` and then only for the requests where the response body is needed for scripting
+to set [responseType](/javascript-api/k6-http/params-k6-http) to `text` or `binary`. Lessens the amount of memory
+required and the amount of GC - reducing the load on the testing machine, and probably producing
+more reliable test results.
+
+| Env | CLI | Code / Config file |
+| ---------------------------- | --------------------------- | ----------------------- |
+| `K6_DISCARD_RESPONSE_BODIES` | `--discard-response-bodies` | `discardResponseBodies` |
+
+### Default
+
+false
+
+### Example
+
+
+
+## Minimum Iteration Duration
+
+Specifies the minimum duration for every single execution (i.e. iteration) of the default
+function should be. Any iterations that are shorter than it will cause that VU to sleep for
+the remainder of the time until the specified minimum duration is reached.
+
+| Env | CLI | Code / Config file |
+| --------------------------- | -------------------------- | ---------------------- |
+| `K6_MIN_ITERATION_DURATION` | `--min-iteration-duration` | `minIterationDuration` |
+
+### Default
+
+`0` (disabled)
+
+### Example
+
+
+
+## No Cookies Reset
+
+This disables the default behavior of resetting the cookie jar after each VU iteration. If
+it's enabled, saved cookies will be persisted across VU iterations.
+
+| Env | CLI | Code / Config file |
+| --------------------- | --- | ------------------ |
+| `K6_NO_COOKIES_RESET` | N/A | `noCookiesReset` |
+
+### Default
+
+false
+
+### Example
+
+
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/09 Cookies.md b/src/data/markdown/docs/01 guides/02 Using k6/09 Cookies.md
new file mode 100644
index 0000000000..b5a28b5df1
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/09 Cookies.md
@@ -0,0 +1,289 @@
+---
+title: 'Cookies'
+excerpt: ''
+---
+
+HTTP Cookies are used by web sites and apps to store pieces of stateful information on the user's
+device. A server tells the client, via a `Set-Cookie` HTTP header, what information it wants to be
+stored on the user's machine.
+
+The user's browser will store the cookie data and associate it with the hostname of the server,
+and for each subsequent request to that hostname, it will include the stored cookie data in a
+`Cookie` header.
+
+You can then control more specific rules for when cookie data should be sent or not, including
+limiting it to specific subdomains of the domain or a specific path. It's also possible to set an
+expiry date on the cookie and tell the browser only to send it over encrypted (SSL/TLS)
+connections.
+
+## Cookies with k6
+
+For most intents and purposes k6 will transparently manage the receiving, storage and sending of
+cookies as described above, so that testing of your cookie-based web site or app will just work
+without you having to do anything special.
+
+There are however use cases where more control over cookies is desired. In k6 you have two
+options, [either to directly manipulate HTTP headers](/javascript-api/k6-http/params-k6-http),
+or use the more ergonomic cookie API. We will go through the latter below.
+
+## Setting simple cookies
+
+To simulate that a cookie has previously been set by a browser and is now supposed to be included
+in a subsequent request to the server we include the cookie in the `cookies` request parameter:
+
+
+
+This will only apply the cookie for the request in question, but will not be sent for any
+subsequent requests. If you want to do that you have to add the cookie to a cookie jar, and by
+default there's a per-VU cookie jar we can interact with to set and inspect cookies:
+
+
+
+The per-VU cookie jar stores all cookies received from the server in a `Set-Cookie` header. You
+can also create "local cookie jars" that overrides the per-VU cookie jar, but more on that in a bit.
+
+You can also specify that a cookie should be overridden if already part of the per-VU cookie jar:
+
+
+
+```js
+import http from 'k6/http';
+import { check } from 'k6';
+
+export default function() {
+ const jar = http.cookieJar();
+ jar.set('https://httpbin.org/cookies', 'my_cookie', 'hello world');
+
+ const cookies = {
+ my_cookie: {
+ value: 'hello world 2',
+ replace: true,
+ },
+ };
+
+ const res = http.get('https://httpbin.org/cookies', {
+ cookies,
+ });
+
+ check(res, {
+ 'cookie has correct value': r =>
+ r.json().cookies.my_cookie === 'hello world 2',
+ });
+}
+```
+
+
+
+## Accessing cookies
+
+To see which cookies were set for a particular response we can look in the `cookies` property of
+the response object:
+
+
+
+The response object's `cookies` property is a map where the key is the cookie name and the value
+is an array of response cookie objects (see below for description). It is an array to support
+multiple cookies having the same name (but different `domain` and/or `path` attributes), which
+is part of [RFC6265](https://tools.ietf.org/html/rfc6265#section-5.3).
+
+## Properties of a response cookie object
+
+A response cookie object contains the following properties:
+
+| Property | Type | Description |
+| --------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| name | `string` | the name of the cookie |
+| value | `string` | the value of the cookie |
+| domain | `string` | domain deciding what hostnames this cookie should be sent to |
+| path | `string` | limiting the cookie to only be sent if the path of the request matches this value |
+| expires | `string` | when the cookie expires, this needs to be in the RFC1123 format looking like: `Mon, 02 Jan 2006 15:04:05 MST` |
+| max_age | `number` | used for the same purpose as expires but defined as the number of seconds a cookie will be valid |
+| secure | `boolean` | if true, the cookie will only be sent over an encrypted (SSL/TLS) connection |
+| http_only | `boolean` | if true, the cookie would not be exposed to JavaScript in a browser environment |
+
+## Inspecting a cookie in the jar
+
+To see which cookies are set, and stored in the cookie jar, for a particular URL we can use the
+`cookieForURL()` method of the cookie jar object:
+
+
+
+```js
+import http from 'k6/http';
+import { check } from 'k6';
+
+export default function() {
+ let res = http.get(
+ 'https://httpbin.org/cookies/set?my_cookie=hello%20world',
+ { redirects: 0 },
+ );
+ let jar = http.cookieJar();
+ let cookies = jar.cookiesForURL('http://httpbin.org/');
+ check(res, {
+ "has cookie 'my_cookie'": r => cookies.my_cookie.length > 0,
+ 'cookie has correct value': r => cookies.my_cookie[0] === 'hello world',
+ });
+}
+```
+
+
+
+The `cookies` object returned by the jar's `cookiesForURL()` method is a map where the key is the
+cookie name and the value is an array of cookie values (strings). It is an array to support
+multiple cookies having the same name (but different `domain` and/or `path` attributes), which
+is part of [RFC6265](https://tools.ietf.org/html/rfc6265#section-5.3).
+
+## Setting advanced cookies with attributes
+
+To set cookies that more tightly controls the behavior of the cookie we must add the cookie to a
+cookie jar. An example:
+
+
+
+```js
+import http from 'k6/http';
+import { check } from 'k6';
+
+export default function() {
+ let jar = http.cookieJar();
+ jar.set('https://httpbin.org/cookies', 'my_cookie', 'hello world', {
+ domain: 'httpbin.org',
+ path: '/cookies',
+ secure: true,
+ max_age: 600,
+ });
+ let res = http.get('https://httpbin.org/cookies');
+ check(res, {
+ 'has status 200': r => r.status === 200,
+ "has cookie 'my_cookie'": r => r.json().cookies.my_cookie !== null,
+ 'cookie has correct value': r =>
+ r.json().cookies.my_cookie == 'hello world',
+ });
+}
+```
+
+
+
+## Local cookie jars
+
+Besides the per-VU cookie jar you can also create local cookie jars that can override the per-VU
+cookie jar on a per-request basis. An example:
+
+
+
+```js
+import http from 'k6/http';
+import { check } from 'k6';
+
+export default function() {
+ const jar = new http.CookieJar();
+
+ // Add cookie to local jar
+ const cookieOptions = {
+ domain: 'httpbin.org',
+ path: '/cookies',
+ secure: true,
+ max_age: 600,
+ };
+ jar.set(
+ 'https://httpbin.org/cookies',
+ 'my_cookie',
+ 'hello world',
+ cookeOptions,
+ );
+
+ // Override per-VU jar with local jar for the following request
+ let res = http.get('https://httpbin.org/cookies', { jar });
+ check(res, {
+ 'has status 200': r => r.status === 200,
+ "has cookie 'my_cookie'": r => r.json().cookies.my_cookie !== null,
+ 'cookie has correct value': r =>
+ r.json().cookies.my_cookie == 'hello world',
+ });
+}
+```
+
+
+
+## Examples
+
+
+
+```js
+// Example showing two methods how to log all cookies (with attributes) from a HTTP response.
+import http from 'k6/http';
+
+function logCookie(c) {
+ // Here we log the name and value of the cookie along with additional attributes.
+ // For full list of attributes see:
+ // https://k6.io/docs/using-k6/cookies#properties-of-a-response-cookie-object
+ const output = `
+ ${c.name}: ${c.value}
+ tdomain: ${c.domain}
+ tpath: ${c.path}
+ texpires: ${c.expires}
+ thttpOnly: ${c.http_only}
+ `;
+ console.log(output);
+}
+export default function() {
+ let res = http.get('https://www.google.com/');
+
+ // Method 1: Use for-loop and check for non-inherited properties
+ for (var name in res.cookies) {
+ if (res.cookies.hasOwnProperty(name) !== undefined) {
+ logCookie(res.cookies[name][0]);
+ }
+ }
+
+ // Method 2: Use ES6 Map to loop over Object entries
+ new Map(Object.entries(res.cookies)).forEach((v, k) => {
+ logCookie(v[0]);
+ });
+}
+```
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/10 Protocols.md b/src/data/markdown/docs/01 guides/02 Using k6/10 Protocols.md
new file mode 100644
index 0000000000..05266a594f
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/10 Protocols.md
@@ -0,0 +1,19 @@
+---
+title: "Protocols"
+excerpt: ""
+---
+Out of the box k6 comes with support for the following protocols:
+
+* HTTP/1.1
+* [HTTP/2](/using-k6/protocols/http-2)
+* [WebSockets](/using-k6/protocols/websockets)
+
+k6 will use HTTP/1.1 by default when it contacts a server. If, after connection, the server
+reports to k6 that it supports [HTTP/2](/using-k6/protocols/http-2), k6 will upgrade the
+connection to HTTP/2 instead. This is all automatic - both the use of HTTP/1.1 initially and
+the potential protocol upgrade, and you don't have to do anything special when using k6 to
+enable either HTTP/1.1 or HTTP/2. You might want to verify which protocol is actually being
+used for a transaction though, which requires an extra step.
+
+[WebSockets](/using-k6/protocols/websockets) is a little bit different, the structure of the
+test and the VU lifecycle is different.
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/10 Protocols/HTTP-2.md b/src/data/markdown/docs/01 guides/02 Using k6/10 Protocols/HTTP-2.md
new file mode 100644
index 0000000000..0358545761
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/10 Protocols/HTTP-2.md
@@ -0,0 +1,43 @@
+---
+title: "HTTP/2"
+excerpt: ""
+---
+
+## Overview
+
+HTTP/2.0 is the latest version of the HTTP protocol and introduces some major improvements compared to its predecessor. Chiefly of which is the introduction of a binary wire protocol with multiplexed streams over a single TCP connection. This solves a long-standing performance issue with HTTP/1.1, [head-of-line blocking](https://en.wikipedia.org/wiki/Head-of-line_blocking).
+
+Well, it at least *partially* solves it, since you still have TCP congestion control mechanisms interfering with the intended independent nature of the multiplexed streams in cases of lost/dropped packets and retransmission/reassembly. The full solution is to run HTTP/2.0 over UDP, which is what Google implemented with [QUIC](https://en.wikipedia.org/wiki/QUIC).
+
+## Additional features of HTTP/2.0
+
+* Builtin compression of HTTP headers
+* Server push
+* Pipelining of requests
+* Prioritization of requests
+
+## Load testing HTTP/2 with k6
+
+When you make HTTP requests in k6 it will automatically upgrade the connection to HTTP/2.0 if the server supports it, just like your web browser would. You can check what protocol was used for a particular request by looking at the `proto` property of the response object.
+
+
+
+For more information on what values the r.proto field can have, check out:
+
+* [k6 HTTP](/javascript-api/k6-http/response-k6-http)
+* https://http2.github.io/http2-spec/#versioning
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/10 Protocols/WebSockets.md b/src/data/markdown/docs/01 guides/02 Using k6/10 Protocols/WebSockets.md
new file mode 100644
index 0000000000..71fdcb8a1e
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/10 Protocols/WebSockets.md
@@ -0,0 +1,193 @@
+---
+title: "WebSockets"
+excerpt: ""
+---
+
+## Overview
+
+[WebSocket](https://en.wikipedia.org/wiki/WebSocket) is a protocol that provides full-duplex communication channels over a single TCP connection. It is commonly used by single-page apps (SPAs), and to some extent mobile apps, to add server-push based functionality, which usually means a performance improvement over polling based solutions.
+
+## Load testing WebSockets with k6
+
+There are some differences in the structure and inner workings of a test when comparing HTTP based to WebSocket based ones. The primary difference is that instead of continuously looping the main function (`export default function() { ... }`) over an over, each VU is now setup to run an asynchronous event loop.
+
+The basic structure of a WebSocket test looks like this:
+
+
+
+As you can see above the [connect()](/javascript-api/k6-ws/connect-url-params-callback) method takes a "run" function as its third parameter, and that function should accept a [Socket](/javascript-api/k6-ws/socket) object as its only parameter. The run function forms the basis of the asynchronous event loop.
+
+It will be called immediately when the WebSocket connection is created, execute all code inside it (usually code to set up event handlers), and then block until the WebSocket connection is closed (by the remote host or by using [socket.close()](/javascript-api/k6-ws/socket/socket-close)).
+
+## Error handling
+
+To catch errors that can happen during the life of a WebSocket connection you attach a handler to the "error" event, as is illustrated below:
+
+
+
+## Timers
+
+If you want to schedule a recurring action you can use the [socket.setInterval](/javascript-api/k6-ws/socket#section-socketsetinterval) function to specify a function that should be called with a particular interval.
+
+
+
+
+## Timeouts
+
+You can add a timeout to the WebSocket connection by passing a handler function as well as the
+timeout value (in milliseconds) to the [socket.setTimeout](/javascript-api/k6-ws/socket/socket-settimeout-callback-delay) function.
+
+
+
+The timeout in the above code will close down the WebSocket connection after 2 seconds.
+
+## Multiple event handlers
+
+You can attach multiple handler functions to an event as the code below illustrates.
+
+
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/11 SSL-TLS.md b/src/data/markdown/docs/01 guides/02 Using k6/11 SSL-TLS.md
new file mode 100644
index 0000000000..d412ad1be2
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/11 SSL-TLS.md
@@ -0,0 +1,33 @@
+---
+title: 'SSL/TLS'
+excerpt: ''
+---
+
+Transport Layer Security (TLS), the successor of Secure Socket Layer (SSL), is the mechanism through
+which encrypted connections can be established between clients and servers on the web and through
+which data can flow with integrity intact.
+
+Simplified, TLS is made possible by using a Public Key Infrastructure (PKI) involving private
+cryptographic keys, certificates of ownership (public, signed with private key) and certificate
+authorities (CAs, issuing and asserting the validity of issued certificates).
+
+The entire system is dependent on the functioning operation of the CAs, that the cryptographic keys
+they use to sign certificates of ownership to site/domain owners are kept secret. It is also
+dependent on the site/domain owners' ability to keep their private cryptographic key secret.
+
+If they fail to do so, they have to report this to the CA that issued the certificate so that the
+CA can revoke it, and by doing so letting browsers and other clients know of the changes through
+the Online Certificate Status Protocol (OCSP).
+
+## TLS in k6
+
+By default and without any special configuration k6 will connect and talk to servers over TLS -
+You just need to make sure that your request URLs are specified with the `https` scheme.
+
+The following TLS functionality supported by k6 is worth talking about in more detail:
+
+- [TLS client certificates](/using-k6/ssl-tls/ssl-tls-client-certificates)
+- [TLS version and ciphers](/using-k6/ssl-tls/ssl-tls-version-and-ciphers) (restricting as
+ well as checking what was used for a HTTP request by checking response object properties)
+- [Online Certificate Status Protocol (OCSP)](/using-k6/ssl-tls/online-certificate-status-protocol-ocsp)
+- [Response.timings.tls_handshaking](/javascript-api/k6-http/response-k6-http)
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/11 SSL-TLS/Online Certificate Status Protocol -OCSP-.md b/src/data/markdown/docs/01 guides/02 Using k6/11 SSL-TLS/Online Certificate Status Protocol -OCSP-.md
new file mode 100644
index 0000000000..f26834d9b5
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/11 SSL-TLS/Online Certificate Status Protocol -OCSP-.md
@@ -0,0 +1,77 @@
+---
+title: "Online Certificate Status Protocol (OCSP)"
+excerpt: ""
+---
+
+## What is OCSP?
+
+Online Certificate Status Protocol (OCSP) is a protocol that web browsers and clients can use
+to check the status of an issued TLS certificate with a Certificate Authority (CA), making sure
+it has not been revoked for whatever purpose.
+
+There are different ways in which this can be done, by putting the burden on different parties:
+
+- The browser/client: talk to the CA (or by CA entrusted OCSP responder) with OCSP. One downside
+ with this approach is that the CA's servers need to be available which might not always be the case.
+
+- The browser vendor: maintain a regularly updated list of certificate revocations by talking to
+ the CAs (or by CA entrusted OCSP responder) and then distributing this list to the browsers
+ running on users' machines.
+- The server side: the server handles the interaction with the CA (or by CA entrusted OCSP
+ responder), caching the results of the periodic updates and including a "stapled response"
+ (referred to as OCSP stapling) in the TLS connection setup with the browser/client.
+
+## OCSP with k6
+
+At the moment k6 supports OCSP stapling, receiving and parsing a stapled response as part of
+the TLS connection setup. The OCSP response information is available on the `ocsp.stapled_response`
+property of the response object.
+
+
+
+```javascript
+import http from "k6/http";
+import { check } from "k6";
+
+export default function() {
+ let res = http.get("https://stackoverflow.com");
+ check(res, {
+ "is OCSP response good": r => r.ocsp.status === http.OCSP_STATUS_GOOD
+ });
+}
+```
+
+
+
+## Properties of an OCSP object
+
+The OCSP `ocsp` object contains the following properties:
+
+| Key | Type | Description |
+| ------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `status` | string | the status of the certificate, see possible values below |
+| `revocation_reason` | string | the reason for revocation of the certificate (if that is the status), see possible values below |
+| `produced_at` | number | number of milliseconds elapsed since 1 January 1970 00:00:00 UTC, representing the time when this OCSP stapled response was signed by CA (or by CA entrusted OCSP responder) |
+| `this_update` | number | number of milliseconds elapsed since 1 January 1970 00:00:00 UTC, representing the time at which the status being indicated was known to be correct |
+| `next_update` | number | number of milliseconds elapsed since 1 January 1970 00:00:00 UTC, representing the time when this OCSP stapled response will be refreshed with CA (or by CA entrusted OCSP responder) |
+| `revoked_at` | number | number of milliseconds elapsed since 1 January 1970 00:00:00 UTC, representing the time when this certificate was revoked (if that is the status) |
+
+### Possible values for `status`:
+
+- `http.OCSP_STATUS_GOOD`
+- `http.OCSP_STATUS_REVOKED`
+- `http.OCSP_STATUS_UNKNOWN`
+- `http.OCSP_STATUS_SERVER_FAILED`
+
+### Possible values for `revocation_reason`:
+
+- `http.OCSP_REASON_UNSPECIFIED`
+- `http.OCSP_REASON_KEY_COMPROMISE`
+- `http.OCSP_REASON_CA_COMPROMISE`
+- `http.OCSP_REASON_AFFILIATION_CHANGED`
+- `http.OCSP_REASON_SUPERSEDED`
+- `http.OCSP_REASON_CESSATION_OF_OPERATION`
+- `http.OCSP_REASON_CERTIFICATE_HOLD`
+- `http.OCSP_REASON_REMOVE_FROM_CRL`
+- `http.OCSP_REASON_PRIVILEGE_WITHDRAWN`
+- `http.OCSP_REASON_AA_COMPROMISE`
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/11 SSL-TLS/SSL-TLS client certificates.md b/src/data/markdown/docs/01 guides/02 Using k6/11 SSL-TLS/SSL-TLS client certificates.md
new file mode 100644
index 0000000000..e17045772d
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/11 SSL-TLS/SSL-TLS client certificates.md
@@ -0,0 +1,91 @@
+---
+title: "SSL/TLS client certificates"
+excerpt: ""
+---
+
+Usually, when we are talking about TLS certificates we are referring to the mechanism by which
+clients authenticate servers. The reverse, servers authenticating clients, is also supported by
+both TLS and k6.
+
+To use client certificates you specify global [configuration options](/using-k6/options) that
+tell k6 how to map a public certificate and private key to the domains they are valid for. You can
+load the certificate and key from local files or embed them as strings in the script.
+
+## Loading a certificate and a key from local files
+
+To load a certificate and a key from local files you use the builtin `open(...)` function:
+
+
+
+
+
+## Loading certificate and key from embedded strings
+
+To load certificate and key from embedded strings (note the use of
+[template literals](https://developer.mozilla.org/en-US/Web/JavaScript/Reference/Template_literals)
+for multi-line strings):
+
+> ### ⚠️ Certificate and key used in the example
+>
+> The partial certificate and key data in the above example were generated for this particular example, they're not real or in-use anywhere.
+
+
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/11 SSL-TLS/SSL-TLS version and ciphers.md b/src/data/markdown/docs/01 guides/02 Using k6/11 SSL-TLS/SSL-TLS version and ciphers.md
new file mode 100644
index 0000000000..e9d604e73e
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/11 SSL-TLS/SSL-TLS version and ciphers.md
@@ -0,0 +1,134 @@
+---
+title: "SSL/TLS version and ciphers"
+excerpt: ""
+---
+
+To support testing specific client configurations k6 allows you to set a specific version or range
+of versions of SSL/TLS that should be allowed for a connection, as well as which cipher suites are
+allowed to be used on that connection.
+
+## Limiting SSL/TLS version
+
+Limiting the SSL/TLS versions that k6 will be allowed to use during a test is a global
+[configuration option](/using-k6/options). You can choose to limit to a specific version:
+
+
+
+
+## Versions available to choose from
+
+Below is the list of available SSL/TLS version that you can choose from. They are listed in
+order from lowest/oldest version to highest/newest version.
+
+* `http.SSL_3_0`
+* `http.TLS_1_0`
+* `http.TLS_1_1`
+* `http.TLS_1_2`
+
+## Limiting cipher suites
+
+Limiting the cipher suites that k6 is allowed to use during a test is a global
+[configuration option](/using-k6/options). You choose a list of allowed ciphers:
+
+
+
+## Checking SSL/TLS version and cipher suite used in request
+
+You can also check which SSL/TLS version and ciphers were used to make a request by looking at the `tls_version` and `tls_cipher_suite` response object properties.
+
+
+
+## Cipher suites available to choose from
+
+Below is a list of available SSL/TLS cipher suites to choose from.
+
+* `TLS_RSA_WITH_RC4_128_SHA`
+* `TLS_RSA_WITH_3DES_EDE_CBC_SHA`
+* `TLS_RSA_WITH_AES_128_CBC_SHA`
+* `TLS_RSA_WITH_AES_256_CBC_SHA`
+* `TLS_RSA_WITH_AES_128_GCM_SHA256`
+* `TLS_RSA_WITH_AES_256_GCM_SHA384`
+* `TLS_ECDHE_ECDSA_WITH_RC4_128_SHA`
+* `TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA`
+* `TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA`
+* `TLS_ECDHE_RSA_WITH_RC4_128_SHA`
+* `TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA`
+* `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA`
+* `TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA`
+* `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`
+* `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`
+* `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`
+* `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`
+
+> ### ⚠️ Differences depending on k6 build
+>
+> Note that there could be differences from the above list of available cipher suites depending on which k6 build your running.
+>
+> The list above will reflect the available cipher suites in the latest official build. If you are using a custom-built k6 then the cipher suites available will be dependent on the Go version you compiled it with, see [https://golang.org/pkg/crypto/tls/#pkg-constants](https://golang.org/pkg/crypto/tls/#pkg-constants).
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/12 HTML.md b/src/data/markdown/docs/01 guides/02 Using k6/12 HTML.md
new file mode 100644
index 0000000000..eafc9445d3
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/12 HTML.md
@@ -0,0 +1,14 @@
+---
+title: 'HTML'
+excerpt: ''
+---
+
+When testing web sites it's common that you have to interact with HTML to submit forms, extract
+data, check for existence of elements or text etc.
+
+For that reason k6 has the [Selection](/javascript-api/k6-html/selection) API. It contains more or less all
+of the [jQuery API](http://api.jquery.com/) that makes sense in the context of k6.
+
+There are also some higher level APIs to do specific things in a more compact way:
+
+- [Working with HTML forms](/using-k6/html/working-with-html-forms)
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/12 HTML/Working with HTML forms.md b/src/data/markdown/docs/01 guides/02 Using k6/12 HTML/Working with HTML forms.md
new file mode 100644
index 0000000000..f0db6e50a7
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/12 HTML/Working with HTML forms.md
@@ -0,0 +1,31 @@
+---
+title: "Working with HTML forms"
+excerpt: ""
+---
+A common use case when testing web sites is to fill in and submit forms.
+
+In many cases using the [Selection](/javascript-api/k6-html/selection) API (jQuery API clone) to interact with HTML data is enough, but for some use cases, like with forms, we can make things easier and the code more compact by wrapping the [Selection](/javascript-api/k6-html/selection) API plus some additional logic to get a higher-level API.
+
+That's what we've done with the [Response.submitForm( [params] )](/javascript-api/k6-http/response/response-submitform-params) API.
+
+
+
+```javascript
+import http from "k6/http";
+
+export default function() {
+ // Request page containing a form
+ let res = http.get("https://httpbin.org/forms/post");
+
+ // Now, submit form setting/overriding some fields of the form
+ res = res.submitForm({
+ fields: {
+ custname: "test",
+ extradata: "test2"
+ },
+ submitSelector: "mySubmit"
+ });
+}
+```
+
+
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/13 Multipart requests -file uploads-.md b/src/data/markdown/docs/01 guides/02 Using k6/13 Multipart requests -file uploads-.md
new file mode 100644
index 0000000000..4e2b494709
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/13 Multipart requests -file uploads-.md
@@ -0,0 +1,85 @@
+---
+title: "Multipart requests (file uploads)"
+excerpt: ""
+---
+Uploading files is a common use case for many applications, so a tool like k6 needs to support
+testing such functionality.
+
+## The open() function
+
+There is a builtin function, [`open()`](/javascript-api/init-context/open-filepath-mode),
+that given a file or a URL will return its contents.
+
+Below is a simple example showing how to load the contents of a local file `data.json`.
+
+
+
+## Creating a multipart request (uploading a file)
+
+Now that you know how to load a local file, let's look at a script that creates a POST request
+to upload this data to an API endpoint along with a regular text field (`field` in the example
+below):
+
+
+
+```js
+import http from "k6/http";
+import { sleep } from "k6";
+
+let binFile = open("/path/to/file.bin", "b");
+
+export default function() {
+ var data = {
+ field: "this is a standard form field",
+ file: http.file(binFile, "test.bin")
+ };
+
+ var res = http.post("https://example.com/upload", data);
+ sleep(3);
+}
+```
+
+
+
+In the example above we use the [http.file()](/javascript-api/k6-http/file-data-filename-contenttype)
+API to wrap the file contents in a [FileData](/javascript-api/k6-http/filedata-k6-http) object.
+When passing a JS object as the body parameter to [http.post()](/javascript-api/k6-http/post-url-body-params),
+or any of the other HTTP request functions, where one of the property values is a
+[FileData](/javascript-api/k6-http/filedata-k6-http) a multipart request will be constructed
+and sent.
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/14 Execution context variables.md b/src/data/markdown/docs/01 guides/02 Using k6/14 Execution context variables.md
new file mode 100644
index 0000000000..de5b3a5794
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/14 Execution context variables.md
@@ -0,0 +1,98 @@
+---
+title: "Execution context variables"
+excerpt: ""
+---
+
+[The "Running k6" tutorial](/getting-started/running-k6) describes how k6 runs a test script for a specified
+number of Virtual Users (VUs) and duration of time or a fixed number of iterations
+for each VU.
+
+When the `duration` option is specified, k6 will continuously run the test script for each VU
+until the `duration` amount of time has elapsed.
+
+
+
+## __VU and __ITER
+
+There are a couple of global variables with execution context information that k6 makes available
+to the load script, namely **__VU** and **__ITER**.
+
+### __ITER
+A numeric counter with the current iteration number for a specific VU. Zero-based.
+
+### __VU
+Current VU number. The value is assigned incrementally for each new VU instance. One-based.
+However, VU number is 0 while executing the setup and teardown functions.
+
+> ### ⚠️ Additional context information available in the k6 Cloud
+>
+> If you are running a test in [k6 Cloud](/cloud) you will have additional
+> [environment variables](/using-k6/environment-variables) that will tell you on which server, load zone
+> and distribution of the test you are currently executing. You can read more about them
+> [here](/using-k6/environment-variables)
+
+
+## k6 Test Coordinator
+
+k6 Virtual Users are concurrent, they will continuously execute through their script until the
+test is over or they hit their iteration limit (if you set one as described above). When you ramp
+up more Virtual Users, k6 will start new ones at that time. When you ramp down, k6 will stop them
+after the completion of the iteration.
+
+## Examples
+
+
+
+Different test behaviors and parameterizations can be accomplished by making use of the
+execution context variables. A typical use case would be a load test simulating different users
+performing a login flow.
+
+
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/15 Test life cycle.md b/src/data/markdown/docs/01 guides/02 Using k6/15 Test life cycle.md
new file mode 100644
index 0000000000..3768c9da53
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/15 Test life cycle.md
@@ -0,0 +1,190 @@
+---
+title: "Test life cycle"
+excerpt: ""
+---
+
+There are four distinct life cycle stages to a k6 test that can be controlled by you, the user.
+They are the "init", "setup", "vu" and "teardown" stages. We also refer to it as "init code",
+"VU code" etc. in the documentation.
+
+
+
+## Init and VU stages
+
+Scripts must contain, at the very least, a `default` function - this defines the entry point
+for your VUs, similar to the `main()` function in many other languages:
+
+
+
+```js
+export default function() {
+ // do things here...
+}
+```
+
+
+_"Why not just run my script normally, from top to bottom"_, you might ask - the answer is: we
+do, but code **inside** and **outside** your `default` function can do different things.
+
+Code inside `default` is called "VU code", and is run over and over for as long as the test is
+running. Code outside of it is called "init code", and is run only once per VU.
+
+VU code can make HTTP requests, emit metrics, and generally do everything you'd expect a load
+test to do - with a few important exceptions: you can't load anything from your local filesystem,
+or import any other modules. This all has to be done from the init code.
+
+There are two reasons for this. The first is, of course: performance.
+
+If you read a file from disk on every single script iteration, it'd be needlessly slow; even
+if you cache the contents of the file and any imported modules, it'd mean the _first run_ of the
+script would be much slower than all the others. Worse yet, if you have a script that imports
+or loads things based on things that can only be known at runtime, you'd get slow iterations
+thrown in every time you load something new.
+
+But there's another, more interesting reason. By forcing all imports and file reads into the
+init context, we make an important design goal possible; we want to support three different
+execution modes without the need for you to modify your scripts; local, cloud and clustered
+execution. In the case of cloud and clustered execution we know which files will be needed, so
+we distribute only those files. We know which modules will be imported, so we can bundle them
+up from the get-go. And, tying into the performance point above, the other nodes don't even
+need writable filesystems - everything can be kept in-memory.
+
+## The default function life-cycle
+
+A VU will execute the default function from start to end in sequence. Nothing out of the ordinary
+so far, but here's the important part; once the VU reaches the end of the default function it will
+loop back to the start and execute the code all over.
+
+As part of this "restart" process, the VU is reset. Cookies are cleared and TCP connections
+might be torn down, depending on your test configuration options.
+
+> Make sure to use `sleep()` statements to pace your VUs properly. An appropriate amount of
+> sleep/think time at the end of the default function is often needed to properly simulate a
+> user reading content on a page. If you don't have a `sleep()` statement at the end of
+> the default function your VU might be more "aggressive" than you've planned.
+>
+> VU without any `sleep()` is akin to a user who constantly presses F5 to refresh the page.
+
+
+## Setup and teardown stages
+
+Beyond the required init and VU stages, which is code run for each VU, k6 also supports test-wide
+setup and teardown stages, like many other testing frameworks and tools. The `setup` and
+`teardown` functions, like the `default` function, needs to be exported functions. But unlike
+the `default` function `setup` and `teardown` are only called once for a test. `setup` is called
+at the beginning of the test, after the init stage but before the VU stage (`default` function),
+and `teardown` is called at the end of a test, after the VU stage (`default` function). Therefore,
+VU number is 0 while executing the `setup` and `teardown` functions.
+
+Again, let's have a look at the basic structure of a k6 test:
+
+
+
+You might have noticed the function signature of the `default` function and `teardown` function
+takes an argument, which we here refer to as `data`.
+
+This `data` will be whatever is returned in the `setup` function, so a mechanism for passing data
+from the setup stage to the subsequent VU and teardown stages in a way that, again, is compatible
+with our goal of supporting local, cloud and clustered execution modes without requiring script
+changes when switching between them. (it might or might not be the same node that runs the setup
+and teardown stages in the cloud or clustered execution mode).
+
+To support all of those modes, only data (i.e. JSON) can be passed between `setup()` and the
+other stages, any passed functions will be stripped.
+
+Here's an example of doing just that, passing some data from setup to VU and teardown stages:
+
+
+
+A big difference between the init stage and setup/teardown stages is that you have the full k6
+API available in the latter, you can for example make HTTP requests in the setup and teardown
+stages:
+
+
+
+```js
+export function setup() {
+ let res = http.get("https://httpbin.org/get");
+ return { data: res.json() };
+}
+
+export function teardown(data) {
+ console.log(JSON.stringify(data));
+}
+
+export default function(data) {
+ console.log(JSON.stringify(data));
+}
+```
+
+
+
+Note that any requests made in the setup and teardown stages will be counted in the end-of-test
+summary. Those requests will be tagged appropriately with the `::setup` and `::teardown` values
+for the `group` metric tag, so that you can filter them in JSON output or InfluxDB.
+
+## Skip setup and teardown execution
+
+There are two CLI options that can be used to skip the execution of setup and teardown stages.
+
+
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/16 Session recording - HAR support.md b/src/data/markdown/docs/01 guides/02 Using k6/16 Session recording - HAR support.md
new file mode 100644
index 0000000000..a6aea323f5
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/16 Session recording - HAR support.md
@@ -0,0 +1,171 @@
+---
+title: "Session recording / HAR support"
+excerpt: ""
+---
+
+In terms of load testing, recording usually refers to the process of creating a load test from the recording of a user session. The process looks like:
+
+1. Record a user or API session
+2. Convert the recorded session into a test
+3. Run the test.
+
+While not exclusive, it is common to use the recording when testing complex scenarios of websites or mobile applications. If you have to create a performance test that simulates a scenario with dozens or hundreds of requests, the recording could help you to be more productive in creating your test.
+
+Recording allows seeing the sequence of requests and parameters of the session instead of having to figure them out. Additionally, you could use the recorded information to auto-generate your test instead of building it from scratch.
+
+k6 does not have built-in functionality to record user or API sessions, but it allows to auto-generate a k6 script via an [HAR file](https://en.wikipedia.org/wiki/HAR_(file_format)); HAR is a file format used by all the browsers and various tools to export the recorded HTTP requests.
+
+In k6, the process looks like:
+
+1. Record a HAR file using your browser or tool of choice.
+2. Use **k6 convert** command to convert the HAR file into a k6 test.
+3. Update the auto-generated k6 test.
+4. Use **k6 run** to run the test.
+
+## 1. Record a HAR file
+
+There are many browsers and tools that can be used to export HTTP traffic in a HAR format. A few popular ones are:
+
+ * [Chrome](https://www.google.com/chrome/)
+ * [Firefox](https://www.mozilla.org/en-US/firefox/)
+ * [Microsoft Edge](https://www.microsoft.com/en-us/windows/microsoft-edge)
+ * [Charles recording proxy ](http://www.charlesproxy.com/)(HTTP proxy/recorder)
+ * [Fiddler](http://www.telerik.com/fiddler) (HTTP proxy/recorder)
+
+Here are the basic steps you need to take to make a recording in Chrome:
+
+1. Open a new incognito window in Chrome (not really necessary, but using an incognito window means you won't be sending a lot of cookies, etc that might have been saved by your browser).
+2. Open up Chrome developer tools (press F12)
+3. Click the "Network" tab
+4. Check out that the recording button (round button) is activated (red color).
+5. Click the "Preserve log" checkbox if you want to make a recording of several successive page loads.
+6. Enter the URL of your site and start doing whatever you'd like your simulated load test users to be doing.
+7. When done, right-click on the list of URLs in Chrome developer tools and choose "Save as HAR with content".
+
+
+
+It's good to have in consideration the following best practices to record a user session:
+
+## Do
+
+- Browse like a user would
+- Take natural pauses that users would take to consume page content
+- Focus on the most common use cases, rather than all the possible use cases
+- Take note of pages where forms/logins occur, you will likely need to complete some scripting there
+
+## Do NOT
+
+- Visit every page in one journey
+- Click every possible option
+- Navigate as fast as you can
+- Navigate away your actual site or application
+
+## 2. Convert the HAR file to a k6 script
+
+The first step is to install k6. If you have not installed yet, please, follow the [k6 installation instructions](/getting-started/installation).
+
+k6 has a built-in HAR converter that will read HAR files and convert them to k6 scripts that can then be executed:
+
+```bash
+k6 convert -O loadtest.js myfile.har
+```
+
+The above command will auto-generate a k6 script for you. k6 will read the HAR file (*myfile.har*) and convert it into a k6 test (*loadtest.js*).
+
+The auto-generation of the test is a great option to add to your toolbox. It’s common practice for advanced user flows that generate many sophisticated HTTP requests, or for helping testers to identify the format of the requests.
+
+The recording avoids writing advanced tests from scratch, saving you precious time building your performance tests.
+
+## 3. Modify the auto-generated k6 script
+
+In the previous step, the converter did create a k6 script for testing. Now, you should evaluate if you have to change any part of the k6 script. Depending on your use case, you might need to modify some of the following aspects:
+
+* Configure the load options
+* Remove third-party content
+* Correlate dynamic data
+
+### Configure the load options
+
+At this moment, k6 has auto-generated a “functional” test, a test that by default will run with one “Virtual User” for one “Iteration”.
+
+It’s time for you to configure the “load” options of your performance tests. k6 allows configuring in several ways:
+
+1 - As CLI arguments while running the test:
+
+```bash
+k6 run --vus 10 --duration 30s loadtest.js
+```
+
+2 - The options of the script file.
+
+```js
+export let options = {
+ vus: 10,
+ duration: "30s"
+};
+```
+
+To learn more information about how to configure the load options, read the [Adding more VUs guide](/getting-started/running-k6#adding-more-vus) and the [Options guide](/using-k6/options).
+
+### Remove third-party content
+
+If you are recording a user session of a website, by default, you will record all the HTTP requests, including requests from third-party tools used on your website — for example, Analytics tools, Facebook, Twitter, Support Widgets, CDNs and many more.
+
+You should remove these third party requests because:
+
+* These third-party requests will skew the percentiles of your performance results.
+* You may have no ability to impact the performance of the third-party service
+* The load test may violate the terms of service contract that you have with the provider.
+
+There are at least three options to skip third-party requests in your k6 script.
+
+1 - Edit the auto-generate k6 script and remove one by one the requests to third-party services.
+
+
+2 - Use the **--only** and **--skip** options of the **k6 convert** command.
+
+**--only**
+
+*This option allows you to supply a comma-separated list of domains which are the only ones you want to fetch things from within your k6 test. This means that k6 will filter out any requests that go to domains other than these.*
+
+**--skip**
+
+The inverse of **--only**. This option allows you to specify some domains that you want to exclude *from the k6 test, meaning that the generated k6 script will not contain any requests for this domain.*
+
+3 - Download a HAR file with only requests to the selected domains.
+
+In Chrome, you can use the DevTools Network Filter to select only particular domains. The Filter input accepts a Regex to match multiple domains.
+
+ `/k6.io|cloudfront.net/`
+
+
+
+After filtering your selected domains, you can download the HAR file as described in the first step of this tutorial, and the HAR file will only include the requests to the selected domains.
+
+If you don’t know all the domains to filter, it is beneficial to use the query language of the Network Filter. Just input `domain:` in the filter to see all the different domains recorded by the Network Panel.
+
+
+
+### Correlate dynamic data
+
+In a load testing, **correlation** means extracting one or more values from the response of one request and then reusing them in subsequent requests. Often times this could be getting a token or some sort of ID necessary to fulfill a sequence of steps in a user journey
+
+The recorded HAR file may include dynamic data used on your site - `IDs`, `CSRF tokens`, `VIEWSTATE`, `wpnonce`, and other `dynamic values` - that will be converted into the k6 script.
+
+To run your load test correctly, you may need to replace the hardcoded data with dynamic data that k6 gets from previous requests. For example, tokens will expire quickly and it is one of the most common things that users will correlate from a recorded session.
+
+[Here](/examples/correlation-and-dynamic-data) are a few examples using the k6 API to correlate dynamic data.
+
+## 4. Run the test
+
+Now, you can run your load test by executing the command:
+
+```bash
+k6 run loadtest.js
+```
+
+For learning more about running k6, check out the [Running k6 guide](/getting-started/running-k6).
+
+## Recording in the k6 Cloud Service
+
+If you are a user of the k6 Cloud Service, you can directly upload HAR files through the web UI or [use a Chrome extension](/cloud/creating-and-running-a-test/recording-a-test-script) to create a script while recording a browsing session.
\ No newline at end of file
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/17 HTTP debugging.md b/src/data/markdown/docs/01 guides/02 Using k6/17 HTTP debugging.md
new file mode 100644
index 0000000000..96ef4642b8
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/17 HTTP debugging.md
@@ -0,0 +1,91 @@
+---
+title: "HTTP debugging"
+excerpt: ""
+---
+
+It's not always things work as expected. For those cases there's a handy CLI flag, `--http-debug`,
+that is good to be aware of.
+
+## Example
+
+Given the following script:
+
+
+
+If we run it using `k6 run --http-debug script.js` we get output that looks like this:
+
+
+
+```text
+ /\ |‾‾| /‾‾/ /‾/
+ /\ / \ | |_/ / / /
+ / \/ \ | | / ‾‾\
+ / \ | |‾\ \ | (_) |
+ / __________ \ |__| \__\ \___/ .io
+
+ execution: local
+ output: -
+ script: script.js
+
+ duration: -, iterations: 1
+ vus: 1, max: 1
+
+Request: [----------------------------------------------------------] starting
+
+GET / HTTP/1.1
+Host: google.com
+User-Agent: k6/0.20.0 (https://k6.io/);
+Accept-Encoding: gzip
+
+
+RedirectResponse:
+HTTP/2.0 302 Found
+Content-Length: 267
+Alt-Svc: hq=":443"; ma=2592000; quic=51303432; quic=51303431; quic=51303339; quic=51303335,quic=":443"; ma=2592000; v="42,41,39,35"
+Cache-Control: private
+Content-Type: text/html; charset=UTF-8
+Date: Thu, 22 Mar 2018 13:39:44 GMT
+Location: https://www.google.se/?gfe_rd=cr&dcr=0&ei=ILKzWqiODOaxX_LBi5AG
+Referrer-Policy: no-referrer
+
+
+RedirectRequest:
+GET /?gfe_rd=cr&dcr=0&ei=ILKzWqiODOaxX_LBi5AG HTTP/1.1
+Host: www.google.se
+User-Agent: k6/0.19.0 (https://k6.io/);
+Referer: https://google.com/
+Accept-Encoding: gzip
+
+
+Response:
+HTTP/2.0 200 OK
+Connection: close
+Accept-Ranges: none
+Alt-Svc: hq=":443"; ma=2592000; quic=51303432; quic=51303431; quic=51303339; quic=51303335,quic=":443"; ma=2592000; v="42,41,39,35"
+Cache-Control: private, max-age=0
+Content-Type: text/html; charset=ISO-8859-1
+Date: Thu, 22 Mar 2018 13:39:44 GMT
+Expires: -1
+P3p: CP="This is not a P3P policy! See g.co/p3phelp for more info."
+Server: gws
+Set-Cookie: 1P_JAR=2018-03-22-13; expires=Sat, 21-Apr-2018 13:39:44 GMT; path=/; domain=.google.se
+Set-Cookie: NID=126=asTcm5s3-jMa1-pquG09m9lpUrowy-OtzZ9cUomBuKeJePbvwJAZe5wCtiyLITj9_RrlWLf6DTQ8ufpdB39MCRV-zUpfXAUw8XUVMWtgdU1gbtnQ9rssin56333g9Hyo; expires=Fri, 21-Sep-2018 13:39:44 GMT; path=/; domain=.google.se; HttpOnly
+Vary: Accept-Encoding
+X-Frame-Options: SAMEORIGIN
+X-Xss-Protection: 1; mode=block
+
+...
+
+```
+
+If we want to get the full response body printed as well we run the script with `k6 run --http-debug="full" script.js` instead.
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/18 Archives for bundling-sharing a test.md b/src/data/markdown/docs/01 guides/02 Using k6/18 Archives for bundling-sharing a test.md
new file mode 100644
index 0000000000..82d88936cf
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/18 Archives for bundling-sharing a test.md
@@ -0,0 +1,225 @@
+---
+title: "Archives for bundling/sharing a test"
+excerpt: ""
+---
+
+## What is an archive?
+
+When the complexity of a k6 test goes beyond a single JS file it quickly becomes cumbersome to
+find and bundle up all the dependencies (JS, [open()](/javascript-api/init-context/open-filepath-mode)'ed data files, TLS
+client certs, etc.). There is a need for a native way to bundle and distribute/share a test. That
+is what k6 archives are for.
+
+A k6 archive is simply a [tar](https://en.wikipedia.org/wiki/Tar_%28computing%29) file with all
+files needed to execute a k6 test.
+
+## How to create and run an archive
+
+Let's say that you normally execute a test using:
+
+
+
+```shell
+$ k6 run script.js
+```
+
+
+
+Now if you replace `run` with `archive` k6 will run the [init stage](/using-k6/test-life-cycle) of
+the code to determine which JS files are being imported and what data files are being
+[`open()`](/javascript-api/init-context/open-filepath-mode)'ed and bundles all of the files up
+into a tar file:
+
+
+
+```shell
+$ k6 archive script.js
+```
+
+
+
+This would produce a tar file on disk called `archive.tar` (you can change that by setting
+`-O filename.tar`). It's also easy to run an archive, as `k6 run` is compatible with archive
+files you can execute:
+
+> ### ⚠️ Overriding options
+>
+> As always you can override options using CLI flags or environment variables when
+> running an archive.
+
+
+
+```shell
+$ k6 run archive.tar
+```
+
+
+
+## Use cases
+
+Archive files have a variety of use cases, but they all share the common need to bundle
+of a test's files into a single file for easy distribution.
+
+### Sharing a test
+By bundling up a test into an archive it's easy to share the test with your teammates by
+simply storing or sending a single tar file. As we saw in the previous section, your teammates
+can execute the archive by running `k6 run archive.tar`.
+
+### Preparing tests for CI
+If you have a complex CI pipeline and your load tests are separated from your application
+code, you could store k6 archives as build artifacts whenever the load test source code
+is changed, and then pull in those k6 archives from the artifacts storage for test execution
+as needed.
+
+### k6 Cloud Execution
+k6 offers a commercial service for running large scale and geographically
+distributed load tests on managed cloud infrastructure. Cloud executed tests are triggered
+from the k6 command-line via the `k6 cloud script.js` command (similar to `k6 run`) which will
+trigger an implicit creation of a k6 archive that is uploaded and distributed to k6 cloud
+load generators for execution.
+
+### Clustered Execution (*future*)
+In the future (see [our roadmap](https://github.com/loadimpact/k6/wiki/Roadmap)) k6 will
+support a clustered execution mode that will enable tests to be run across more than one
+node. This mode of execution is also likely to make use of the archive functionality to
+distribute the test files to all participating nodes.
+
+## Contents of an archive file
+
+An archive contains the original source of the JS code, any [`open()`](/javascript-api/init-context/open-filepath-mode)'ed
+data files, [SSL/TLS client certificates](/using-k6/ssl-tls/ssl-tls-client-certificates) as well as a
+`metadata.json` with all the options (a cascading of the options set on the [CLI](/using-k6/options),
+via [Environment variables](/using-k6/options) and [in-script options](/using-k6/options)
+(`export let options = {...}`)).
+
+Let's create an archive from the following sample test. Here is the layout in the filesystem
+of the files:
+
+
+
+Now, if the current working directory is `/home/johndoe/tests/api-test/` and we run
+`k6 archive script.js` we'd get a tar file called `archive.tar` (you can change the name of the
+file using `-O filename.tar`). The contents of the archive file would look like something like
+this:
+
+
+
+
+```text
+├-- data
+├-- files
+| └-- home
+| └-- nobody <-- the username has been anonymized (see section further down)
+| └-- tests
+| └-- api-test
+| └-- data
+| └-- users.json
+├-- metadata.json
+└-- scripts
+ └-- home
+ └-- nobody <-- the username has been anonymized (see section further down)
+ └-- tests
+ └-- api-test
+ ├-- script.js
+ ├-- utils
+ | └-- common.js
+ ├-- endpoints
+ | ├-- login.js
+ | └-- search.js
+ └-- node_modules
+ └-- somelib
+ └-- lib.js
+```
+
+
+
+Breaking down the file structure we get:
+
+**data** contains the source code of the main JS file (`script.js` in this example).
+
+**files** contains the full original directory tree of all [`open()`](/javascript-api/init-context/open-filepath-mode)'ed data files.
+
+**metadata.json** The resolved "default" options for this test based on [CLI flags](/using-k6/options),
+[Environment variables](/using-k6/options) and [in-script options](/using-k6/options).
+
+***scripts*** contains the full original directory tree of all `import`'ed JS dependencies.
+
+
+
+## What an archive file does not contain
+
+We try to be cautious with what we include in an archive file. Some things we do to that end:
+* We anonymize the username found in any path to JS and data file dependencies
+* We don't include and environment variables from the system in the archive
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/19 Cloud execution.md b/src/data/markdown/docs/01 guides/02 Using k6/19 Cloud execution.md
new file mode 100644
index 0000000000..37791788bf
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/19 Cloud execution.md
@@ -0,0 +1,273 @@
+---
+title: 'Cloud execution'
+excerpt: ''
+---
+
+One of the goals with k6 is to support three execution modes to run your k6 tests:
+
+- **Local**: on your local machine or a CI server.
+- **Cloud**: on cloud infrastructure managed by k6 (triggered
+ from local command-line, CI or cloud UI).
+- **Clustered**: on more than one machine managed by you.
+
+k6 aims to support moving a script between the three execution modes
+without having to make modifications to the script.
+
+Currently, k6 supports the local execution mode. The second execution
+mode, cloud execution, is available by starting a trial of the Load
+Impact cloud service. See the "Getting Started" steps below.
+
+## Getting started
+
+1. First, you need to create a k6 Cloud account, [register here](https://app.k6.io/account/register).
+
+2. Then you need to start a trial of our cloud service, [start trial here](https://app.k6.io/start-trial?utm_source=k6%20docs%20cloud%20exec&utm_medium=CTA&utm_campaign=Start%20Trial%20Insights).
+
+3. After that you need to download [the latest release of k6](https://github.com/loadimpact/k6/releases).
+
+4. k6 needs a k6 Cloud API token to be able to communicate with the cloud. Log in to k6 Cloud from the CLI to save your token in a local config file:
+
+
+
+ ```shell
+ k6 login cloud
+ ```
+
+
+
+ Alternatively, you could also get your token from the [API token
+ page](https://app.k6.io/account/api-token) and set the
+ environment variable `K6_CLOUD_TOKEN` or use `k6 login cloud --token YOUR_TOKEN`.
+
+5. Instruct k6 to run your test in the cloud.
+
+
+
+ ```shell
+ k6 cloud script.js
+ ```
+
+ ```shell
+ docker run -i -e K6_CLOUD_TOKEN= loadimpact/k6 cloud -
+
+ > ### Docker usage
+ >
+ > Note the difference in specifying the `K6_CLOUD_TOKEN` environment variable using
+ > the `docker run -e` option.
+ >
+ > Also, when passing the script via stdin as shown in the example there is no way
+ > for the containerized k6 process to get the script filename, which is required
+ > for cloud execution. To fix this you can either mount the local filesystem as
+ > a Docker volume
+ >
+ >
+
+6. You'll see k6 print some information and the URL of your test results.
+
+ 
+
+7. Navigate to the URL to check your test results. During the initialization phase of a cloud test you'll see a screen like the following:
+
+ 
+
+ When the test is running, the result page for k6 tests
+ ("Insights") will be shown. The [k6 Cloud Results
+ docs](/cloud/analyzing-results/overview)
+ provides more documentation about the different test result
+ sections.
+
+ 
+
+## Cloud execution options
+
+You can optionally define some cloud options in your k6 script.
+
+
+
+| Name | Default | Description |
+| --------------------- | ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| name (string) | Optional. The name of the main script file, so something like "script.js". | The name of the test in the k6 Cloud UI. Test runs with the same name will be grouped together. |
+| distribution (object) | Optional. The equivalent of `someDefaultLabel: { loadZone: "amazon:us:ashburn", percent: 100 }`. | How the traffic should be distributed. The keys are string labels that will be injected as [environment variables](/using-k6/environment-variables) on the appropriate nodes (matching the `loadZone`): `__ENV["someDefaultLabel"]` |
+
+### List of supported load zones
+
+| Location | ID |
+| --------------------- | --------------------- |
+| Tokyo | `amazon:jp:tokyo` |
+| Seoul | `amazon:kr:seoul` |
+| Mumbai | `amazon:in:mumbai` |
+| Singapore | `amazon:sg:singapore` |
+| Sydney | `amazon:au:sydney` |
+| Montreal | `amazon:ca:montreal` |
+| Frankfurt | `amazon:de:frankfurt` |
+| Ireland | `amazon:ie:dublin` |
+| London | `amazon:gb:london` |
+| Paris | `amazon:fr:paris` |
+| Stockholm | `amazon:se:stockholm` |
+| N. Virginia (Default) | `amazon:us:ashburn` |
+| Ohio | `amazon:us:columbus` |
+| N. California | `amazon:us:palo alto` |
+| Oregon | `amazon:us:portland` |
+| Hong Kong | `amazon:cn:hong kong` |
+
+### Run options
+
+
+
+```shell
+k6 cloud -h
+```
+
+
+
+All the options, like `--vus` and `--duration` are the same between
+the `k6 run` and `k6 cloud` commands. Check out the [Options
+page](/using-k6/options) for more information about the different options.
+
+## Cloud execution tags
+
+[Tags](/using-k6/tags-and-groups) is a powerful concept in k6 as it opens up for great flexibility in how you can slice and dice the result data.
+
+When running a k6 test in the cloud we add two tags to all metrics:
+
+| Tag name | Type | Description |
+| ------------- | ------ | -------------------------------------------------------------------------------------------------------- |
+| `load_zone` | string | The load zone from where the the metric was collected. Values will be of the form: `amazon:us :ashburn`. |
+| `instance_id` | int | A unique number representing the ID of a load generator server taking part in the test. |
+
+
+
+## Using setup/teardown life-cycle functions
+
+Your [setup and teardown life cycle functions](/using-k6/test-life-cycle)
+are executed as normal when running cloud tests. Depending on the size
+of your test, it will execute from one or more cloud servers, but the
+setup and teardown will only execute from one server, so execute once
+each test-wide. There's no guarantee though that the same cloud server
+that executed the `setup()` will execute the `teardown()`.
+
+## Using environment variables
+
+To use [environment variables](/using-k6/environment-variables) when running
+a cloud executed test you use one or more `-e KEY=VALUE` (or `--env KEY=VALUE`) CLI flags.
+
+> ### Use the CLI flags to set environment variables
+>
+> With cloud execution you must use the CLI flags (`-e`/`--env`) to
+> set environment variables. Environment variables set in the local
+> terminal before executing k6 won't be forwarded to the k6
+> cloud service, and thus won't be available to your script when
+> executing in the cloud."
+
+Given the script below, which reads the `MY_HOSTNAME` environment
+variable, you'd execute it using the command line `k6 run -e MY_HOSTNAME=test.k6.io script.js`.
+
+
+
+```javascript
+import { check, sleep } from 'k6';
+import http from 'k6/http';
+
+export default function() {
+ var r = http.get(`http://${__ENV.MY_HOSTNAME}/`);
+ check(r, {
+ 'status is 200': r => r.status === 200,
+ });
+ sleep(5);
+}
+```
+
+
+
+When running in the k6 Cloud there will be three additional
+environment variables that can be used to find out in which load zone,
+server instance, and distribution label the given script is currently
+running.
+
+Name| Value| Description
+-|-|-
+`LI_LOAD_ZONE` |string| The load zone from where the the metric was collected. Values will be of the form: amazon:us :ashburn (see list above).
+`LI_INSTANCE_ID` |number| A sequential number representing the unique ID of a load generator server taking part in the test, starts at 0.
+`LI_DISTRIBUTION` |string| The value of the "distribution label" that you used in `ext.loadimpact.distribution` corresponding to the load zone the script is currently executed in.
+
+## Running tests under a different project than your default one
+
+By default tests and test runs will be created and run under your
+default project, in your default organization. To create and run tests
+under a different project, whether under your default organization or
+one you've been invited to, you have two options:
+
+1. You can specify the project ID in the script options:
+
+
+
+2. You can set the `K6_CLOUD_PROJECT_ID` environment variable when running the test.
+
+ You find the ID of a k6 Cloud project by selecting the project in
+ the UI and looking in the URL bar of your browser, the `12345` in
+ `https://app.k6.io/projects/12345` is the project ID.
+
+## Differences between local and cloud execution (in beta)
+
+There's currently one difference between local and cloud execution:
+local execution has support for iterations based test length (`-i` or
+`--iterations` on CLI, and `iterations` in script options) which is
+not yet supported by cloud execution.
+
+## Limits
+
+You're only limited to what your subscription, trial or premium, allows.
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/20 Javascript Compatibility Mode.md b/src/data/markdown/docs/01 guides/02 Using k6/20 Javascript Compatibility Mode.md
new file mode 100644
index 0000000000..d66ae5329c
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/02 Using k6/20 Javascript Compatibility Mode.md
@@ -0,0 +1,191 @@
+---
+title: JavaScript Compatibility Mode
+excerpt: ''
+---
+
+> ### 🎉 This feature is new as of version 0.26.0
+
+k6 supports running test scripts with different ECMAScript compatibility modes using the
+`run --compatibility-mode` CLI option or `K6_COMPATIBILITY_MODE` environment variable.
+
+Currently two modes are available:
+
+## Base
+
+
+
+```shell
+$ k6 run --compatibility-mode=base script.js
+```
+
+```shell
+$ K6_COMPATIBILITY_MODE=base k6 run script.js
+```
+
+
+
+Pure Golang JavaScript VM supporting ES5.1+. Use this mode if your scripts are already written
+using only ES5.1 features, or were previously transformed by [Babel](https://babeljs.io/),
+to reduce startup time, RAM usage and improve performance. See the [k6-es6 project](https://github.com/MStoykov/k6-es6)
+for an example [Webpack](https://webpack.js.org/) setup that does this
+transformation outside of k6.
+
+### Basic Example
+
+
+
+> ### ⚠️ About require()
+>
+> Note that `require()` is a custom k6 implementation of module
+> loading, which doesn't behave in the same way as the
+> [require() call in Node.js](https://nodejs.org/api/modules.html#modules_require_id).
+> Specifically, it only handles loading of built-in k6 modules,
+> scripts on the local filesystem, and remote scripts over HTTP(S),
+> but it does *not* support the
+> [Node.js module resolution algorithm](https://nodejs.org/api/modules.html#modules_all_together).
+
+### Advanced Example
+
+
+
+```shell
+$ k6 run --compatibility-mode=extended script.js
+```
+
+```shell
+$ K6_COMPATIBILITY_MODE=extended k6 run script.js
+```
+
+
+
+Transforms scripts to ES5.1 using Babel with ES2015 preset, and loads
+[core.js](https://github.com/zloirock/core-js) v2 polyfills. This is
+the default mode, providing greater JavaScript compatibility, at the
+expense of startup time, RAM usage and performance.
+
+## Performance Comparison
+
+There's a substantial difference in performance between both modes, as shown by
+[GNU time](https://www.gnu.org/software/time/) below, especially when running tests with a large
+number of VUs:
+
+
+
+```shell
+$ /usr/bin/time -v k6 run \
+ --compatibility-mode=base \
+ --vus 3500 \
+ --duration=60s \
+ script.js
+
+[...]
+User time (seconds): 15.10
+System time (seconds): 10.02
+Percent of CPU this job got: 40%
+Elapsed (wall clock) time (h:mm:ss or m:ss): 1:01.88
+Average shared text size (kbytes): 0
+Average unshared data size (kbytes): 0
+Average stack size (kbytes): 0
+Average total size (kbytes): 0
+Maximum resident set size (kbytes): 903612
+Average resident set size (kbytes): 0
+Major (requiring I/O) page faults: 1
+Minor (reclaiming a frame) page faults: 352090
+Voluntary context switches: 558479
+Involuntary context switches: 4689
+Swaps: 0
+File system inputs: 0
+File system outputs: 78856
+Socket messages sent: 0
+Socket messages received: 0
+Signals delivered: 0
+Page size (bytes): 4096
+Exit status: 0
+```
+
+```shell
+$ /usr/bin/time -v k6 run \
+ --compatibility-mode=extended \
+ --vus 3500 \
+ --duration=60s \
+ script.js
+
+[...]
+User time (seconds): 104.44
+System time (seconds): 6.96
+Percent of CPU this job got: 101%
+Elapsed (wall clock) time (h:mm:ss or m:ss): 1:49.49
+Average shared text size (kbytes): 0
+Average unshared data size (kbytes): 0
+Average stack size (kbytes): 0
+Average total size (kbytes): 0
+Maximum resident set size (kbytes): 7972316
+Average resident set size (kbytes): 0
+Major (requiring I/O) page faults: 1
+Minor (reclaiming a frame) page faults: 2595676
+Voluntary context switches: 535511
+Involuntary context switches: 9306
+Swaps: 0
+File system inputs: 0
+File system outputs: 78856
+Socket messages sent: 0
+Socket messages received: 0
+Signals delivered: 0
+Page size (bytes): 4096
+Exit status: 0
+```
+
+
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/analysis-tab-tags.png b/src/data/markdown/docs/01 guides/02 Using k6/images/analysis-tab-tags.png
new file mode 100644
index 0000000000..27e0bfd1c7
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/analysis-tab-tags.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/cli-screen.png b/src/data/markdown/docs/01 guides/02 Using k6/images/cli-screen.png
new file mode 100644
index 0000000000..3f251fd69c
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/cli-screen.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-exec-init.png b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-exec-init.png
new file mode 100644
index 0000000000..f4755b4fdf
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-exec-init.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-exec-output.png b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-exec-output.png
new file mode 100644
index 0000000000..5a90be470d
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-exec-output.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-exec-tags.png b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-exec-tags.png
new file mode 100644
index 0000000000..81138bb3b8
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-exec-tags.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-exec-test-init.png b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-exec-test-init.png
new file mode 100644
index 0000000000..12481bd216
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-exec-test-init.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-insights-analysis-tab.png b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-insights-analysis-tab.png
new file mode 100644
index 0000000000..cffcd544a6
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-insights-analysis-tab.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-insights-checks-tab.png b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-insights-checks-tab.png
new file mode 100644
index 0000000000..93b19381fb
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-insights-checks-tab.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-insights-http-tab.png b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-insights-http-tab.png
new file mode 100644
index 0000000000..a1204624fb
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-insights-http-tab.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-insights-metrics-analysis.png b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-insights-metrics-analysis.png
new file mode 100644
index 0000000000..44bb7e48b8
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-insights-metrics-analysis.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-insights-results.png b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-insights-results.png
new file mode 100644
index 0000000000..740c46c54e
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-insights-results.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-insights-thresholds-tab.png b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-insights-thresholds-tab.png
new file mode 100644
index 0000000000..3a634403c8
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-insights-thresholds-tab.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-insights-url-table.png b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-insights-url-table.png
new file mode 100644
index 0000000000..b6d9215e8e
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-insights-url-table.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-threshold-graph.png b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-threshold-graph.png
new file mode 100644
index 0000000000..8cb19a7b64
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/cloud-threshold-graph.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/executing-with-a-threshold.png b/src/data/markdown/docs/01 guides/02 Using k6/images/executing-with-a-threshold.png
new file mode 100644
index 0000000000..2f9aba3e87
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/executing-with-a-threshold.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/filter-tags.gif b/src/data/markdown/docs/01 guides/02 Using k6/images/filter-tags.gif
new file mode 100644
index 0000000000..f1ab05d685
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/filter-tags.gif differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/insights-breakdown-row-status.png b/src/data/markdown/docs/01 guides/02 Using k6/images/insights-breakdown-row-status.png
new file mode 100644
index 0000000000..36f215bc44
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/insights-breakdown-row-status.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/insights-breakdown-structure-full.png b/src/data/markdown/docs/01 guides/02 Using k6/images/insights-breakdown-structure-full.png
new file mode 100644
index 0000000000..94b86ab6d3
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/insights-breakdown-structure-full.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/insights-results.png b/src/data/markdown/docs/01 guides/02 Using k6/images/insights-results.png
new file mode 100644
index 0000000000..e5113330d6
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/insights-results.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/onboarding-screen.png b/src/data/markdown/docs/01 guides/02 Using k6/images/onboarding-screen.png
new file mode 100644
index 0000000000..f13db53e35
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/onboarding-screen.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/output-to-stdout.png b/src/data/markdown/docs/01 guides/02 Using k6/images/output-to-stdout.png
new file mode 100644
index 0000000000..ac6964b736
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/output-to-stdout.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/running-k6-in-docker-on-windows.png b/src/data/markdown/docs/01 guides/02 Using k6/images/running-k6-in-docker-on-windows.png
new file mode 100644
index 0000000000..d327023a28
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/running-k6-in-docker-on-windows.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/save-as-har.png b/src/data/markdown/docs/01 guides/02 Using k6/images/save-as-har.png
new file mode 100644
index 0000000000..c2d5e2e393
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/save-as-har.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/session_recorder_filter_domain.png b/src/data/markdown/docs/01 guides/02 Using k6/images/session_recorder_filter_domain.png
new file mode 100644
index 0000000000..8a91e8762d
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/session_recorder_filter_domain.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/session_recorder_filter_domain_list.png b/src/data/markdown/docs/01 guides/02 Using k6/images/session_recorder_filter_domain_list.png
new file mode 100644
index 0000000000..6ce3fcde4a
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/session_recorder_filter_domain_list.png differ
diff --git a/src/data/markdown/docs/01 guides/02 Using k6/images/session_recorder_save_as_har.png b/src/data/markdown/docs/01 guides/02 Using k6/images/session_recorder_save_as_har.png
new file mode 100644
index 0000000000..c2d5e2e393
Binary files /dev/null and b/src/data/markdown/docs/01 guides/02 Using k6/images/session_recorder_save_as_har.png differ
diff --git a/src/data/markdown/docs/01 guides/03 Results visualization/InfluxDB - Grafana.md b/src/data/markdown/docs/01 guides/03 Results visualization/InfluxDB - Grafana.md
new file mode 100644
index 0000000000..a9597f4962
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/03 Results visualization/InfluxDB - Grafana.md
@@ -0,0 +1,121 @@
+---
+title: 'InfluxDB + Grafana'
+excerpt: ''
+---
+
+Want some graphs? It's simpler than you think, using InfluxDB for data storage and Grafana
+for visualization.
+
+
+
+## Installing InfluxDB and Grafana
+
+### InfluxDB
+
+Full installation instructions are available in [the InfluxDB docs](https://docs.influxdata.com/influxdb/v1.2/introduction/installation/).
+
+
+
+_After this, you should have an InfluxDB server running on localhost, listening on port 8086,
+and a Grafana server on `http://localhost:3000_`
+
+## Using InfluxDB to store results
+
+k6 has built-in support for outputting results data directly to an InfluxDB database using
+the `--out` (`-o`) switch:
+
+
+
+```shell
+$ k6 run --out influxdb=http://localhost:8086/myk6db script.js
+```
+
+```shell
+$ docker run -i loadimpact/k6 run --out influxdb=http://localhost:8086/myk6db -
+
+The above command line makes k6 connect to a local influxdb instance, and send the results from
+the test to a database named `myk6db`. If this database does not exist, k6 will create it
+automatically.
+
+Once you have k6 results in your InfluxDB database, you can then use Grafana to
+create results visualizations.
+
+## Using Grafana to visualize results
+
+- Open `http://localhost:3000` (or wherever your Grafana installation is located) in your browser.
+- Create a data source:
+ 
+- Now create a dashboard. Here is the newly created dashboard:
+ 
+- Click `Graph` to create a new graph panel:
+ 
+- Click the `Panel title` and then `Edit` to set up the graph panel:
+ 
+- Set the panel data source to your `myk6db` database and click the `SELECT mean(value)...`
+ statement to edit the metric:
+ 
+
+## Using our docker-compose setup
+
+To make all the above even simpler, we have created a docker-compose setup that will:
+
+- Start a Docker container with InfluxDB
+- Start a Docker container with Grafana
+- Make available a k6 container that you can use to run load tests
+
+Make sure you have at least docker-compose version v1.12.0 installed.
+You just need to do the following:
+
+```shell
+$ git clone 'https://github.com/loadimpact/k6'
+$ cd k6
+$ git submodule update --init
+$ docker-compose up -d \
+ influxdb \
+ grafana
+$ docker-compose run -v \
+ $PWD/samples:/scripts \
+ k6 run /scripts/es6sample.js
+```
+
+Now you should be able to connect to localhost on port 3000 with your browser and access the
+Grafana installation in the Docker container.
+
+## Preconfigured Grafana dashboards
+
+Here we will list premade Grafana dashboard configurations contributed by users, for use
+with k6. To enable a contributed Grafana dashboard is simple: you just choose to "import"
+a dashboard in the Grafana UI and then specify the ID number of the dashboard you want,
+see http://docs.grafana.org/reference/export_import/ for more details.
+
+
+_https://grafana.com/dashboards/2587_
diff --git a/src/data/markdown/docs/01 guides/03 Results visualization/images/cli-get-started.png b/src/data/markdown/docs/01 guides/03 Results visualization/images/cli-get-started.png
new file mode 100644
index 0000000000..eb89f90138
Binary files /dev/null and b/src/data/markdown/docs/01 guides/03 Results visualization/images/cli-get-started.png differ
diff --git a/src/data/markdown/docs/01 guides/03 Results visualization/images/cli-instructions.png b/src/data/markdown/docs/01 guides/03 Results visualization/images/cli-instructions.png
new file mode 100644
index 0000000000..50552ba5ca
Binary files /dev/null and b/src/data/markdown/docs/01 guides/03 Results visualization/images/cli-instructions.png differ
diff --git a/src/data/markdown/docs/01 guides/03 Results visualization/images/cli-screen.png b/src/data/markdown/docs/01 guides/03 Results visualization/images/cli-screen.png
new file mode 100644
index 0000000000..3f251fd69c
Binary files /dev/null and b/src/data/markdown/docs/01 guides/03 Results visualization/images/cli-screen.png differ
diff --git a/src/data/markdown/docs/01 guides/03 Results visualization/images/grafana-configure-graph-panel.png b/src/data/markdown/docs/01 guides/03 Results visualization/images/grafana-configure-graph-panel.png
new file mode 100644
index 0000000000..47345faefd
Binary files /dev/null and b/src/data/markdown/docs/01 guides/03 Results visualization/images/grafana-configure-graph-panel.png differ
diff --git a/src/data/markdown/docs/01 guides/03 Results visualization/images/grafana-create-data-source.png b/src/data/markdown/docs/01 guides/03 Results visualization/images/grafana-create-data-source.png
new file mode 100644
index 0000000000..7e4c784994
Binary files /dev/null and b/src/data/markdown/docs/01 guides/03 Results visualization/images/grafana-create-data-source.png differ
diff --git a/src/data/markdown/docs/01 guides/03 Results visualization/images/grafana-dave.png b/src/data/markdown/docs/01 guides/03 Results visualization/images/grafana-dave.png
new file mode 100644
index 0000000000..22f61b79e4
Binary files /dev/null and b/src/data/markdown/docs/01 guides/03 Results visualization/images/grafana-dave.png differ
diff --git a/src/data/markdown/docs/01 guides/03 Results visualization/images/grafana-edit-metric.png b/src/data/markdown/docs/01 guides/03 Results visualization/images/grafana-edit-metric.png
new file mode 100644
index 0000000000..c09e0ca532
Binary files /dev/null and b/src/data/markdown/docs/01 guides/03 Results visualization/images/grafana-edit-metric.png differ
diff --git a/src/data/markdown/docs/01 guides/03 Results visualization/images/grafana-new-dashboard.png b/src/data/markdown/docs/01 guides/03 Results visualization/images/grafana-new-dashboard.png
new file mode 100644
index 0000000000..f94c32b4ae
Binary files /dev/null and b/src/data/markdown/docs/01 guides/03 Results visualization/images/grafana-new-dashboard.png differ
diff --git a/src/data/markdown/docs/01 guides/03 Results visualization/images/grafana-new-graph-panel.png b/src/data/markdown/docs/01 guides/03 Results visualization/images/grafana-new-graph-panel.png
new file mode 100644
index 0000000000..61d3b3d047
Binary files /dev/null and b/src/data/markdown/docs/01 guides/03 Results visualization/images/grafana-new-graph-panel.png differ
diff --git a/src/data/markdown/docs/01 guides/03 Results visualization/images/grafana-visualization.png b/src/data/markdown/docs/01 guides/03 Results visualization/images/grafana-visualization.png
new file mode 100644
index 0000000000..f0d1492687
Binary files /dev/null and b/src/data/markdown/docs/01 guides/03 Results visualization/images/grafana-visualization.png differ
diff --git a/src/data/markdown/docs/01 guides/03 Results visualization/images/k6-cloud-output.png b/src/data/markdown/docs/01 guides/03 Results visualization/images/k6-cloud-output.png
new file mode 100644
index 0000000000..ff94ef3490
Binary files /dev/null and b/src/data/markdown/docs/01 guides/03 Results visualization/images/k6-cloud-output.png differ
diff --git a/src/data/markdown/docs/01 guides/03 Results visualization/images/k6-cloud-results.png b/src/data/markdown/docs/01 guides/03 Results visualization/images/k6-cloud-results.png
new file mode 100644
index 0000000000..56ef0c565f
Binary files /dev/null and b/src/data/markdown/docs/01 guides/03 Results visualization/images/k6-cloud-results.png differ
diff --git a/src/data/markdown/docs/01 guides/03 Results visualization/images/onboarding-screen.png b/src/data/markdown/docs/01 guides/03 Results visualization/images/onboarding-screen.png
new file mode 100644
index 0000000000..f13db53e35
Binary files /dev/null and b/src/data/markdown/docs/01 guides/03 Results visualization/images/onboarding-screen.png differ
diff --git a/src/data/markdown/docs/01 guides/03 Results visualization/images/test-results-new-result-screen.png b/src/data/markdown/docs/01 guides/03 Results visualization/images/test-results-new-result-screen.png
new file mode 100644
index 0000000000..8504c7724d
Binary files /dev/null and b/src/data/markdown/docs/01 guides/03 Results visualization/images/test-results-new-result-screen.png differ
diff --git a/src/data/markdown/docs/01 guides/03 Results visualization/k6 Cloud Test Results.md b/src/data/markdown/docs/01 guides/03 Results visualization/k6 Cloud Test Results.md
new file mode 100644
index 0000000000..f7f13fb3da
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/03 Results visualization/k6 Cloud Test Results.md
@@ -0,0 +1,136 @@
+---
+title: "k6 Cloud Test Results"
+excerpt: ""
+---
+
+## Insights introduction
+
+We offer a SaaS solution for k6 results storage, analysis and trending. It is
+called _[k6 Cloud Test Results](https://k6.io/cloud/)_. Test Results allows you to run
+your load tests locally using k6 while streaming your results to [k6.io](https://k6.io)
+where you can look at the test in real-time and also perform detailed results analysis.
+
+As part of its SaaS solution, k6 Cloud also offers
+[distributed execution from the cloud](/using-k6/cloud-execution), to run larger and/or
+geographically distributed tests.
+
+
+
+This means you can run your own load generator and test internal systems, but benefit from a more
+powerful and convenient SaaS solution when you want to store, share and analyze test results.
+
+You can also utilize the k6.io cloud to *execute* tests (but such tests will require that
+the target system is reachable from the public Internet).
+
+## Getting started with k6 and k6 Cloud Insights
+
+- First you need to [create a k6.io account](https://app.k6.io/account/register)
+
+- Once logged in, click the "CLI" link in the left menu (at the bottom).
+
+
+
+- Follow the instructions on screen to get k6 installed and setup for steaming test results.
+
+
+
+If you have already installed k6 you only need to make sure you have it configured with access to
+your k6 Cloud API token. You do that by either running `k6 login cloud` and entering your k6 Cloud
+account details or you set the `K6_CLOUD_TOKEN` to [your API token value](https://app.k6.io/account/api-token)
+(you can also use the API token to login from the command-line using
+`k6 login cloud -t `).
+
+Don't forget to add `-o cloud` to specify that you want the test results streamed to Insights!
+
+
+
+
+```shell
+$ K6_CLOUD_TOKEN=c3b391149764640ed7d51476cd34a947f0d0762552a5bae79ee10b07ee84c1f7 k6 run -o cloud script.js
+```
+
+```shell
+$ docker run -i \
+ -e "K6CLOUD_TOKEN=c3b391149764640ed7d51476cd34a947f0d0762552a5bae79ee10b07ee84c1f7" \
+ loadimpact/k6 \
+ run -o cloud -
+
+Now your test should be running, and results should be streamed live to k6.io. k6 will output
+something like this when it starts:
+
+
+
+As you can see in the screen shot above, k6 will tell you that you can use the URL
+`https://app.k6.io/runs/123` to go directly to the test result/analysis page where
+results will be updated continuously throughout the test.
+
+## Streaming results to a project other than the default one
+
+By default tests and test runs will be created and run under your default project, in your default
+organization. To create and run tests under a different project, whether under your default
+organization or one you've been invited to, you have two options:
+
+1. You can specify the project ID in the script options:
+
+
+
+2. You can set the `K6_CLOUD_PROJECT_ID` environment variable when running the test.
+
+ You find the ID of a k6 Cloud project by selecting it in the UI and looking
+ in the URL bar of your browser, the `12345` in `https://app.k6.io/projects/12345`
+ is the project ID.
+
+## Insight service run states
+
+When you run a k6 test run against k6 Cloud Insights, data will be continuously streamed
+to the cloud. While this happens the test's *run state* will be marked as `Running`. A test run
+that ran its course will be marked `Finished`. The run state has nothing to do with the test
+passing any of its checks, only that the test itself is operating correctly.
+
+If you deliberately abort your test (e.g. by pressing *Ctrl-C*), it will still be considered
+`Finished` by Insights. You can still look and analyze the test data you streamed so far. The test
+will just have run shorter than originally planned.
+
+Another possibility would be if you lose network connection with k6 Cloud Insights while your
+test is running. In that case Insights will patiently wait for you to reconnect. In the meanwhile
+your test's run state will continue to appear as `Running` on the Insights web overview. If no
+reconnection happens,
+
+Insights will time out after two minutes of no data, setting the run state to `Timed out`. You can
+still analyze a timed out test but you'll of course only have access to as much data as was
+streamed before the network issue.
+
+## Aggregation
+
+Since version 0.21.0, k6 supports partial aggregation of metrics streamed to k6 Cloud Test Results
+for reduced bandwidth usage and processing times. To enable this, set the environment
+variable `K6_CLOUD_AGGREGATION_PERIOD` to the aggregation period you want, for example `1s`. If
+there are more than a certain number of HTTP metrics for a period (100 by default, but it can be
+modified by setting `K6_CLOUD_AGGREGATION_MIN_SAMPLES`), they are partially aggregated. It is
+important to note that outlier metrics are automatically detected and sent separately, they are
+never aggregated.
+
+## Cloud/Distributed execution
+
+k6 also offers a commercial cloud service, k6 Cloud, for distributed execution of k6 tests. See
+the [Cloud execution](/cloud) page for more information.
+
+## More information
+
+- [k6 Cloud Test Results at k6.io](https://k6.io/cloud)
+- Detailed information about k6 Cloud Test Results [analysis/results view](/cloud)
diff --git a/src/data/markdown/docs/01 guides/04 Test Types/00 Introduction.md b/src/data/markdown/docs/01 guides/04 Test Types/00 Introduction.md
new file mode 100644
index 0000000000..38ec4792a0
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/04 Test Types/00 Introduction.md
@@ -0,0 +1,52 @@
+---
+title: 'Introduction'
+excerpt: 'Guide to test types'
+---
+
+There are many types of tests that can be performed with k6. Each type serves a different purpose.
+
+
+
+Each test type is designed to give you different insights about your system.
+
+[Smoke Test's](/test-types/smoke-testing) role is to verify that your System can handle
+minimal load, without any problems.
+
+[Load Test](/test-types/load-testing) is primarily concerned with assessing the performance
+of your system in terms of concurrent users or requests per second.
+
+[Stress Test](/test-types/stress-testing) and [Spike testing](/test-types/stress-testing#spike-testing-in-k6)
+are concerned with assessing the limits of your system and stability under extreme conditions.
+
+[Soak Test](/test-types/soak-testing) tells you about reliability and performance of your
+system over the extended period of time.
+
+The important thing to understand is that each test can be performed with the same test script.
+You can write one script and perform all the above tests with it. The only thing that changes is
+the test configuration, the logic stays the same.
+
+Different test types will teach you different things about your system and give you the insight
+needed to understand or optimize performance.
+
+Start with a [Smoke test](/test-types/smoke-testing) and see how easy it is to get your first load test running!
+
+
diff --git a/src/data/markdown/docs/01 guides/04 Test Types/01 Smoke Testing.md b/src/data/markdown/docs/01 guides/04 Test Types/01 Smoke Testing.md
new file mode 100644
index 0000000000..d87ee0fed9
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/04 Test Types/01 Smoke Testing.md
@@ -0,0 +1,69 @@
+---
+title: "Smoke testing"
+excerpt: "Smoke test is a regular load test, configured for minimal load. You want to run a smoke test as a sanity check every time you write a new
+script or modify an existing script"
+---
+
+Smoke test is a regular load test, configured for minimal load.
+You want to run a smoke test as a sanity check every time you write a new
+script or modify an existing script.
+
+You want to run a smoke test to:
+ 1. Verify that your test script doesn't have errors.
+ 2. Verify that your system doesn't throw any errors when under minimal load
+
+## Smoke testing in k6
+
+Here's a relatively simple smoke test script to get you started. You can copy it, change a few URLs and start testing in no time.
+If you would like to see more comprehensive script, check out our [example section](/examples).
+
+
+
+The VU chart of a smoke test should look similar to this. You want to use only 1 or 2 VUs.
+
+
+If your smoke test produced any errors, you must either correct the script or fix your environment
+before you can continue.
+
+The k6 output should look similar to this:
+
+
+Once your Smoke Test shows 0 errors, as on the screenshot above, you can go to the next step and
+execute a [Load Test](/test-types/load-testing) to assess the performance of your system.
diff --git a/src/data/markdown/docs/01 guides/04 Test Types/02 Load Testing.md b/src/data/markdown/docs/01 guides/04 Test Types/02 Load Testing.md
new file mode 100644
index 0000000000..c2c7eb63c3
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/04 Test Types/02 Load Testing.md
@@ -0,0 +1,154 @@
+---
+title: "Load testing"
+excerpt: "Load testing is primarily concerned with assessing the current performance of your system in terms
+of concurrent users or requests per second."
+---
+
+Load Testing is primarily concerned with assessing the current performance of your system in terms
+of concurrent users or requests per second.
+
+When you want to understand if your system is meeting the performance goals, this is the type of test you'll run.
+
+> ## What is Load Testing
+> Load Testing is a type of Performance Testing used to
+> determine a system's behavior under both normal and peak conditions.
+>
+> Load Testing is used to ensure that the application performs satisfactorily
+> when many users access it at the same time.
+
+You should run Load Test to:
+ 1. Assess the current performance of your system under typical and peak load.
+ 2. Make sure you are continuously meeting the performance standards as you make changes to your system (code and infrastructure).
+
+You probably have some understanding about the amount of traffic your system is seeing on average and during peak hours.
+This information will be useful when deciding what your performance goals should be, in other words,
+how to configure the [performance thresholds](/using-k6/thresholds).
+
+Let's say you're seeing around 600 concurrent users on average and 1000 users during the peak hours of operation.
+
+It's probably important to you to meet the performance goals both during normal hours and peak hours,
+therefore it's recommended to configure the load test with the high load in mind - 1000 users in this case.
+
+## Load Testing in k6
+
+Note, this test has one simple threshold. The response time for 99% requests must be below 1.5 seconds.
+Thresholds are a way of ensuring that your system is meeting the performance goals you set for it.
+
+
+
+```javascript
+import http from 'k6/http';
+import {check, group, sleep} from 'k6';
+
+export let options = {
+ stages: [
+ { duration: "5m", target: 1000 }, // simulate ramp-up of traffic from 1 to 100 users over 5 minutes.
+ { duration: "10m", target: 1000 }, // stay at 50 users for 5 minutes
+ { duration: "5m", target: 0 }, // ramp-down to 0 users
+ ],
+ thresholds: {
+ 'http_req_duration': ['p(99)<1500'], // 99% of requests must complete below 1.5s
+ 'logged in successfully': ['p(99)<1500'], // 99% of requests must complete below 1.5s
+ }
+};
+
+const BASE_URL = 'https://test-api.k6.io';
+const USERNAME = 'TestUser';
+const PASSWORD = 'SuperCroc2020';
+
+export default () => {
+ let loginRes = http.post(`${BASE_URL}/auth/token/login/`, {
+ username: USERNAME,
+ password: PASSWORD
+ });
+
+ check(loginRes, { 'logged in successfully': (resp) => resp.json('access') !== '' });
+
+ let authHeaders = { headers: {
+ Authorization: `Bearer ${loginRes.json('access')}`
+ }};
+
+ let myObjects = http.get(`${BASE_URL}/my/crocodiles/`, authHeaders).json();
+ check(myObjects, { 'retrieved crocodiles': (obj) => obj.length > 0 });
+
+ sleep(1);
+}
+```
+
+
+This is a rather simple script that authenticates the user, and retrieves list of objects.
+If you would like to see a more comprehensive test that makes use of groups, checks, thresholds,
+helper functions, see our [examples section](/examples).
+
+The VU chart of a typical load test looks similar to this
+
+
+Note that the number of users starts at 0, and slowly ramps up to the nominal value, where it stays for an extended period of time.
+The ramp down stage is optional.
+
+We recommend you to always include a ramp-up stage in all your Load Tests because:
+ - it allows your system to warm up or auto scale to handle the traffic
+ - it allows you to compare the response time between the low-load and nominal-load stages.
+ - If you run a load test using the SaaS cloud service, it allows the automated performance alerts to
+ better understand the normal behaviour of your system.
+
+## Load Testing scenario - simulating a normal day
+You may also go one step further and configure the load test to resemble more closely your normal and peak conditions.
+In that case you could configure the load test to stay at 600 users for most of the day, and ramp-up
+to 1000 users during the peak hours of operation, then ramp-down back to normal load.
+
+Make sure you don't go over your normal number of VUs - that's not load testing, it's [stress testing](/test-types/stress-testing).
+
+
+
+
+```javascript
+export let options = {
+ stages: [
+ { duration: "5m", target: 60 }, // simulate ramp-up of traffic from 1 to 100 users over 5 minutes.
+ { duration: "10m", target: 60 }, // stay at 100 users for 10 minutes
+ { duration: "3m", target: 100 }, // ramp-up to 100 users over 3 minutes (peak hour starts)
+ { duration: "2m", target: 100 }, // stay at 100 users for short amount of time (peak hour)
+ { duration: "3m", target: 60 }, // ramp-down to 60 users over 3 minutes (peak hour ends)
+ { duration: "10m", target: 60 }, // continue at 60 for additional 10 minutes
+ { duration: "5m", target: 0 } // ramp-down to 0 users
+ ],
+ thresholds: {
+ 'http_req_duration': ['p(99)<1500'], // 99% of requests must complete below 1.5s
+ }
+};
+```
+
+
+The VU chart for the above configuration should look like this:
+
+
+
+k6 is very flexible in simulating the ramp-up/ramp-down scenarios.
+
+### Note about performance thresholds
+Whenever you are load testing, you have some expectations in mind.
+
+Typical expectations are:
+ - 99% of requests should finish within 5 seconds.
+ - 95% of requests should finish within 1 second.
+ - 99% users should be able to login successfully on the first try
+
+Performance thresholds are a way to describe your expectations in a formal way, and automatically
+evaluate those expectations on each test run.
+Once you have configured the thresholds you'll see a Pass/Fail metric for each threshold,
+and you will know immediately if your system fulfills your expectations without analyzing the results in details.
+
+
+
+
+> ## Start small
+>
+> If this is your first time running load tests, start small. Your application and infrastructure
+> might not be as rock solid as you think. We've had thousands of users run load tests that quickly
+> crashed their applications (or staging environments).
+
+
+
+If your system crashes under a load test, it means that your load test has morphed into a [stress test](/test-types/stress-testing),
+which is the next type we're covering.
diff --git a/src/data/markdown/docs/01 guides/04 Test Types/03 Stress testing.md b/src/data/markdown/docs/01 guides/04 Test Types/03 Stress testing.md
new file mode 100644
index 0000000000..9c198191dc
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/04 Test Types/03 Stress testing.md
@@ -0,0 +1,243 @@
+---
+title: 'Stress testing'
+excerpt: 'Stress Testing is a type of Load testing used to determine the limits of the system. The purpose of this test is to verify the stability and reliability of the system under extreme conditions.'
+---
+
+Stress testing is one of many different types of load testing.
+
+While [load testing](/test-types/load-testing) is primarily concerned with assessing the systems performance,
+the purpose of stress testing is to assess the availability and stability of the system under heavy load.
+
+> ## What is stress testing?
+>
+> Stress Testing is a type of Load testing used to determine the limits of the system.
+> The purpose of this test is to verify the stability and reliability of the system under **extreme conditions**.
+
+To execute a proper stress test, one needs to push the system over its normal operations, to its limits, and _beyond the breaking point_.
+
+You typically want to run a Stress Test to:
+
+1. determine how your system will behave under extreme conditions
+2. determine what is the maximum capacity of your system in terms of users or RPS.
+3. determine the breaking point of your system and its failure mode
+4. determine if your system will recover without manual intervention after the stress test is over
+
+When stress testing, you're going to configure the test to include more concurrent users than:
+
+1. your application typically sees
+2. you think it will be able to handle.
+
+It's important to note that a stress test does not mean you're going to overwhelm the system
+immediately — that's a spike test, we're going to cover it in a minute.
+
+A stress test should be configured in many gradual steps, each step increasing the concurrent load of the system.
+
+A classic example of a need for stress testing is "Black Friday" or "Cyber Monday" - two days each
+year that generates multiple times the normal traffic for many internet businesses.
+
+A stress test can be only a couple of steps, or it can be many, as you see in the example below.
+No matter how many steps you include, just remember this type of test is about finding out what
+happens when pushing the performance limits of your system — so don’t worry about being too aggressive.
+
+With this said, you probably don't want to run this test against your production environment.
+We recommend running this type of test in a UAT or staging environment.
+
+## Stress Testing in k6
+
+You can easily create a stress test in k6 by properly configuring the `options` object.
+Remember, the point of this test is to gradually push your system beyond its breaking point.
+It's probably the easiest to start with an example.
+
+
+
+The VU chart of a Stress Test should look similar to this:
+
+
+This configuration increases the load by 100 users every 2 minutes and stays at this level for
+5 minutes. We have also included a recovery stage at the end, where the system is gradually
+decreasing the load to 0.
+
+If your infrastructure is configured to auto-scale, this test will help you to determine:
+
+1. How quickly the auto-scaling mechanisms react to increased load
+2. Are there any failures during the scaling events
+
+The point of the recovery stage is to determine if the system can serve requests once the load
+decreases to a normal level. If you are testing auto-scaling, you may want to scale down in steps
+as well to determine if the down-scaling is working.
+
+# Spike testing
+
+Spike test is a variation of a Stress Test, but it does not gradually increase the load,
+instead it spikes to extreme load over a very short window of time.
+While a stress test allows the SUT (System Under Test) to gradually scale up its
+infrastructure, a spike test does not.
+
+> ## What is Spike testing
+>
+> Spike testing is a type of stress testing that immediately overwhelms the system with an extreme surge of load.
+
+You want to execute a spike test to:
+
+1. Determine how your system will perform under a sudden surge of traffic
+2. Determine if your system will recover once the traffic has subsided.
+
+A classic need for a spike testing is if you've bought advertising on a big television event,
+such as the Super Bowl or a popular singing competition.
+
+You’re expecting a large number of people to see your advertisement and immediately visit your website,
+which can end with disastrous results if you haven't tested for this scenario and made
+performance optimizations in advance.
+
+Another typical example is a "HackerNews hug of death" - someone links to your website on one
+of the popular internet forums such as HackerNews or Reddit which makes thousands of people visit
+your system at the same time.
+
+Success or failure of a spike test depends on your expectations. Systems generally react in 4 different ways:
+
+1. Excellent: system performance is not degraded during the surge of traffic.
+ Response time is similar during low traffic and high traffic.
+2. Good: Response time is slower, but the system does not produce any errors.
+ All requests are handled.
+3. Poor: System produces errors during the surge of traffic, but recovers to normal after the
+ traffic subsides.
+4. Bad: System crashes, and does not recover after the traffic has subsided.
+
+## Spike testing in k6
+
+Here's an example script configuration for a spike test.
+
+
+
+The VU chart of a Spike Test should look similar to this:
+
+
+Note, the test starts with a period of 1 minute of low load, a quick spike to very high load, followed by a recovery period of low load.
+
+Remember that the point of this test is to suddenly overwhelm the system. Don't be afraid to increase the number of VUs beyond your worst-case prediction.
+Depending on your needs, you may want to extend the recovery stage to 10+ minutes to see when the system finally recovers.
+
+
+
+> ### ⚠️ Don't execute these tests in your production environment
+>
+> A successful Stress/Spike test will overwhelm your system and may make it unavailable.
+> Double check your URLs to make sure you are not testing the production system.
+
+
+
+## Conclusions
+
+Stress and Spike testing help to prepare you for the extreme conditions your system will
+inevitably encounter in production.
+
+Preparing for inevitable is a sign of maturity for a technical organization. Stress testing not
+only makes your system more reliable but also decreases the stress level of your Ops and Dev teams.
+
+Once your system has is stress-proof, you may want to run a Soak Test to see if other reliability
+issues don't surface over an extended period.
diff --git a/src/data/markdown/docs/01 guides/04 Test Types/05 Soak Testing.md b/src/data/markdown/docs/01 guides/04 Test Types/05 Soak Testing.md
new file mode 100644
index 0000000000..088550c9d4
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/04 Test Types/05 Soak Testing.md
@@ -0,0 +1,93 @@
+---
+title: "Soak testing"
+excerpt: "The soak test uncovers performance and reliability issues stemming from a system being under pressure for an extended period."
+---
+
+While [Load testing](/test-types/load-testing) is primarily concerned with Performance assessment, and
+[Stress Testing](/test-types/stress-testing) is concerned with system stability under extreme conditions,
+the Soak Testing is concerned with reliability over a long time.
+
+The soak test uncovers performance and reliability issues stemming from a system being under
+pressure for an extended period.
+
+Reliability issues typically relate to bugs, memory leaks, insufficient storage quotas,
+incorrect configuration or infrastructure failures. Performance issues typically relate to
+incorrect database tuning, memory leaks, resource leaks or a large amount of data.
+
+With Soak test you can simulate days worth of traffic in only a few hours.
+
+You typically run this test to:
+ - Verify that your system doesn't suffer from bugs or memory leaks, which result in a crash or
+ restart after several hours of operation
+ - Verify that expected application restarts don't lose requests.
+ - Find bugs related to race-conditions that appear sporadically.
+ - Make sure your database doesn't exhaust the allotted storage space and stops.
+ - Make sure your logs don't exhaust the allotted disk storage
+ - Make sure the external services you depend on don't stop working after a certain amount of
+ requests are executed.
+
+You may discover that the performance of your application was much better at the beginning of the
+test in comparison to the end. This typically happens if your database is not properly tuned.
+Adding indexes or assigning additional memory may help.
+
+# Soak testing in k6
+
+We recommend you to configure your Soak Test at about 80% capacity of your system.
+If your system can handle a maximum of 500 simultaneous users, you should configure your soak test to 400 VUs.
+
+The duration of a stress test should be measured in hours. We recommend you to start with a 1 hour test,
+and once successful extend it to several hours.
+Some errors are related to time, and not to the total number of requests executed.
+
+Here's a sample test configuration.
+
+
+
+The VU chart of a Soak Test should look similar to this:
+
+
+
+
+
+> ### Make a cost estimate before starting a Soak Test
+>
+> Soak test can simulate days or weeks worth of normal traffic within a few hours. This means that your
+> infrastructure and vendor costs may be significant.
+> If you are testing a website, you should consider excluding your CDN from the test.
+> If your system makes use of external services, you may want to calculate the cost before you start the test.
+
+
+
+## Conclusions
+Soak Testing helps you uncover bugs and reliability issues that surface over an extended period.
+Many complex systems have bugs of this nature. This test should be executed after your standard
+Load Tests are successful, and your system has been found stable when executing a Stress Test.
+
+Soak testing is the last major step on the road to building reliable systems.
diff --git a/src/data/markdown/docs/01 guides/04 Test Types/images/load-test-2.png b/src/data/markdown/docs/01 guides/04 Test Types/images/load-test-2.png
new file mode 100644
index 0000000000..0a69be23e6
Binary files /dev/null and b/src/data/markdown/docs/01 guides/04 Test Types/images/load-test-2.png differ
diff --git a/src/data/markdown/docs/01 guides/04 Test Types/images/load-test.png b/src/data/markdown/docs/01 guides/04 Test Types/images/load-test.png
new file mode 100644
index 0000000000..b69cd6c2c1
Binary files /dev/null and b/src/data/markdown/docs/01 guides/04 Test Types/images/load-test.png differ
diff --git a/src/data/markdown/docs/01 guides/04 Test Types/images/smoke-test-terminal-output.png b/src/data/markdown/docs/01 guides/04 Test Types/images/smoke-test-terminal-output.png
new file mode 100644
index 0000000000..2824e2c768
Binary files /dev/null and b/src/data/markdown/docs/01 guides/04 Test Types/images/smoke-test-terminal-output.png differ
diff --git a/src/data/markdown/docs/01 guides/04 Test Types/images/smoke-test.png b/src/data/markdown/docs/01 guides/04 Test Types/images/smoke-test.png
new file mode 100644
index 0000000000..7429496b2d
Binary files /dev/null and b/src/data/markdown/docs/01 guides/04 Test Types/images/smoke-test.png differ
diff --git a/src/data/markdown/docs/01 guides/04 Test Types/images/soak-test.png b/src/data/markdown/docs/01 guides/04 Test Types/images/soak-test.png
new file mode 100644
index 0000000000..b841acd9fa
Binary files /dev/null and b/src/data/markdown/docs/01 guides/04 Test Types/images/soak-test.png differ
diff --git a/src/data/markdown/docs/01 guides/04 Test Types/images/spike-test.png b/src/data/markdown/docs/01 guides/04 Test Types/images/spike-test.png
new file mode 100644
index 0000000000..a35079dc04
Binary files /dev/null and b/src/data/markdown/docs/01 guides/04 Test Types/images/spike-test.png differ
diff --git a/src/data/markdown/docs/01 guides/04 Test Types/images/stress-test.png b/src/data/markdown/docs/01 guides/04 Test Types/images/stress-test.png
new file mode 100644
index 0000000000..449dd80b03
Binary files /dev/null and b/src/data/markdown/docs/01 guides/04 Test Types/images/stress-test.png differ
diff --git a/src/data/markdown/docs/01 guides/04 Test Types/images/test-types.png b/src/data/markdown/docs/01 guides/04 Test Types/images/test-types.png
new file mode 100644
index 0000000000..f488149453
Binary files /dev/null and b/src/data/markdown/docs/01 guides/04 Test Types/images/test-types.png differ
diff --git a/src/data/markdown/docs/01 guides/05 Testing Guides/01 API load testing.md b/src/data/markdown/docs/01 guides/05 Testing Guides/01 API load testing.md
new file mode 100644
index 0000000000..899cf61f6b
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/05 Testing Guides/01 API load testing.md
@@ -0,0 +1,242 @@
+---
+title: 'API load testing'
+excerpt: 'API load testing considerations, best practices and examples'
+---
+
+It is crucial to test your API with various testing methods and tools. From unit- to performance-testing, you need to have plans and execute them with great care. One type of testing the API is to put load on it to see how it performs, hence the load-testing. In this guide, you'll learn how to do API load testing and what the best practices are. You'll also learn about our tools, which helps you generate or convert your existing API documentation or tests into k6 scripts.
+In this guide you'll find information about our tools, how to do API load testing and what the best practices are.
+
+## How to load test APIs with k6
+
+Our developer-friendly tool for load-testing is k6. You can write JavaScript code to load test your API. This is different from other tools, which are focused more on simple testing by hammering one or multiple endpoints via predefined requests, in that, you can write a user-flow scenarios in JavaScript to do all sorts of load testing. Using this tool will help you achieve more by giving you the possibility of:
+
+1. writing your tests in this well-known scripting language, ES5.1(+).
+2. using correlation to easily connect various requests together. (For example, you can log in to your API, extract the API key from the response, and use it to make other requests, with a unique API key dedicated to that specific session.)
+3. having the option to set thresholds on your requests to achieve your SLOs.
+4. automating your load testing in your CI tool.
+
+k6 binaries are available for various platforms, so you don't need to install a language runtime anymore. It is really easy to use by providing a easy-to-use command line interface:
+
+```bash
+$ k6 run script.js
+```
+
+Using this command, you can run your load test script and put load on your API. Since you're already in the documentation, make sure to look around for specifics catered to your use case. To give you an example, have a look at the following script, taken from [HTTP Requests](/using-k6/http-requests) section of the docs. It uses the [k6/http API](/javascript-api/k6-http) to make a request. You can easily play with the example to create your own script. The following sections describe how to do load testing, either by hammering an endpoint or testing the user flow (scenario).
+
+## Hammering an endpoint
+
+Suppose you want to load test your login endpoint to see how many requests it can handle concurrently. This is the type you write to achieve that.
+
+```js
+import http from 'k6/http';
+
+export default function() {
+ var url = 'http://api.yourplatform.com/login';
+ var payload = JSON.stringify({
+ email: 'johndoe@example.com',
+ password: 'PASSWORD',
+ });
+
+ var params = {
+ headers: {
+ 'Content-Type': 'application/json',
+ },
+ };
+
+ http.post(url, payload, params);
+}
+```
+
+It is a simple HTTP request, which runs once. By tweaking the command line arguments, you can adjust how many concurrent requests you want to make. This command would create 1000 concurrent sessions (virtual users), and would run this single requests 10 times for each virtual user, hence 10,000 iterations.
+
+```bash
+$ k6 run -vus 1000 --iterations 10000 script.js
+```
+
+While hammering is good in some cases, e.g. if you want to test endpoints in isolation, it is recommended that you take into account other endpoints and write a scenario-based load test script.
+
+## User flow (scenarios) testing
+
+In the following example, you see four consecutive [HTTP requests](/using-k6/http-requests) to your API to log in, fetch user profile, update user profile and finally log out. Each request has unique characteristics, accepts some parameters and finally returns a [response](/javascript-api/k6-http/response-k6-http), which is [check](/using-k6/checks)ed against a set of rules. We also pause after each request and response, for the API to be able to keep up and not be flooded. There are also a set of options at the top, that defines load test [options](/using-k6/options) in your script.
+
+The `iterations` is a number that specifies how many iterations (executions) of the script per VU should happen, which is divided by the number of virtual users. The `vus` is a number specifying the number of concurrent sessions (virtual users) to your API. So from `iterations` and `vus` you deduct that you'll likely run each VU around 10 iterations, depending on your API response time and network roundtrip.
+
+As you can see, this is a fairly normal, yet simple, user flow that tries to mimic the user behavior while using our mobile App or website. For the sake of simplicity, only four requests has been shown, but you can easily add additional requests to be able to have a more realistic user experience. This way you can test the flow of your users' navigation in your application or platform. This is the point that distinguishes k6 from most of the currently available load testing tools, in that it can be used to test realistic user flows, instead of just relying on hammering a set of endpoints.
+
+```js
+import http from 'k6/http';
+import { check, sleep } from 'k6';
+
+let options = {
+ vus: 1000,
+ duration: '600s',
+};
+const SLEEP_DURATION = 0.1;
+
+export default function() {
+ let body = JSON.stringify({
+ username: 'user_' + __ITER,
+ password: 'PASSWORD',
+ });
+ let params = {
+ headers: {
+ 'Content-Type': 'application/json',
+ },
+ tags: {
+ name: 'login', // first request
+ },
+ };
+
+ group('simple user journey', _ => {
+ // Login request
+ let login_response = http.post(
+ 'http://api.yourplatform.com/v2/login',
+ body,
+ params,
+ );
+ check(login_response, {
+ 'is status 200': r => r.status === 200,
+ 'is api key present': r => r.json().hasOwnProperty('api_key'),
+ });
+ params.headers['api-key'] = login_response.json()['api_key'];
+ sleep(SLEEP_DURATION);
+
+ // Get user profile request
+ params.tags.name = 'get-user-profile';
+ let user_profile_response = http.get(
+ 'http://api.yourplatform.com/v2/users/user_' + __ITER + '/profile',
+ params,
+ );
+ sleep(SLEEP_DURATION);
+
+ // Update user profile request
+ body = JSON.string({
+ first_name: 'user_' + __ITER,
+ });
+ params.tags.name = 'update-user-profile';
+ let update_profile_response = http.post(
+ 'http://api.yourplatform.com/v2/users/user_' + __ITER + '/profile',
+ body,
+ params,
+ );
+ sleep(SLEEP_DURATION);
+
+ // Logout request
+ params.tags.name = 'logout';
+ let logout_response = http.get(
+ 'http://api.yourplatform.com/v2/logout',
+ params,
+ );
+ sleep(SLEEP_DURATION);
+ });
+}
+```
+
+## Virtual Users vs. Constant Request Rate
+
+Historically, there are two types of categories of load testing tools: scriptable and non-scriptable. Non-scriptable tools generate requests to one or multiple endpoints without any correlation between the requests providing the option to define a constant request rate to hit an endpoint. On the other hand, scriptable tools are usually designed to facilitate user flow testing, thus providing the option to configure the number of virtual users to set up the load of your test. k6 belongs to this category.
+
+With some changes to your test script, k6 can also perform a constant request rate in your load test by controlling the number of virtual users and the sleep time between each iteration.
+
+The following blog post shows [how to generate a constant request rate in k6](https://k6.io/blog/how-to-generate-a-constant-request-rate-in-k6).
+
+> We are working on a set of awesome new features in k6, namely the [New Executors](https://github.com/loadimpact/k6/pull/1007) that will introduce new ways to configure the load in your tests.
+
+## Test creation
+
+There are various ways to create a test and eventually run it using k6. You can write your tests in your favorite editor, convert your existing Postman collections and Swagger/OpenAPI specification documents to scripts or use proxy recording as HAR files and convert them to k6 scripts. The recommended way is definitely to write your own scripts. The other tools are available just to help you with onboarding to k6. There's a rich set of tools that can help you create load tests and run them to gain insight into your system.
+
+
+
+As is evident in the above diagram, there are four different tools to help onboard existing users into k6. The best way is to make your own custom script, but you can use our converters to help you with generating script out of your existing postman collections, swagger specification documents, fiddler and [HAR]() recordings.
+
+## Write your own script
+
+Writing your own script is the recommended way to create your load test script, since it is the easiest, yet the most flexible and customizable, way to create and run your load tests. With many examples for different use cases throughout the documentation, you can easily create load test scripts.
+
+## Converters for API testing tools
+
+We have developed two (actually more) converters for you to be able to convert your existing Postman collections or your existing Swagger/OpenAPI specification documents to k6 scripts. Although fairly easy to use, the output script is not 100 percent accurate, since they uses wrapper APIs and limited functionality (postman-to-k6) or have limited support for all the features (openapi-to-k6). Use them to create the skeleton of your script, then try to eventually modify it or your own script.
+
+The postman-to-k6 converter produces non-idiomatic k6 scripts, because it uses wrapper for various functionality inside Postman and it has its own limitations. On the other hand, the openapi-to-k6 converter produces idiomatic k6 scripts, yet not every single OpenAPI specification is supported.
+
+### Postman-to-k6
+
+Postman is a good and easy to use tool for API testing. It can group requests into collections and you can export/import them easily. Yet, there is an easy way to create your own k6 script out of your existing Postman exported collections. We have a tool called [postman-to-k6](https://github.com/loadimpact/postman-to-k6) tool that can convert your Postman exported collections. For this to work, you need to have either Node.js or Docker installed. This tool also converts your Postman scripts written with the help of the [Postman Scripting API](https://learning.postman.com/docs/postman/scripts/postman-sandbox-api-reference/) and includes a wrapper for its API and related libraries. The output of the tool, which is a k6 script, is fairly customizable.
+
+
+
+### OpenAPI-Generator
+
+Swagger/OpenAPI is a good way to design, document and test your APIs. We have built a new OpenAPI generator in the [openapi-generator](https://github.com/loadimpact/openapi-generator) project, that takes in the Swagger/OpenAPI specification in JSON/YAML format and generates pure idiomatic k6 script. It is really easy to use, and there are various ways to [install](https://github.com/OpenAPITools/openapi-generator#1---installation) and use it. In order to get an idea of how it works, please have a look at our [Load Testing Your API with Swagger/OpenAPI and k6](https://k6.io/blog/load-testing-your-api-with-swagger-openapi-and-k6) blog post.
+
+## Converters for proxy recorders
+
+### HAR-to-k6
+
+HAR files are recorded browser logs that can be exported as an archive and later replayed. [HAR files specification](https://w3c.github.io/web-performance/specs/HAR/Overview.html) defines the format of the file, which is basically a JSON file with various objects containing requests to different resources. This file can be converted to k6 script using the [HAR-to-k6](https://github.com/loadimpact/har-to-k6) tool. For this, you also need to have Node.js installed. Since HAR files contain requests to every single resource that the browser fetches, it is not recommended to use the converted script intact, rather revise it to remove extra unneeded requests to load test CDNs and other static files. Generally, recording users' sessions is not usually the best way to do API load testing, since it creates more noise than real requests and it is used more for website load testing. Nevertheless, you can take advantage of it, but beware of what you are doing, since it won't give you a nice experience as the other tools mentioned above do. This tool gives you a _scenario_ for API load testing. Look at the [best practices](#best-practices) to have a better view of what should and what shouldn't be included in your test script.
+For more information, refer to [session recording](/using-k6/session-recording-har-support) guide.
+
+### Fiddler-to-k6
+
+Originally called [FiddlerToLoadImpact](https://github.com/loadimpact/FiddlerToLoadImpact), it can be used to export your fiddler recordings into a k6 script. Obviously, you need to have Fiddler installed, for it to work. This tool also creates HAR recordings, so the same holds true for this, in that, it is not fit for API load testing, rather made for website load testing, so beware! For more information, refer to [session recording](/using-k6/session-recording-har-support) guide.
+
+## Different types of API load testing
+
+As said in the introduction, it is crucial to test your API in advance, rather than relying on the untested API, which may crash at any time and have unexpected consequences.
+
+There are various ways to test your API, each pertaining to a particular test type and each producing a different type of load. You can read more about it in [test types](/test-types/introduction) section. Generally each of these tests serves a different purpose.
+
+## API load testing considerations
+
+## Identify your goals
+
+Having a clear goal is of utmost importance in running a load test on your APIs. As with the type of load testing you want to use, you also need to identify your goals to expect correct results. For example, you cannot expect your API to perform very well under heavy load, if you just test it with a simple smoke test. Therefore you need to set well-defined goals and tune your load test to meet your expectations. Usually your goals are to meet your [Service-Level Objectives (SLOs)](https://landing.google.com/sre/sre-book/chapters/service-level-objectives/), which might be defined in a Service-Level Agreement (SLA), formally or informally, between you and the other party, e.g. your users. You set some thresholds for your service and you make yourself responsible for any deviation from that standard.
+Fortunately, these thresholds can be tested using k6, which has a rich set of [metrics](/using-k6/metrics), built-in and custom, that can be tested against a set of [thresholds](/using-k6/thresholds).
+Before writing and eventually running your test, set aside some time to think about your SLOs and then try to design your test, so that it meets your requirements and your customers' expectations.
+
+## Start small and build upon your script
+
+It is important to have a predefined set of goals and expectations, but it's not good to try to meet them all at once. The bigger your list of goals, the less likely your ability to make things right the first time. So, start small, e.g. write and run a test for one or two API endpoints. Try to experiment with different settings and environments, then you can build upon that and execute large tests that span several hours and has thousands of virtual users and hundreds of thousands of requests per second.
+
+The very simple examples in the [running k6](https://k6.io/docs/getting-started/running-k6) section would give you a head start.
+
+## Correlation and data parameterization
+
+Since REST APIs are HTTP-based, hence asynchronous, it is always the responsibility of the client to describe what resource it wants to CRUD on. The whole idea is to have a stateless API, which has a way to relate separate requests to related resources. Usually it is done via some sort of correlation. Correlation would help developers to easily track the relationship between the requests and the resources with a unique key or identifier.
+
+While writing load test scripts, you may want to use this unique key to have your virtual users know which resources to work with in each request. In the above scenario script, you saw how we used the responses of the login request to extract the API key and later used it with subsequent requests to identify ourselves as a certain (virtual) user.
+
+This can be easily taken advantage of by using the response data (in form of a JSON object or even a body of text) to provide unique keys (correlation IDs, API keys, etc.) to other requests down the flow.
+
+There's also the possibility of loading data files from disk to help parameterize the load test. Imagine that you want to have 1000 users with separate credentials to be able to make multiple requests. This can be achieved by simply loading a JSON file and using its objects in your requests.
+
+For more information, refer to [the post on the k6 community forum](https://community.k6.io/t/when-parameterizing-data-how-do-i-not-use-the-same-data-more-than-once-in-a-test/).
+
+## URL grouping
+
+By default, k6 will print runtime information and general results to standard output, `stdout`, while the test is running, and will also print a summary after the test has ended. It may output more granular result data using special output plugins, one of them being [JSON output](/getting-started/results-output/json). The contents of the records in output includes many pieces of useful information like various metrics and some of those metrics include the URL of the requests you made.
+
+Sometimes you need to make lots of similar API requests to read or create many resources of the same type. As shown in the following example, a 100 posts will be fetched with unique requests. Each of these requests will create a metric and will have the full URL inside the metric. This poses a problem for data aggregation, either on our cloud platform or on your own API load testing stack. The problem is that all the metrics for each of these URLs will be separate and they'll be aggregated individually, because they are different in their `id` field. It also creates a lot of unnecessary records in the output.
+
+```javascript
+for (var id = 1; id <= 100; id++) {
+ http.get(`http://example.com/posts/${id}`);
+}
+
+// tags.name="http://example.com/posts/1",
+// tags.name="http://example.com/posts/2",
+```
+
+There's a way to prevent creating a lot of metrics for the same URL. It's called [URL grouping](/using-k6/http-requests#section-url-grouping), and by using it you'll avoid creating separate metrics for the same URL. It is just a matter of using a tag that you should add to your requests' [parameters](/javascript-api/k6-http/params-k6-http).
+
+```javascript
+for (var id = 1; id <= 100; id++) {
+ http.get(`http://example.com/posts/${id}`, {
+ tags: { name: 'PostsItemURL' },
+ });
+}
+
+// tags.name="PostsItemURL",
+// tags.name="PostsItemURL",
+```
diff --git a/src/data/markdown/docs/01 guides/05 Testing Guides/02 Load testing websites.md b/src/data/markdown/docs/01 guides/05 Testing Guides/02 Load testing websites.md
new file mode 100644
index 0000000000..e1b11378d8
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/05 Testing Guides/02 Load testing websites.md
@@ -0,0 +1,189 @@
+---
+title: "Load testing websites"
+excerpt: "This guide provides some recommendations to help you load testing a website or web app with k6."
+---
+
+This guide describes some recommendations to help you load testing a website or web app.
+
+A load test of a website simulates many concurrent users mimicking one or several real user journeys that generally involve complex actions in a logical flow. This guide can help you creating these user scenarios, getting started, and avoid common pitfalls.
+
+## Should I load test my website?
+
+You should if you are concerned about the availability and scalability of your website.
+
+The performance golden rule states:
+
+> 80-90% of the end-user response time is spent on the frontend.
+
+But this is not necessarily accurate when the number of users visiting your website increases. In this scenario, the frontend work will always be the same , but the backend time might grow exponentially with the rise of concurrent users if your system struggles with the increased concurrency.
+
+
+
+In the performance golden rule article Steve Souders pointed out that:
+
+> If you’re worried about availability and scalability, focus on the backend.
+
+Load testing simulates many concurrent users visiting your website to help you analyze how the performance of your backend behaves.
+
+## What should I check load testing a website?
+
+The goal of load testing is to test how your system behaves under a particular load. A performance test will focus on testing the performance of the requests to your backend. The two most basic aspects to analyze are the server response time and the number of returned errors.
+
+A performance test is not responsible for testing the User Interface, and it will not check visual aspects of UI elements like the position, size, form, etc.
+
+
+In fact, [k6 does not run a browser engine](/#what-k6-does-not), and it won’t render a webpage as a browser.
+
+
+```js
+// The following request will ONLY load the HTML index page.
+// Other assets that a browser would load when accessing this webpage will NOT be loaded.
+http.get(‘https://google.com’)
+```
+
+Therefore, you cannot use k6 to measure the rendering time or other Browser Real User Metrics.
+
+In the context of load testing, browser metrics are in most cases less useful. Each browser runs independently, and the number of concurrent users visiting your website will not impact these metrics.
+
+## What should I start load testing?
+
+To begin, we recommend that you consider performance testing to be an iterative and continuous process. You start small, test frequently and iterate, iterate, iterate.
+
+The first thing you have to decide is what to load test first.
+
+On one side, you should evaluate which are the performance aspects that are most valuable to your business and has the most significant risks.
+
+On the other side, you have to identify what your users will do regularly. You could look at your analytics tools to find the most frequent user journeys.
+
+With this information, it’s time to analyze the frequency of usage, business value, performance risks, and any other critical performance aspect of your organization to decide what to load test first.
+
+As a rule of thumb, Simple testing is better than no testing:
+
+> Start small and simple, make sure you get something out of the testing first, then expand the test suite and add more complexity until you feel that you’ve reached the point where more effort spent on realism will not give enough return on your invested time.
+
+
+Once you adopt performance testing in your development lifecycle, your performance test suite will grow over time. You will add and update performance tests based on the evolution of your application, new performance areas, bugs, and the maturity of your team and processes, amongst other factors.
+
+To sum up, start small, test frequently and iterate, iterate, iterate.
+
+## Should I load test my website in production or pre-production?
+
+We recommend to Load test in a pre-production environment that mimics the production environment as closely as possible.
+
+Testing regularly in a pre-production environment allows assessing the performance of your website over time and catch performance regressions before they reach production.
+
+Load testing in pre-production allows breaking your website without worrying about the interruption of your service. Load testing in production is risky, but if your processes and team are mature, you could run your load tests in production as part of your chaos experiments. Sometimes it is the best way to get a picture of the real world.
+
+## Which type of performance tests should I run against my website?
+
+The best results come when you run your tests in a systematic way, where you can compare data between test runs, and you change a minimal number of variables between tests. For this reason, we recommend the following testing pattern:
+
+### Baseline tests
+
+A test with a small number of Virtual Users meant to produce response times for a system experiencing favorable conditions. You want a low enough number not to cause any stress on your system.
+
+This test typically runs for 5-10 minutes, and it will establish the baseline for future comparisons.
+You could use the information on the analysis of these test results to create [thresholds](/using-k6/thresholds) in your future tests.
+
+### Stress tests
+
+A test that steps through different levels of load and will highlight where performance problems start to happen.
+You should expect to iterate this test multiple times as you enter a test-> analyze-> make changes-> repeat pattern.
+
+
+### Load tests
+
+After you experience a stable stress test result, this test will become part of your load tests and you should regularly run them to confirm the system can meet your performance goals.
+
+You could also define your load tests based on the observation of your normal and peak traffic levels. You should use data on how many users you have normally and any business goals you may have for concurrency.
+
+Use the formula:
+
+> VUs = (Peak Hourly Sessions * Average Session Duration in Seconds) / 3600
+
+You should run your test long enough for all VUs to complete 2-5 complete iterations of your test script. If your user journey takes 5 minutes to complete, 10+ minutes would be a reasonable test length.
+
+### Other tests as required
+
+You may have other traffic patterns you want to test, for example, from different load zones or different ramping profiles. Continue testing here as needed.
+
+### Continuous and Regression Testing
+
+Many users schedule performance tests or run them as part of a CI pipeline to monitor for performance regressions. Since you’ve created your test scripts, most of the work is already done! Read more in our [Automated Performance Testing guide](/testing-guides/automated-performance-testing).
+
+## Best practices load testing websites
+
+### Start recording your user journey
+
+Load tests should mimic user journeys as closely as possible. These user journeys, aka user scenarios, generally involve complex actions in a logical flow (dozens or hundreds of requests).
+
+The process of creating this type of load test could be tedious. But the recording of a user session could facilitate the job of starting the test creation for you.
+
+Check out the [Session Recording guide](/using-k6/session-recording-har-support) to learn more about how to auto-generate your load test from a user session.
+
+### Do not include third-party requests
+
+
+You may have various external requests happening for a normal visitor on your site — for example, Analytics tools, Social Networks, Widgets, etc.
+
+While these requests do impact the user experience on the frontend, they have no impact on the performance of your system on your backend. We highly recommend removing all third party requests from your test script for the following reasons:
+- Third-party requests have no impact on your backend performance.
+- Third parties may throttle requests, skewing your results.
+- Third parties add a lot of noise to your test result data which makes understanding results harder.
+- It may be against the TOS with the third party to run a test against their system.
+
+
+### Do not include your CDN assets
+
+You should consider your CDN as a third-party provider and do not include CDN requests in your load tests because of the reasons explained previously. Additionally, load testing a CDN may cost you money.
+
+But there are also valid cases to test your CDN in case you want to understand something about your CDN provider.
+
+### Calculate the VU number
+
+You could define your load tests based on the observation of your normal and peak traffic levels, and use this formula to determine the number of VUs to specify in your load tests:
+
+> VUs = (hourly sessions \* average session duration in seconds)/3600
+>
+> - hourly sessions = Number of sessions per hour
+> - average session duration = Average time between the first and last request of each user
+
+Refer to [Determining Concurrent Users in Your Load Tests](https://k6.io/blog/monthly-visits-concurrent-users) to learn how to calculate the formula using Google Analytics.
+
+### Tag different types of resources
+
+By default, the standard metrics of a load testing tool -- for example, the response time metric will aggregate the values of all the website requests. But you might want to see the results of these metrics filtered by the type of resources:
+
+- 95th percentile response time of all the images.
+- 99th percentile response time of all the API requests.
+
+Different types of resources could behave very differently and could make meaningless the value of the aggregated metrics.
+
+
+If you might want to filter your metrics based on different types of requests, consider using the [tagging feature](/using-k6/tags-and-groups#tags).
+
+
+```js
+http.get("http://myweb.com/images/logo.png", { tags: { assets: "image" } });
+```
+
+### Group the different webpages
+
+[Groups](/using-k6/tags-and-groups#groups) help you organize your load test around a common logic.
+When a load test simulates a user scenario visiting multiple pages, it is a good practice to set up a group for each webpage to organize your load test and facilitate the visualization of your test results.
+
+```js
+group("visit homepage", function() {
+ // load homepage resources
+});
+group("login page", function() {
+ // load login page and perform login
+});
+```
+
+## See also
+
+- [Session Recording guide](/using-k6/session-recording-har-support)
+- [Data Correlation in your test script](/examples/correlation-and-dynamic-data)
+- [Parameterizing from a JSON or CSV file](/examples/data-parameterization)
+- [Determining Concurrent Users in Your Load Tests](https://k6.io/blog/monthly-visits-concurrent-users)
diff --git a/src/data/markdown/docs/01 guides/05 Testing Guides/03 Automated Performance testing.md b/src/data/markdown/docs/01 guides/05 Testing Guides/03 Automated Performance testing.md
new file mode 100644
index 0000000000..df420c073d
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/05 Testing Guides/03 Automated Performance testing.md
@@ -0,0 +1,283 @@
+---
+title: "Automated performance testing"
+excerpt: "The why and how of automated load testing"
+---
+
+Automation, a hot topic in the larger testing community and somewhat of a holy graal, is the end-goal for many organizations when it comes to understanding performance over time. However, where to start or how to get there from where you’re currently at is not always straightforward, especially if you don’t already have a lot of experience in performance engineering. This guide aims to lay down the steps and best practices for achieving your goal to automate load testing.
+
+## Why you should automate load tests
+
+Let’s start by examining why you would consider automating your performance tests. To do that we need to revisit why we run performance tests in the first place:
+
+- **Avoid launch failures** leading to a missed opportunity window and wasted investments, eg. your app or site crashing during a high-profile product launch event.
+- **Avoid bad user experiences** leading visitors and customers to go with the competition, and you ultimately losing revenue, eg. churning hard won customers due to non responsive app or website.
+- **Avoid performance regressions** as new code changes get deployed to your production system and put infront of end users. This is what this guide is primarily aimed at.
+
+From here the decision to go for test automation is hopefully straightforward:
+
+- **Shifting performance testing left**, making sure it happens as close to development as possible, giving developers an early feedback loop for performance matters.
+- **Adding performance regression checks** to your Continuous Integration and Delivery (CI/CD) pipelines.
+
+Of course not [all types of performance tests](/test-types/introduction) are suitable for automation, A/B type performance tests is one such type of performance test where it probably doesn’t make much sense to automate, unless you're aiming to compare the performance over time of A and B of course.
+
+## Create test cases
+
+If you haven’t already created test cases for your system then that’s the first step. If you don’t know where to start, then we suggest having a read through one of our guides for creating tests for websites and APIs/microservices:
+
+- [Website testing guide](/testing-guides/load-testing-websites)
+- [API testing guide](/testing-guides/api-load-testing)
+
+In general, when creating test cases the golden rule is to start small and then expanding from that initial starting point. Identify the most business critical transactions in your system and write test cases covering that part of the system.
+
+**Tip**: Once you’ve gained enough experience with test creation we strongly advise you to [modularize your tests](/using-k6/modules) to make them common logic/patterns reusable across members of your team, or teams across the larger organization.
+
+
+## Know your goals
+
+Besides the step of creating a test case itself, the most important step to ensure a successful load testing automation project is to spell out your goals. What metrics, and values (in absolute terms; "response times should be less than 500ms", and not just "response times should not be slow"), are important to you, your team and the business.
+
+If you have established [Service Level Agreements (SLAs)](https://en.wikipedia.org/wiki/Service-level_agreement) in place with your customers, or just [Service Level Objectives (SLOs)](https://en.wikipedia.org/wiki/Service-level_objective) and [Service Level Indicators (SLIs)](https://en.wikipedia.org/wiki/Service_level_indicator) defined internally, then that’s a great starting point. If not, then it’s a great opportunity to bring stakeholders together and discuss what goals you should have defined to drive a performance culture.
+
+Starting with the results of a baseline test is another good way to find a starting point for your goals. A baseline test is a test run with a single or very few VUs that you know your system can handle without breaking a sweat. The idea being that you'll get some real numbers on where your system is at in terms of latency and response time. Important to make sure that your baseline test is not resulting in any unwanted errors and is functionally accurate.
+
+From the perspective of human perceptive abilities, the following guidance points from [Nielsen Norman Group](https://www.nngroup.com/articles/response-times-3-important-limits/) might be of help when deciding on what latency and response time to aim for:
+
+> - **0.1 second** is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
+> - **1.0 second** is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
+> - **10 seconds** is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.
+
+Once your goals are clear, you need to codify them as [thresholds](/using-k6/thresholds) which is the mechanism by which you specify pass/fail criteria in k6. More on that below.
+
+## Integrate with CI
+
+Once your goals are clear, you can start introducing load tests into your automation pipelines. Running load tests from a continuous integration (CI) system is very simple with k6. The set up can easily be generalized across the various CI tools into the following sequence of steps:
+
+- **Installation**: Install k6 on the server/VM/container that will be running the CI jobs.
+- **Version control test files**: Store your test files in version control, alongside application code.
+- **Pass/fail criteria**: Codify pass/fail criteria as thresholds so that k6 can pass/fail your tests when run in CI.
+- **Local vs Cloud execution**: Decide how to run tests.
+- **Test frequency**: Decide how often to run tests.
+- **Notifications**: Get notified in your team communication tool of choice when your tests fail.
+
+We'll have a closer look at these general steps in more detail below. You'll find CI tool specific guides further down.
+
+
+## Installation of k6
+
+To run load tests in your CI tool of choice, the first step is to install k6. There are 3 ways to do this:
+
+- Using one of the OS specific package managers
+- Pulling the k6 Docker image
+- Downloading the k6 binary for your OS
+
+See the full [installation instructions](/getting-started/installation) for more information.
+
+## Version control test files
+
+One of the best practices that we advise users and customers to adopt is version controlling load tests, preferably alongside application code like other types of tests. In our experience this will lead to a higher likeliness of tests being maintained as the application evolves. It also affords you all the usual benefits of version controlling your code.
+
+## Pass/fail criteria
+
+Every step in an automation pipeline either passes or fails. As mentioned in [Know your goals](/testing-guides/automated-performance-testing#know-your-goals), the mechanism by which k6 decides whether a test has passed or failed is called [thresholds](/using-k6/thresholds). Without your goals codifed as thresholds there's no way for k6 to actually know if your test should be considered a success or failure.
+
+A basic threshold on the 95th percentile of the response time metric looks like this:
+
+```js
+export let options = {
+ thresholds: {
+ // fail the test if 95th percentile response goes above 500ms
+ "http_req_duration": ["p(95)<500"]
+ }
+};
+```
+
+You can setup thresholds on any metric in k6 and you can have multiple thresholds per metric. You can also optionally specify that a threshold should immediately abort a test if the threshold is reached. Adding that to the example above would look like this:
+
+```js
+export let options = {
+ thresholds: {
+ // fail and abort the test if 95th percentile response goes above 500ms
+ // delay the threshold evaluation for 1 min to gather enought data
+ "http_req_duration": [
+ { threshold: "p(95)<500", abortOnFail: true, delayAbortEval: "1min" }
+ ]
+ }
+};
+```
+
+If the test ends with one or more failed thresholds k6 will exit with a non-zero exit code signalling to the CI tool that the load test step failed, halting the build/pipeline from progressing further, and hopefully notifiying you so you can take corrective action, but more on notifications further down below.
+
+## Local vs Cloud execution
+
+k6 supports both local (`k6 run ...`) and cloud execution (`k6 cloud ...`) modes. In local execution mode k6 will generate all the traffic from the machine where it's being run. In CI this would be the build servers. When executing a test locally, you can optionally stream the results to k6 Cloud for storage and visualization (`k6 run -o cloud ...`). In cloud execution mode k6 will instead bundle up and send the main JS test file, and all dependent files, to k6 Cloud as an archive for execution on cloud infrastructure managed by our k6 Cloud service. The different modes of execution are appropriate for different use cases. Some general guidance follows:
+
+| Use case | Execution mode |
+| --------------------- | -------------- |
+| Load test with <1000 VUs on a machine with consistent dedicated resources | Local execution |
+| The target system is behind a firewall and not accessible from the public Internet | Local execution |
+| Can't ensure consistent dedicated resources locally for load test, eg. your CI tool is running jobs on machines/containers with varying amounts of resources | Cloud execution |
+| Need to run test from multiple geographic locations in a test | Cloud execution |
+
+### Authenticating with k6 Cloud
+
+If you decide to use the k6 Cloud service, either to stream results with local execution (`k6 run -o cloud ...`) or through cloud execution, you'll need to authenticate with k6 Cloud. The recommended way to do this is by setting the `K6_CLOUD_TOKEN` environment variable in your CI tool. Alternatively you can pass in your k6 Cloud token to `k6 login cloud` like so:
+
+```bash
+k6 login cloud -t
+```
+
+Get your k6 Cloud token from the [account settings page](https://app.k6.io/account/token).
+
+## How often to run tests
+
+The boring, but true, answer to the question of how often you should run load tests is that "it depends". It depends on a number of parameters. How often is your application changing? Do you need many or few VUs to generate the necessary load? How long is one full cycle of a VU iteration? etc. Testing a full user journey or just a single API endpoint or website page has different implications on the answer as well.
+
+There are three primary factors that will affect what solution is the best for you:
+
+- VU iteration duration
+- Your branching strategy
+- Pre-production test environment
+
+### VU iteration duration
+
+A rule of thumb is that the shorter the "VU iteration duration" the more frequent you *can* run your tests without introducing long delays in the development cycle feedback loop, or blocking your team mates' deployments from access to shared pre-production environments.
+
+A quick re-cap of the [test life cycle](/using-k6/test-life-cycle) article:
+
+```js
+export default function() {
+ // k6 will execute this default function in a loop for every VU
+ // for the duration of the test run.
+
+ // The duration it takes for a VU to complete one loop, or iteration,
+ // of this function is what we refer to as "VU iteration duration".
+}
+```
+
+You can find the VU iteration duration in the k6 terminal output:
+
+
+
+### Branching strategy
+
+Another important aspect to consider is your team's version control branching policy. If you are strict with keeping feature branches separate from you main team-wide development branch, and you have per-feature test environments, then you can also generally run load tests with a higher frequency than if your builds are competing for exclusive access to a shared pre-production environment.
+
+It's also important to consider that load test might not need to run at the same frequency as unit or functional tests. Running load tests could just as well be run as part of Pull/Merge Request creation or when a feature branch gets merged into the main team-wide development branch. Both of these setup variants can be achieved with most CI tools.
+
+
+### Pre-production test environment
+
+As touched upon in the previous section, on branching strategy, the test environment is the third point to consider. We point out "pre-production" specifically as that is the best practices when it comes to load testing. If your team is at the maturity level of running chaos experiments in productionn then fine, run load test in production as well. If not, stick to pre-production.
+
+Things to consider with your test environment:
+
+- Make sure there's no other traffic hitting the same test environment as your test
+- Make sure the system has an adequate amount of data in any database that is being accessed as a result of the test traffic
+- Make sure databases only contains test data, and not real production data
+
+### Guidance
+
+Generalized, our recommendation is as follows, broken down by VU iteration duration:
+
+| VU iteration duration | Test frequency | Trigger mechanism |
+| --------------------- | -------------- | -------------- |
+| <10s | On every commit | Commit push |
+| <60s | Daily/Nightly | Scheduling, Pull/Merge Requests or when merging into main development branch |
+| >60s | Couple of times a week | Scheduling, Pull/Merge Requests or when merging into main development branch |
+| >5min | Once a week | Scheduling, Pull/Merge Requests or when merging into main development branch |
+
+**Scheduling**
+
+Besides triggering tests based on commit events, we also often see users and customers use [cron](https://k6.io/blog/performance-monitoring-with-cron-and-k6) or CI tool equivalent mechanisms for running tests on off-hours or at a particular cadence.
+
+If you're using k6 Cloud you can use the built in [scheduling feature](/cloud/creating-and-running-a-test/scheduling-tests) to trigger tests at a frequency of your chosing.
+
+**Load test suite**
+
+Do you need to run your full load test suite on every commit? Probably not, but in any case should not be the initial ambition. Repeating the advice from earlier in the guide, start small and expand from there. Start by evaluating the most business critical transactions/journeys you have in your system and start by automating those.
+
+## Notifications
+
+Once you have your load tests integrated into a CI pipeline you should make sure you’re also getting notified whenever a build/pipeline fails. You might already get notification via email, Slack, Microsoft Teams or Webhook through your CI tool, but if not you can set it up as follows.
+
+### For k6 OSS
+
+There’s no builtin notification mechanism in k6 OSS, so you’d have to send a notification from the test script. One way to achieve this is by sending a notification event request to Slack or Microsoft Teams.
+
+For Slack you need to first [setup an incoming webhook](https://slack.com/intl/en-se/help/articles/115005265063-Incoming-WebHooks-for-Slack). Once setup you get a webhook URL that you specify as the target of the POST request in the teardown function:
+
+```js
+import {sleep} from "k6";
+import http from "k6/http";
+
+export let options = {
+ thresholds: {
+ // fail the test if 95th percentile response goes above 500ms
+ "http_req_duration": ["p(95)<500"]
+ }
+};
+
+export default function() {
+ http.get('https://test.k6.io/');
+ sleep(5.0);
+}
+
+export function teardown(data) {
+ // send notification request to Slack API
+ let event = {
+ text: 'My test just finished!',
+ };
+ let res = http.post('https://hooks.slack.com/services/...',
+ JSON.stringify(event), { headers: { 'Content-Type': 'application/json' } });
+}
+```
+
+For Microsoft Teams you need to first [setup an incoming webhook connector](https://docs.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook). Once setup you get a webhook URL that you specify as the target of the POST request in the teardown function:
+
+```js
+import http from "k6/http";
+import {sleep} from "k6";
+
+export let options = {
+ thresholds: {
+ // fail the test if 95th percentile response goes above 500ms
+ "http_req_duration": ["p(95)<500"]
+ },
+ // Increase teardown function timeout as MS Teams API seems to be slower than >10s
+ teardownTimeout: '60s'
+};
+
+export default function() {
+ http.get('https://test.k6.io/');
+ sleep(5.0);
+}
+
+export function teardown(data) {
+ // send notification request to Microsoft Teams API
+ let event = {
+ text: "My test just finished!"
+ };
+ let res = http.post('https://outlook.office.com/webhook/...',
+ JSON.stringify(event), { headers: { 'Content-Type': 'application/json' } });
+}
+```
+
+### For k6 cloud
+
+If you’re running your tests from k6 Cloud then you can make use of our [Slack integration](/cloud/integrations/notifications#slack).
+
+
+## CI integration guides
+
+We have written CI tool specific guides following the steps mentioned above:
+
+
+
+
+## See also
+
+- [Test life cycle](/using-k6/test-life-cycle)
+- [Thresholds](/using-k6/thresholds)
+- [Modules](/using-k6/modules)
+- [Scheduling](/cloud/creating-and-running-a-test/scheduling-tests)
+- [Slack integration](/cloud/integrations/notifications#slack)
diff --git a/src/data/markdown/docs/01 guides/05 Testing Guides/Frontend-Backend-LoadTesting.png b/src/data/markdown/docs/01 guides/05 Testing Guides/Frontend-Backend-LoadTesting.png
new file mode 100644
index 0000000000..dff6dacd9d
Binary files /dev/null and b/src/data/markdown/docs/01 guides/05 Testing Guides/Frontend-Backend-LoadTesting.png differ
diff --git a/src/data/markdown/docs/01 guides/05 Testing Guides/images/vu-iteration-duration-k6-cli.png b/src/data/markdown/docs/01 guides/05 Testing Guides/images/vu-iteration-duration-k6-cli.png
new file mode 100644
index 0000000000..cc7116c808
Binary files /dev/null and b/src/data/markdown/docs/01 guides/05 Testing Guides/images/vu-iteration-duration-k6-cli.png differ
diff --git a/src/data/markdown/docs/01 guides/05 Testing Guides/our-tools.png b/src/data/markdown/docs/01 guides/05 Testing Guides/our-tools.png
new file mode 100644
index 0000000000..3facf8bc89
Binary files /dev/null and b/src/data/markdown/docs/01 guides/05 Testing Guides/our-tools.png differ
diff --git a/src/data/markdown/docs/01 guides/05 Testing Guides/postman-export.png b/src/data/markdown/docs/01 guides/05 Testing Guides/postman-export.png
new file mode 100644
index 0000000000..5f8169c6bf
Binary files /dev/null and b/src/data/markdown/docs/01 guides/05 Testing Guides/postman-export.png differ
diff --git a/src/data/markdown/docs/01 guides/06 Misc/01 Usage reports.md b/src/data/markdown/docs/01 guides/06 Misc/01 Usage reports.md
new file mode 100644
index 0000000000..33a4ddbf3e
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/06 Misc/01 Usage reports.md
@@ -0,0 +1,62 @@
+---
+title: "Usage reports"
+excerpt: ""
+---
+
+By default, k6 sends a usage report each time it is run, so that we can track how often people use it. This report can be turned off by setting the environment variable `K6_NO_USAGE_REPORT` or by adding the option `--no-usage-report` when executing k6.
+
+The usage report does not contain any information about what you are testing. The contents are the following:
+
+- The k6 version (string, e.g. "0.17.2")
+- Max VUs configured (number)
+- Test duration (number)
+- Total stages duration (number)
+- VU iterations configured (number)
+- The running program's operating system target (`darwin`, `freebsd`, `linux`...)
+- The running program's architecture target (386, amd64, arm, s390x...)
+
+This info is sent to an HTTP server that collects statistics on k6 usage.
+
+For those interested, here is the actual Go [code](https://github.com/loadimpact/k6/blob/master/cmd/run.go) that generates and sends the usage report:
+
+
+
+```go
+ // If the user hasn't opted out: report usage.
+
+ if !conf.NoUsageReport.Bool {
+ go func() {
+ u := "http://k6reports.k6.io/"
+ mime := "application/json"
+ var endTSeconds float64
+
+ if endT := engine.Executor.GetEndTime(); endT.Valid {
+ endTSeconds = time.Duration(endT.Duration).Seconds()
+ }
+
+ var stagesEndTSeconds float64
+ if stagesEndT := lib.SumStages(engine.Executor.GetStages()); stagesEndT.Valid {
+ stagesEndTSeconds = time.Duration(stagesEndT.Duration).Seconds()
+ }
+
+ body, err := json.Marshal(map[string]interface{}{
+ "k6_version": Version,
+ "vus_max": engine.Executor.GetVUsMax(),
+ "iterations": engine.Executor.GetEndIterations(),
+ "duration": endTSeconds,
+ "st_duration": stagesEndTSeconds,
+ "goos": runtime.GOOS,
+ "goarch": runtime.GOARCH,
+ })
+
+ if err != nil {
+ panic(err) // This should never happen!!
+ }
+ if _, err := http.Post(u, mime, bytes.NewBuffer(body)); err != nil {
+ log.WithError(err).Debug("Couldn't send usage blip")
+ }
+ }()
+ }
+```
+
+
diff --git a/src/data/markdown/docs/01 guides/06 Misc/02 Fine tuning OS.md b/src/data/markdown/docs/01 guides/06 Misc/02 Fine tuning OS.md
new file mode 100644
index 0000000000..2809ee4da3
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/06 Misc/02 Fine tuning OS.md
@@ -0,0 +1,323 @@
+---
+title: "Fine tuning OS"
+excerpt: ""
+---
+
+## Background
+
+A number of users while running their test scripts locally will run into limits within their OS which would prevent them from making the necessary number of requests to complete the test. This limit usually manifests itself in a form of **Too Many Open Files** error. These limits, if unchanged, can be a severe bottleneck if you choose to run a somewhat bigger or complicated test locally on your machine.
+
+In this article we will show you how to inspect the OS imposed limits of your system, tweak them and scale for larger tests.
+
+Important to note here is that everything that we are covering in this article needs to be approached with a healthy dose of caution. As with any changes you are introducing to your OS, we recommend not to blindly change your system settings to a specific value. You should document ways of testing that shows a clear before/after relation. E.g. before changing MSL / TIME_WAIT period, confirm that you’re experiencing the issue (error messages, netstat, ss, etc.), change settings conservatively, re-run the test and note any improvement. This way we can gauge the impact of the optimization, any negative side-effects and come up with a range of recommended values.
+
+> Modifications below have been tested for macOS Sierra 10.12 and above, so if you are running an older version than that, the process for changing these settings may be different.
+
+## User resource limits
+
+Unix operating system derivatives like GNU/Linux, BSDs and macOS, have the capability to limit the amount of system resources available to a process to safeguard system stability. This includes the total amount of memory, CPU time or amount of open files a single process is allowed to manage.
+
+Since in Unix everything is a file, including network connections, application testing tools that heavily use the network, such as k6, might reach the configured limit of allowed open files, depending on the amount of network connections used in a particular test.
+
+As mentioned in our opening section, this results in a message like the following being shown during a test:
+
+```bash
+WARN[0127] Request Failed error="Get http://example.com/: dial tcp example.com: socket: too many open files"
+```
+
+This message means that the network resource limit has been reached, which will prevent k6 from creating new connections, thus altering the test result. In some cases this may be desired, to measure overall system performance, for example, but in most cases this will be a bottleneck towards testing the HTTP server and web application itself.
+
+Below we will look at ways to increase this resource limit, and allow k6 to run tests with hundreds or thousands of concurrent VUs from a single system.
+
+## Limit types
+
+There are two types of resource limits in Unix systems:
+
+- hard limits: these are the absolute maximum allowed for each user, and can only be configured by the root user.
+- soft limits: these can be configured by each user, but cannot be above the hard limit setting.
+
+## Viewing limits configuration
+
+**Linux**
+
+On GNU/Linux, you can see the configured limits with the ulimit command.
+
+`ulimit -Sa` will show all soft limits for the current user:
+
+```bash
+$ ulimit -Sa
+core file size (blocks, -c) 0
+data seg size (kbytes, -d) unlimited
+scheduling priority (-e) 0
+file size (blocks, -f) unlimited
+pending signals (-i) 3736
+max locked memory (kbytes, -l) 16384
+max memory size (kbytes, -m) unlimited
+open files (-n) 1024
+pipe size (512 bytes, -p) 8
+POSIX message queues (bytes, -q) 819200
+real-time priority (-r) 0
+stack size (kbytes, -s) 8192
+cpu time (seconds, -t) unlimited
+max user processes (-u) 3736
+virtual memory (kbytes, -v) unlimited
+file locks (-x) unlimited
+```
+While `ulimit -Ha` will show all hard limits for the current user:
+
+```bash
+$ ulimit -Ha
+core file size (blocks, -c) unlimited
+data seg size (kbytes, -d) unlimited
+scheduling priority (-e) 0
+file size (blocks, -f) unlimited
+pending signals (-i) 3736
+max locked memory (kbytes, -l) 16384
+max memory size (kbytes, -m) unlimited
+open files (-n) 1048576
+pipe size (512 bytes, -p) 8
+POSIX message queues (bytes, -q) 819200
+real-time priority (-r) 0
+stack size (kbytes, -s) unlimited
+cpu time (seconds, -t) unlimited
+max user processes (-u) 3736
+virtual memory (kbytes, -v) unlimited
+file locks (-x) unlimited
+```
+
+Note the difference of open files being a maximum of 1024 for the soft limit, while it's 1048576 for the hard limit.
+
+**macOS**
+
+In macOS however, you will have a couple of different system imposed limits to take into consideration.
+
+The first one is `launchctl limit maxfiles` which prints the per-process limits which are specified also as a soft limit and a hard limit. When a soft limit is exceeded a process may receive a signal (for example, if the CPU time or file size is exceeded), but it will be allowed to continue execution until it reaches the hard limit (or modifies its resource limit).
+`kern.maxfiles` is the limit of total file descriptors on the entire system - the sum total of all the open files for all processes plus all the files the kernel has open for its own purposes.
+
+`sysctl kern.maxfiles`
+
+`sysctl kern.maxfilesperproc`
+
+So, to reiterate, running commands above will show you the system limits on open files and running processes.
+
+## Changing limits configuration
+
+The first thing you should consider before changing the configuration is the amount of network connections you expect your test to require. The http_reqs metric in the k6 result summary can hint at this, but a baseline calculation of number of max. VUs * number of HTTP requests in a single VU iteration will deliver a fair approximation. Note that k6 also deals with text files and other resources that count towards the "open files" quota, but network connections are the biggest consumers.
+
+**macOS**
+
+Before we can change any system imposed limits in macOS we will need to disable a security feature put in place to prevent us in doing so. You will need to disable System Integrity Protection that was introduced in OS X El Capitan to prevent certain system-owned files and directories from being modified by processes without the proper privileges.
+
+To disable it you will need to restart your Mac and hold down `Command + R` while it boots. This will boot it into Recovery Mode.
+
+There you should navigate to `Utilities` which are located in the menu bar at the top of the screen, then open `Terminal`. Once you have it open, enter the following command:
+
+`csrutil disable`
+
+Once you press enter and close the Terminal, you can reboot your Mac normally and log into your account.
+
+## Changing soft limits
+**Linux**
+
+So, let's say that we want to run a 1000 VU test which makes 4 HTTP requests per iteration. In this case we could increase the open files limit to 5000, to account for additional non-network file usage. This can be done with the following command:
+
+```bash
+$ ulimit -n 5000
+```
+
+This changes the limit only for the current shell session.
+
+If we want to persist this change for future sessions, we can add this to a shell startup file. For Bash this would be:
+
+```bash
+$ echo "ulimit -n 5000" >> ~/.bashrc
+```
+
+**macOS**
+
+If the soft limit is too low, set the current session to (values written here are usually close to default ones) :
+
+```bash
+sudo launchctl limit maxfiles 65536 200000
+```
+
+Since sudo is needed, you are prompted for a password.
+
+## Changing hard limits
+**Linux**
+
+If the above command results in an error like cannot modify limit: Operation not permitted or value exceeds hard limit, that means that the hard limit is too low, which as mentioned before, can only be changed by the root user.
+
+This can be done by modifying the `/etc/security/limits.conf` file.
+
+For example, to set both soft and hard limits of the amount of open files per process for the alice account, open `/etc/security/limits.conf` as root in your text editor of choice and add the following lines:
+
+```bash
+alice soft nofile 5000
+alice hard nofile 1048576
+```
+
+The new limits will be in place after logging out and back in.
+
+Alternatively, * hard nofile 1048576 would apply the setting for all non-root user accounts, and root hard nofile 1048576 for the root user. See the documentation in that file or man bash for the ulimit command documentation.
+
+**macOS**
+
+Next step will be to configure your new file limits. Open terminal and paste the following command:
+
+```bash
+sudo nano /Library/LaunchDaemons/limit.maxfiles.plist
+```
+
+This will open a text editor inside your terminal window where you will be prompted to provide your user password and then paste the following:
+
+
+```xml
+
+
+
+
+ Label
+ limit.maxfiles
+ ProgramArguments
+
+ launchctl
+ limit
+ maxfiles
+ 64000
+ 524288
+
+ RunAtLoad
+
+ ServiceIPC
+
+
+
+```
+
+Pressing `Control + X` will save the changes and exit the editor. By pasting and saving this we have introduced two different limitations to your maxfiles limit. The first one (64000) is a soft limit, which if reached, will prompt your Mac to prepare to stop allowing new file opens but still let them open. If the second one is reached (524288), a hard limit, you will again start seeing your old friend, the 'too many files open' error message.
+
+We will use the same procedure to increase the processes limit next.
+
+While in Terminal create a similar file with this command:
+
+```bash
+sudo nano /Library/LaunchDaemons/limit.maxproc.plist
+```
+
+Again, after prompted for your password, you can paste the following and save and close with `Control + X`
+
+```xml
+
+
+
+
+ Label
+ limit.maxproc
+ ProgramArguments
+
+ launchctl
+ limit
+ maxproc
+ 2048
+ 4096
+
+ RunAtLoad
+
+ ServiceIPC
+
+
+
+ ```
+
+ All that is left after this is to reboot your Mac back to the Recovery Mode, open the Terminal, turn the SIP back on with `csrutil enable` and check if the limits were changed with commands we used at the beginning.
+
+In most cases these limits should be enough to run most of your simple tests locally for some time, but you can modify the files above to any values you will need in your testing.
+
+
+
+> Please be aware that all of these limitations are put in place to protect your operating system from files and applications that are poorly written and might leak memory like in huge quantities. We would suggest not going too overboard with the values, or you might find your system slowing down to a crawl if or when it runs out of RAM.
+
+
+
+## General optimizations not dependent on OS
+In this section we will go over some of the optimisations that are not necessarily dependant on your OS, but may impact your testing.
+
+## RAM usage
+
+Depending on the particular k6 test: maximum number of VUs used, number and size of JavaScript dependencies, and complexity of the test script itself, k6 can consume large amounts of system RAM during test execution. While the development is focused on reducing RAM usage as much as possible, a single test run might use tens of gigabytes of RAM under certain scenarios.
+
+As a baseline, count each VU instance to require between 5MB and 20MB of RAM, depending on your script complexity and dependencies. This is roughly between 5GB and 20GB of required system RAM for a 1,000 VU test, so make sure that sufficient physical RAM is available to meet your test demands.
+
+## Virtual memory
+In addition to physical RAM, ensure that the system is configured with an appropriate amount of virtual memory, or swap space, in case higher memory usage bursts are required.
+
+You can see the status and amount of available swap space on your system with the commands swapon or free.
+
+We won't go into swap configuration details here, but you can find several guides online.
+
+## Network performance
+Because k6 can generate and sustain large amounts of network traffic, it also stresses the network stack of modern operating systems. Under certain loads or network conditions it's possible to achieve higher throughput and better performance by tweaking some network settings of the operating system or restructuring the network conditions of the test.
+
+## TCP TIME_WAIT period
+TCP network applications, such as web clients and servers, are assigned a network socket pair (a unique combination of local address, local port, remote address, and remote port) for each incoming or outgoing connection. Typically this socket pair is used for a single HTTP request/response session, and closed soon after. However, even after a connection is successfully closed by the application, the kernel might still reserve resources for quickly reopening the same socket if a new matching TCP segment arrives. This also occurs during network congestion where some packets get lost in transmission. This places the socket in a TIME_WAIT state, and is released once the TIME_WAIT period expires. This period is typically configured between 15 seconds and 2 minutes.
+
+The problem some applications like k6 might run into is causing a high number of connections to end up in the TIME_WAIT state, which can prevent new network connections being created.
+
+In these scenarios, before making changes to the system network configuration, which might have adverse side-effects for other applications, it's preferable to first take some common testing precautions.
+Use different server ports or IPs
+
+Since sockets are uniquely created for a combination of local address, local port, remote address and remote port, a safe workaround for avoiding TIME_WAIT congestion is using different server ports or IP addresses.
+
+For example, you can configure your application to run on ports :8080, :8081, :8082, etc. and spread out your HTTP requests across these endpoints.
+
+## Increase local port range
+When creating an outgoing network connection the kernel allocates a local (source) port for the connection from a range of available ports.
+
+**GNU/Linux**
+
+On GNU/Linux you can see this range with:
+
+```bash
+$ sysctl net.ipv4.ip_local_port_range net.ipv4.ip_local_port_range = 32768 60999
+```
+
+While 28,231 ports might be sufficient for most use cases, this might be a limiting factor if you’re testing with thousands of connections. You can increase it with, for example:
+
+```bash
+sysctl -w net.ipv4.ip_local_port_range="16384 65000"
+```
+
+Be aware that this range applies to both TCP and UDP, so be conservative with the values you choose and increase as needed.
+
+To make the changes permanent, add `net.ipv4.ip_local_port_range=16384 65000` to `/etc/sysctl.conf`.
+Last resort tweaks
+If you still experience network issues with the above changes, consider enabling net.ipv4.tcp_tw_reuse:
+
+```bash
+sysctl -w net.ipv4.tcp_tw_reuse=1
+```
+
+This will enable a feature to quickly reuse connections in TIME_WAIT state, potentially yielding higher throughput.
+
+**macOS**
+
+On macOS the default ephemeral port range is 49152 to 65535, for a total of 16384 ports. You can check this with the sysctl command:
+
+```bash
+$ sysctl net.inet.ip.portrange.first net.inet.ip.portrange.last
+
+net.inet.ip.portrange.first: 49152
+net.inet.ip.portrange.last: 65535
+```
+
+Once you run out of ephemeral ports, you will normally need to wait until the TIME_WAIT state expires (2 * maximum segment lifetime) until you can reuse a particular port number. You can double the number of ports by changing the range to start at 32768, which is the default on Linux and Solaris. (The maximum port number is 65535 so you cannot increase the high end.)
+
+```bash
+$ sudo sysctl -w net.inet.ip.portrange.first=32768
+
+net.inet.ip.portrange.first: 49152 -> 32768
+```
+
+Note that the official range designated by IANA is 49152 to 65535, and some firewalls may assume that dynamically assigned ports fall within that range. You may need to reconfigure your firewall in order to make use of a larger range outside of your local network.
diff --git a/src/data/markdown/docs/01 guides/06 Misc/03 k6 REST API.md b/src/data/markdown/docs/01 guides/06 Misc/03 k6 REST API.md
new file mode 100644
index 0000000000..85eb1d5821
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/06 Misc/03 k6 REST API.md
@@ -0,0 +1,584 @@
+---
+title: 'k6 REST API'
+excerpt: ''
+hideFromSidebar: true
+---
+
+When k6 starts, it spins up an HTTP server with a REST API that can be used to control some
+parameters of the test execution. By default, that server listens on `localhost:6565`, but
+that can be modified by the `--address` CLI flag.
+
+With this API you can see and control different execution aspects like number of VUs, Max
+VUs, pause or resume the test, list groups, set and get the setup data and so on.
+
+You can also find practical usage examples in
+[this blog post](https://k6.io/blog/how-to-control-a-live-k6-test).
+
+## Get Status
+
+**GET** `http://localhost:6565/v1/status`
+
+
+
+This endpoint lets you pause/resume a running test and set the number of `vus` and `vus-max`
+during the test.
+
+## List Metrics
+
+**GET** `http://localhost:6565/v1/metrics`
+
+
+
+This endpoint will give you all the metrics in the current time. You can see more details on all
+metrics available and how to create new ones in [Metrics](/using-k6/metrics).
+
+## Get Metric
+
+**GET** `http://localhost:6565/v1/metrics/id`
+
+
+
+This endpoint will give you details for the given metric in the current time.
+
+You can see more on all metrics available and how to create new ones in [Metrics](/using-k6/metrics).
+
+## List Groups
+
+**GET** `http://localhost:6565/v1/groups`
+
+
+
+This endpoint returns all groups available on the test.
+
+For more details on how to create groups please go to [Tags and Groups](/using-k6/tags-and-groups).
+
+## Get Group
+
+**GET** `http://localhost:6565/v1/groups/id`
+
+
+
+This endpoint returns the Group with the given ID.
+
+For more details on how to create groups, please go to [Tags and Groups](/using-k6/tags-and-groups).
+
+## Get Setup Data
+
+**GET** `http://localhost:6565/v1/setup`
+
+
+
+This endpoint returns the current JSON-encoded setup data.
+
+For more detail about the setup stage please go to [Test life cycle](/using-k6/test-life-cycle).
+
+## Run Setup
+
+**PUT** `http://localhost:6565/v1/setup`
+
+
+
+This endpoint executes the Setup stage and returns the result.
+
+For more detail about the setup stage please go to [Test life cycle](/using-k6/test-life-cycle).
+
+## Update Setup
+
+**PATCH** `http://localhost:6565/v1/setup`
+
+
+
+This endpoint parses the JSON request body and sets the result as Setup data.
+
+For more detail about the setup stage please go to [Test life cycle](/using-k6/test-life-cycle).
diff --git a/src/data/markdown/docs/01 guides/06 Misc/04 Glossary.md b/src/data/markdown/docs/01 guides/06 Misc/04 Glossary.md
new file mode 100644
index 0000000000..665a332b75
--- /dev/null
+++ b/src/data/markdown/docs/01 guides/06 Misc/04 Glossary.md
@@ -0,0 +1,136 @@
+---
+title: Glossary
+excerpt: |
+
+
+---
+
+When discussing complex topics, it is usually a good idea to define a clear, shared terminology to ensure that we leave as little room as possible for misunderstandings. Below, you'll find a list of terms commonly used within the k6 project and what we mean when we use them.
+
+## Correlation
+
+**Correlation** is a term used for describing the process of capturing dynamic data, received from the system under test, for reuse in subsequent requests. A common use case for correlation is retrieving and reusing a session id, or token, throughout the whole lifetime of a [virtual user](#virtual-user).
+
+## Dynamic Data
+
+**Dynamic data** is data that might, or will, change between test runs. Common examples are order ids, session tokens or timestamps.
+
+## Endurance Testing
+
+**Endurance testing** is a synonym for [soak testing](#soak-test).
+
+## Goja
+
+**Goja** is a javascript runtime, purely written in go, that emphasizes standard compliance and performance. We use goja to allow for test scripting without having to compromise speed, efficiency or reliability, which would have been the case using NodeJS. For more details, see the [Goja repository on GitHub](https://github.com/dop251/goja).
+
+## Horizontal Scalability
+
+**Horizontal Scalability** is a trait describing to what degree a system under test’s performance and capacity may be increased by adding more nodes (servers or computers for instance).
+
+## HTTP Archive
+
+An **HTTP Archive**, or **HAR file**, is a file containing logs of a browser interactions with the system under test. All of the included transactions are stored as JSON-formatted text. These archives may then be used to generate test scripts using, for instance, the [har-to-k6 Converter](https://github.com/loadimpact/har-to-k6). For more details, see the [HAR 1.2 Specification](http://www.softwareishard.com/blog/har-12-spec/).
+
+## k6 Cloud
+
+**k6 Cloud** is the common name for the entire cloud product, which is composed of both k6 Cloud Execution and k6 Cloud Test Results.
+
+## Load Test
+
+A **load test** is a type of test used to assess the performance of the system under test in terms of concurrent users or requests per second. See [Load Testing](/test-types/load-testing).
+
+## Metric
+
+A **metric** is a calculation that, using measurements, serves as an indicator of how the system under test performs under a given condition.
+
+## Parameterization
+
+**Parameterization** refers to the process of building a test in such a way that the values used throughout the test might be changed without having to change the actual test script.
+
+## Performance Threshold
+
+A **performance threshold** describes the limits of what is considered acceptable values for a metric produced by a performance test. In many ways, this is similar to an [SLO](#service-level-objective), although a performance threshold only concerns itself with a single metric.
+
+## Reliability
+
+**Reliability** is a trait used to describe a system under test’s ability to produce reliable results consecutively, even under pressure.
+
+## Requests per Second
+
+**Requests per Second**, or **RPS**, is the rate at which requests are executed against the system under test.
+
+## Saturation
+
+**Saturation** is reached when the system under test is fully utilized and hence, unable to handle any additional requests.
+
+## Scalability
+
+**Scalability** is a trait used to describe to what degree a system under test’s performance or capacity may be increased by adding additional resources. See [Vertical scalability](#vertical-scalability) and [Horizontal scalability](#horizontal-scalability).
+
+## Service-level Agreement
+
+A **service-level agreement**, or **SLA** is an agreement made between the one providing the service and someone, often a user of the service, promising that the availability of the service will meet a certain level during a certain period.
+
+If the service provider fails to deliver on that promise, some kind of penalty is usually applied, like a partial or full refund, or monetary compensation.
+
+## Service-level Indicator
+
+A **service-level indicator**, or **SLI** is the metric we use to measure whether a service meets the [service-level objective (SLO)](#service-level-objective). While doing performance monitoring this could, for instance, be the number of successful requests against the service during a specified period.
+
+## Service-level Objective
+
+A **service-level objective**, or **SLO** is an actual target, either internal or part of the [service-level agreement (SLA)](#service-level-agreement), for the availability of the service. This is often expressed as a percentage (99,2%, for instance). If the service meets or exceeds this target, it's deemed stable.
+
+## Smoke test
+
+A **smoke test** is a type of test used to verify that the system under test can handle a minimal amount of load without any issues. It’s commonly used as a first step, to ensure that everything works as intended under optimal conditions, before advancing to any of the other performance test types. See [Smoke Testing](/test-types/smoke-testing).
+
+## Soak test
+
+A **soak test** is a type of test used to uncover performance and reliability issues stemming from a system being under pressure for an extended period. See [Soak Testing](/test-types/soak-testing).
+
+## Stability
+
+**Stability** is a trait used to describe a system under test’s ability to withstand failures and erroneous behavior under normal usage.
+
+## Stress test
+
+A **stress test** is a type of test used to identify the limits of what the system under test is capable of handling in terms of load. See [Stress Testing](/test-types/stress-testing).
+
+## System under test
+
+**System under test** refers to the actual piece of software that we're currently testing. This could be an API, a website, infrastructure, or any combination of these.
+
+## Test Configuration
+
+The options object of a test script or configuration parameters passed via the CLI. See [Options](/using-k6/options).
+
+## Test Run
+
+An individual execution of a test script. See [Running k6](/getting-started/running-k6).
+
+## Test Script
+
+A **test script** is the actual code you run as part of your test run, as well as any (or at least most) of the configuration needed to run the code. It defines how the test will behave as well as what requests will be made. See the [Single Request example](https://k6.io/docs/examples/single-request).
+
+## User Journey
+
+**User journey** is used to describe a sequence of actions taken by either a real or simulated user.
+
+## User Scenario
+
+**User Scenario** is a synonym for [user journey](#user-journey).
+
+## Vertical Scalability
+
+**Vertical scalability** is a trait describing to what degree a system under test’s performance or capacity may be increased by adding more hardware resources to a node (RAM, cores, bandwidth, etc.).
+
+## Virtual Users
+
+**Virtual Users**, or **VUs** are used to perform separate and concurrent executions of your test script. They can make HTTP(s) and WebSocket requests against a webpage or API.
+
+Virtual Users, although emulated by k6 itself, can be used to mimic the behavior of a real user.
+
+VUs typically perform requests at a much higher rate than regular users. Because of this, there is seldom any need for anywhere near as many virtual users as the actual user target.
+
+For additional details, see [What are virtual users?](/cloud/cloud-faq/what-are-vus-virtual-users).
\ No newline at end of file
diff --git a/src/data/markdown/docs/02 javascript api/01 Init context.md b/src/data/markdown/docs/02 javascript api/01 Init context.md
new file mode 100644
index 0000000000..b952fe848c
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/01 Init context.md
@@ -0,0 +1,7 @@
+---
+title: "Init context"
+---
+The init context (aka "init code") is code in the global context that has
+access to a few functions not accessible during main script execution (aka
+"VU context" or "VU code"). For a more detailed description see
+[Running k6](/getting-started/running-k6#section-the-init-context-and-the-default-function).
diff --git a/src/data/markdown/docs/02 javascript api/01 Init context/open.md b/src/data/markdown/docs/02 javascript api/01 Init context/open.md
new file mode 100644
index 0000000000..db35c4feb6
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/01 Init context/open.md
@@ -0,0 +1,86 @@
+---
+title: "open( filePath, [mode] )"
+description: "Opens a file and reads all the contents into memory."
+excerpt: ""
+---
+Opens a file, reading all its contents into memory for use in the script. Favourably used to parameterize tests with data from CSV/JSON files etc.
+
+
+
+> ### Function only available in "init context"
+> This is a function that can only be called from the init context (aka `init code`), code in the global context that is, outside of the main export default function { ... }.
+>
+> By restricting it to the init context, we can easily determine what local files are needed to run the test and thus what we need to bundle up when distributing the test to multiple nodes in a clustered/distributed test.
+>
+> See example further down on this page. For more in-depth description see [Running k6](/getting-started/running-k6).
+
+
+
+| Parameter | Type | Description |
+| --------- | -----| ----------- |
+| filePath | string | The path to the file, absolute or relative, that will be read into memory. The file will only be loaded once, even when running with several VUs. |
+| mode | string | By default the contents of the file is read as text, but if you specify `b` the file will be read as binary data instead. |
+
+
+### Returns
+
+| Type | Description |
+| ---- | ----------- |
+| string / bytes | The contents of the file, read as text or bytes (if `b` has been specified as the mode). |
+
+
+
+```js
+import http from "k6/http";
+import { sleep } from "k6";
+
+let binFile = open("/path/to/file.bin", "b");
+
+export default function() {
+ var data = {
+ field: "this is a standard form field",
+ file: http.file(binFile, "test.bin")
+ };
+ var res = http.post("https://example.com/upload", data);
+ sleep(3);
+}
+```
+
+
diff --git a/src/data/markdown/docs/02 javascript api/02 k6.md b/src/data/markdown/docs/02 javascript api/02 k6.md
new file mode 100644
index 0000000000..33c5de5af5
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/02 k6.md
@@ -0,0 +1,4 @@
+---
+title: "k6"
+---
+The k6 module contains k6-specific functionality.
diff --git a/src/data/markdown/docs/02 javascript api/02 k6/check- val- sets- -tags- -.md b/src/data/markdown/docs/02 javascript api/02 k6/check- val- sets- -tags- -.md
new file mode 100644
index 0000000000..468d5bb73c
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/02 k6/check- val- sets- -tags- -.md
@@ -0,0 +1,45 @@
+---
+title: "check( val, sets, [tags] )"
+description: "Runs one or more checks on a value and generates a pass/fail result but does not throw errors or otherwise interrupt execution upon failure."
+---
+Run checks on a value. A check is a test condition that can give a truthy or
+falsy result. The `sets` parameter contains one or more checks, and the `check()`
+function will return `false` if any of them fail.
+
+Note that checks are not *asserts* in their traditional sense - a failed assertion
+will throw an error, while a check will always return with a pass or a failure.
+Failure conditions can then instead be controlled by thresholds, for more power and flexibility.
+
+| Parameter | Type | Description |
+|-----------------|--------|------------------------------------------|
+| val | any | Value to test. |
+| sets | object | Tests (checks) to run on the value. |
+| tags (optional) | object | Extra tags to attach to metrics emitted. |
+
+### Returns
+
+| Type | Description |
+|------|-------------|
+| boolean | `true` if all checks have succeeded, `false` otherwise. |
+
+
+### Example
+
+Using `check()` to verify that an HTTP response code was 200 and that body was 1234 bytes:
+
+
+
+```js
+import http from "k6/http";
+import { check } from "k6";
+
+export default function() {
+ let res = http.get("http://httpbin.org");
+ check(res, {
+ "response code was 200": (res) => res.status == 200,
+ "body size was 1234 bytes": (res) => res.body.length == 1234,
+ });
+};
+```
+
+
diff --git a/src/data/markdown/docs/02 javascript api/02 k6/fail- -err- -.md b/src/data/markdown/docs/02 javascript api/02 k6/fail- -err- -.md
new file mode 100644
index 0000000000..56404455cd
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/02 k6/fail- -err- -.md
@@ -0,0 +1,34 @@
+---
+title: "fail( [err] )"
+description: "Throws an error, failing and aborting the current VU script iteration immediately."
+---
+Immediately throw an error, aborting the current script iteration.
+
+`fail()` is a simple convenience wrapper on top of JavaScript's `throw()`,
+because the latter cannot be used as `[expr] || throw`, which is a convenient way to write k6 test code.
+
+| Parameter | Type | Description |
+|----------------|--------|--------------------------------------------|
+| err (optional) | string | Error message that gets printed to stderr. |
+
+### Example
+
+Aborting the current script iteration if a check fails:
+
+
+
+```js
+import http from "k6/http";
+import { check, fail } from "k6";
+
+export default function() {
+ let res = http.get("https://k6.io");
+ if (!check(res, {
+ "status code MUST be 200": (res) => res.status == 200,
+ })) {
+ fail("status code was *not* 200");
+ }
+};
+```
+
+
diff --git a/src/data/markdown/docs/02 javascript api/02 k6/group- name- fn -.md b/src/data/markdown/docs/02 javascript api/02 k6/group- name- fn -.md
new file mode 100644
index 0000000000..18cb516108
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/02 k6/group- name- fn -.md
@@ -0,0 +1,50 @@
+---
+title: "group( name, fn )"
+description: "Runs code inside a group. Used to organize results in a test."
+---
+Run code inside a group. Groups are used to organize results in a test.
+
+| Parameter | Type | Description |
+|-----------|----------|--------------------------------------------------------|
+| name | string | Name of the group. |
+| fn | function | Group body - code to be executed in the group context. |
+
+### Returns
+
+| Type | Description |
+|------|---------------------------|
+| any | The return value of _fn_. |
+
+
+### Example
+
+
+
+```js
+import { group, check } from "k6";
+import http from "k6/http";
+
+export default function() {
+ group("my user scenario", function() {
+ group("front page", function() {
+ let res = http.get("https://k6.io");
+ check(res, {
+ "status code is 200": (res) => res.status == 200,
+ });
+ });
+ group("features page", function() {
+ let res = http.get("https://k6.io/features");
+ check(res, {
+ "status code is 200": (res) => res.status == 200,
+ "h1 message is correct": (res) => res.html("h1").text().startsWith("Simple yet realistic load testing"),
+ });
+ });
+ });
+};
+```
+
+
+
+The above code will produce output like shown on the screenshot below,
+with check results presented separately depending on which group they were executed in:
+
diff --git a/src/data/markdown/docs/02 javascript api/02 k6/images/groups.png b/src/data/markdown/docs/02 javascript api/02 k6/images/groups.png
new file mode 100644
index 0000000000..4135d30379
Binary files /dev/null and b/src/data/markdown/docs/02 javascript api/02 k6/images/groups.png differ
diff --git a/src/data/markdown/docs/02 javascript api/02 k6/sleep- t -.md b/src/data/markdown/docs/02 javascript api/02 k6/sleep- t -.md
new file mode 100644
index 0000000000..91b9a5ebb7
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/02 k6/sleep- t -.md
@@ -0,0 +1,29 @@
+---
+title: "sleep( t )"
+description: "Suspends VU execution for the specified duration."
+---
+Suspend VU execution for the specified duration.
+
+| Parameter | Type | Description |
+|-----------|--------|-----------------------|
+| t | number | Duration, in seconds. |
+
+
+### Example
+
+Fetching two different pages with a 0-30 second random sleep in between:
+
+
diff --git a/src/data/markdown/docs/02 javascript api/03 k6-crypto.md b/src/data/markdown/docs/02 javascript api/03 k6-crypto.md
new file mode 100644
index 0000000000..bec391b74f
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/03 k6-crypto.md
@@ -0,0 +1,5 @@
+---
+title: "k6/crypto"
+excerpt: ""
+---
+The k6/crypto module provides common hashing functionality available in the GoLang [crypto](https://golang.org/pkg/crypto/) package.
diff --git a/src/data/markdown/docs/02 javascript api/03 k6-crypto/01 Hasher.md b/src/data/markdown/docs/02 javascript api/03 k6-crypto/01 Hasher.md
new file mode 100644
index 0000000000..418727a0c4
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/03 k6-crypto/01 Hasher.md
@@ -0,0 +1,37 @@
+---
+title: "Hasher"
+category: "k6api-class"
+description: "Object returned by crypto.createHash(). It allows adding more data to be hashed and to extract digests along the way."
+---
+This object is returned by [crypto.createHash()](/javascript-api/k6-crypto/createhash-algorithm)
+and allows the user to successively add more string data to be hashed, and to extract digests along the way.
+
+| Name | Type | Description |
+|------|------|-------------|
+| Hasher.update(string) | function | Add more data to the string we want to create a hash of. Takes one string argument, which is the new data we want to add. |
+| Hasher.digest(string) | function | Return a digest from the data added (using update()) to the Hasher object so far. Takes one string argument, which is the encoding format to return. This can be either "hex" or "base64". |
+
+### Example
+
+
+
+The above code sample should produce this in its output:
+
+```bash
+INFO[0000] 7509e5bda0c762d2bac7f90d758b5b2263fa01ccbc542ab5e3df163be08e6ca9
+INFO[0000] 7509e5bda0c762d2bac7f90d758b5b2263fa01ccbc542ab5e3df163be08e6ca9
+```
diff --git a/src/data/markdown/docs/02 javascript api/03 k6-crypto/createHMAC- algorithm- secret -.md b/src/data/markdown/docs/02 javascript api/03 k6-crypto/createHMAC- algorithm- secret -.md
new file mode 100644
index 0000000000..8f25a9db51
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/03 k6-crypto/createHMAC- algorithm- secret -.md
@@ -0,0 +1,42 @@
+---
+title: "createHMAC( algorithm, secret )"
+description: "Create an HMAC hashing object, allowing the user to add data to hash multiple times, and extract hash digests along the way."
+---
+
+Creates a HMAC hashing object that can then be fed with data repeatedly, and from which you can extract a signed hash digest whenever you want.
+
+| Parameter | Type | Description |
+| --------- | :----: | :---------------------------------------------------------------------------------------------------------------------------------- |
+| algorithm | string | The hashing algorithm to use. One of `md4`, `md5`, `sha1`, `sha256`, `sha384`, `sha512`, `sha512_224`, `sha512_256` or `ripemd160`. |
+| secret | string | A shared secret used to sign the data. |
+
+### Returns
+
+| Type | Description |
+| ------ | :------------------------------------------------------- |
+| object | A [Hasher](/javascript-api/k6-crypto/hasher) object. |
+
+### Example
+
+
+
+```javascript
+import crypto from 'k6/crypto';
+
+export default function() {
+ console.log(crypto.hmac('sha256', 'a secret', 'my data', 'hex'));
+ let hasher = crypto.createHMAC('sha256', 'a secret');
+ hasher.update('my ');
+ hasher.update('data');
+ console.log(hasher.digest('hex'));
+}
+```
+
+
+
+The above script should result in the following being printed during execution:
+
+```shell
+INFO[0000] 82f669c8fde13aef6d6977257588dc4953dfac505428f8fd6b52e19cd96d7ea5
+INFO[0000] 82f669c8fde13aef6d6977257588dc4953dfac505428f8fd6b52e19cd96d7ea5
+```
diff --git a/src/data/markdown/docs/02 javascript api/03 k6-crypto/createHash- algorithm -.md b/src/data/markdown/docs/02 javascript api/03 k6-crypto/createHash- algorithm -.md
new file mode 100644
index 0000000000..3bbb9e35fc
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/03 k6-crypto/createHash- algorithm -.md
@@ -0,0 +1,41 @@
+---
+title: "createHash( algorithm )"
+description: "Create a Hasher object, allowing the user to add data to hash multiple times, and extract hash digests along the way."
+---
+
+Creates a hashing object that can then be fed with data repeatedly, and from which you can extract a hash digest whenever you want.
+
+| Parameter | Type | Description |
+| --------- | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| algorithm | string | The name of the hashing algorithm you want to use. Can be any one of "md4", "md5", "sha1", "sha256", "sha384", "sha512", "sha512_224", "sha512_256", "ripemd160". |
+
+### Returns
+
+| Type | Description |
+| ------ | -------------------------------------------------------- |
+| object | A [Hasher](/javascript-api/k6-crypto/hasher) object. |
+
+### Example
+
+
+
+The above script should result in the following being printed during execution:
+
+```bash
+INFO[0000] 7509e5bda0c762d2bac7f90d758b5b2263fa01ccbc542ab5e3df163be08e6ca9
+INFO[0000] 7509e5bda0c762d2bac7f90d758b5b2263fa01ccbc542ab5e3df163be08e6ca9
+```
diff --git a/src/data/markdown/docs/02 javascript api/03 k6-crypto/hmac- algorithm- secret- data- outputEncoding -.md b/src/data/markdown/docs/02 javascript api/03 k6-crypto/hmac- algorithm- secret- data- outputEncoding -.md
new file mode 100644
index 0000000000..a9f19506f2
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/03 k6-crypto/hmac- algorithm- secret- data- outputEncoding -.md
@@ -0,0 +1,44 @@
+---
+title: 'hmac( algorithm, secret, data, outputEncoding )'
+description: 'Use HMAC to sign an input string.'
+---
+
+Use [HMAC](https://en.wikipedia.org/wiki/Hash-based_message_authentication_code) to sign a piece of data using a shared secret.
+
+| Parameter | Type | Description |
+| -------------- | :----: | :---------------------------------------------------------------------------------------------------------------------------------- |
+| algorithm | string | The hashing algorithm to use. One of `md4`, `md5`, `sha1`, `sha256`, `sha384`, `sha512`, `sha512_224`, `sha512_256` or `ripemd160`. |
+| secret | string | A shared secret used to sign the data. |
+| data | string | The data to sign. |
+| outputEncoding | string | Describes what type of encoding to use for the hash value. Can be "base64" or "hex". |
+
+### Returns
+
+| Type | Description |
+| ------ | ------------------------------ |
+| string | The string-encoded hash digest |
+
+### Example
+
+
+
+The above script should result in the following being printed during execution:
+
+```shell
+INFO[0000] 3363b72840acd5f49f922fef598ee85d
+```
diff --git a/src/data/markdown/docs/02 javascript api/03 k6-crypto/md5- input- outputEncoding -.md b/src/data/markdown/docs/02 javascript api/03 k6-crypto/md5- input- outputEncoding -.md
new file mode 100644
index 0000000000..ef3dd38124
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/03 k6-crypto/md5- input- outputEncoding -.md
@@ -0,0 +1,39 @@
+---
+title: "md5( input, outputEncoding )"
+description: "Use MD5 to hash an input string."
+---
+Use [md5](https://golang.org/pkg/crypto/md5/) to hash an input string.
+
+| Parameter | Type | Description |
+| --------- |------|-------------|
+| input | string | The input string to hash. |
+| outputEncoding | string | Describes what type of encoding to use for the hash value. Can be "base64" or "hex". |
+
+
+### Returns
+
+| Type | Description |
+|------|-------------|
+| string | The string-encoded hash digest. |
+
+
+### Example
+
+
+
+The above script should result in the following being printed during execution:
+
+```shell
+INFO[0000] fc3ff98e8c6a0d3087d515c0473f8677
+```
diff --git a/src/data/markdown/docs/02 javascript api/03 k6-crypto/ripemd160- input- outputEncoding -.md b/src/data/markdown/docs/02 javascript api/03 k6-crypto/ripemd160- input- outputEncoding -.md
new file mode 100644
index 0000000000..a349241843
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/03 k6-crypto/ripemd160- input- outputEncoding -.md
@@ -0,0 +1,39 @@
+---
+title: "ripemd160( input, outputEncoding )"
+description: "Use RIPEMD-160 to hash an input string."
+---
+Use [ripemd160](https://godoc.org/golang.org/x/crypto/ripemd160) to hash an input string.
+
+| Parameter | Type | Description |
+| --------- |------|-------------|
+| input | string | The input string to hash. |
+| outputEncoding | string | Describes what type of encoding to use for the hash value. Can be "base64" or "hex". |
+
+
+### Returns
+
+| Type | Description |
+|------|-------------|
+| string | The string-encoded hash digest. |
+
+
+### Example
+
+
+
+The above script should result in the following being printed during execution:
+
+```shell
+INFO[0000] 595b5926068b4828fb1c27db21281e31118b8475cb6c3ceeb09be7b685414d5f
+```
diff --git a/src/data/markdown/docs/02 javascript api/04 k6-encoding.md b/src/data/markdown/docs/02 javascript api/04 k6-encoding.md
new file mode 100644
index 0000000000..b11cf98df9
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/04 k6-encoding.md
@@ -0,0 +1,5 @@
+---
+title: "k6/encoding"
+---
+The encoding module provides [base64](https://en.wikipedia.org/wiki/Base64)
+encoding/decoding as defined by [RFC4648](https://tools.ietf.org/html/rfc4648).
diff --git a/src/data/markdown/docs/02 javascript api/04 k6-encoding/b64decode- input- -encoding- -.md b/src/data/markdown/docs/02 javascript api/04 k6-encoding/b64decode- input- -encoding- -.md
new file mode 100644
index 0000000000..abf91e140a
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/04 k6-encoding/b64decode- input- -encoding- -.md
@@ -0,0 +1,38 @@
+---
+title: "b64decode( input, [encoding] )"
+description: "Base64 decode a string."
+---
+Decode the passed base64 encoded `input` string into the unencoded original string.
+
+| Parameter | Type | Description |
+|---------------------|--------|------------------------------|
+| input | string | The string to base64 decode. |
+| encoding (optional) | string | The base64 encoding to use. Available options are: - **"std"**: the standard encoding with `=` padding chars and `+` and `/` characters in encoding alphabet. This is the default. - **"rawstd"**: like `std` but without `=` padding characters. - **"url"**: URL safe version of `std`, encoding alphabet doesn't contain `+` and `/` characters, but rather `-` and `_` characters. - **"rawurl"**: like `url` but without `=` padding characters. |
+
+
+### Returns
+
+| Type | Description |
+|--------|---------------------------------------------------|
+| string | The base64 decoded version of the `input` string. |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/04 k6-encoding/b64encode- input- -encoding- -.md b/src/data/markdown/docs/02 javascript api/04 k6-encoding/b64encode- input- -encoding- -.md
new file mode 100644
index 0000000000..207d6cf567
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/04 k6-encoding/b64encode- input- -encoding- -.md
@@ -0,0 +1,37 @@
+---
+title: "b64encode( input, [encoding] )"
+description: "Base64 encode a string."
+---
+
+| Parameter | Type | Description |
+|-----------|--------|------------------------------|
+| input | string | The string to base64 encode. |
+| encoding (optional) | string | The base64 encoding to use. Available options are: - **"std"**: the standard encoding with `=` padding chars and `+` and `/` characters in encoding alphabet. This is the default. - **"rawstd"**: like `std` but without `=` padding characters. - **"url"**: URL safe version of `std`, encoding alphabet doesn't contain `+` and `/` characters, but rather `-` and `_` characters. - **"rawurl"**: like `url` but without `=` padding characters. |
+
+
+### Returns
+
+| Type | Description |
+|--------|---------------------------------------------------|
+| string | The base64 encoded version of the `input` string. |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html.md b/src/data/markdown/docs/02 javascript api/05 k6-html.md
new file mode 100644
index 0000000000..e55e056400
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html.md
@@ -0,0 +1,4 @@
+---
+title: "k6/html"
+---
+The k6/html module contains functionality for HTML parsing.
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection.md
new file mode 100644
index 0000000000..80bf6f885b
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection.md
@@ -0,0 +1,66 @@
+---
+title: 'Selection'
+category: 'k6api-class'
+description: 'A jQuery-like API for accessing HTML DOM elements.'
+---
+
+Represents a set of nodes in a DOM tree.
+
+Selections have a jQuery-compatible API, but with two caveats:
+
+- CSS and screen layout are not processed, thus calls like css() and offset() are unavailable.
+- DOM trees are read-only, you can't set attributes or otherwise modify nodes.
+
+(Note that the read-only nature of the DOM trees is purely to avoid a maintenance burden on code with seemingly no practical use - if a compelling use case is presented, modification can easily be implemented.)
+
+| Method | Description |
+| --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| [Selection.attr(name)](/javascript-api/k6-html/selection/selection-attr-name) | Get the value of an attribute for the first element in the Selection. |
+| [Selection.children([selector])](/javascript-api/k6-html/selection/selection-children-selector) | Get the children of each element in the set of matched elements, optionally filtered by a selector. |
+| [Selection.closest(selector)](/javascript-api/k6-html/selection/selection-closest-selector) | Get the first element that matches the selector by testing the element itself and traversing up through its ancestors |
+| [Selection.contents()](/javascript-api/k6-html/selection/selection-contents) | Get the children of each element in the set of matched elements, including text and comment nodes. |
+| [Selection.data([key])](/javascript-api/k6-html/selection/selection-data-key) | Return the value at the named data store for the first element in the set of matched elements. |
+| [Selection.each(fn)](/javascript-api/k6-html/selection/selection-each-fn) | Iterate and execute a function for each matched element. |
+| [Selection.eq(index)](/javascript-api/k6-html/selection/selection-eq-index) | Reduce the set of matched elements to the one at the specified index. |
+| [Selection.filter(selector)](/javascript-api/k6-html/selection/selection-filter-selector) | Reduce the set of matched elements to those that match the selector or pass the function's test. |
+| [Selection.find(selector)](/javascript-api/k6-html/selection/selection-find-selector) | Find the selection descendants, filtered by a selector. |
+| [Selection.first()](/javascript-api/k6-html/selection/selection-first) | Reduce the set of matched elements to the first in the set. |
+| [Selection.get(index)](/javascript-api/k6-html/selection/selection-get-index) | Retrieve the [Element (k6/html)](/javascript-api/k6-html/element) matched by the selector |
+| [Selection.has(selector)](/javascript-api/k6-html/selection/selection-has-selector) | Reduce the set of matched elements to those that have a descendant that matches the selector |
+| [Selection.html()](/javascript-api/k6-html/selection/selection-html) | Get the HTML contents of the first element in the set of matched elements |
+| [Selection.is(selector)](/javascript-api/k6-html/selection/selection-is-selector) | Check the current matched set of elements against a selector or element and return true if at least one of these elements matches the given arguments. |
+| [Selection.last()](/javascript-api/k6-html/selection/selection-last) | Reduce the set of matched elements to the final one in the set. |
+| [Selection.map(fn)](/javascript-api/k6-html/selection/selection-map-fn) | Pass each element in the current matched set through a function, producing a new Array containing the return values. |
+| [Selection.nextAll([selector])](/javascript-api/k6-html/selection/selection-nextall-selector) | Get all following siblings of each element in the set of matched elements, optionally filtered by a selector. |
+| [Selection.next([selector])](/javascript-api/k6-html/selection/selection-next-selector) | Get the immediately following sibling of each element in the set of matched element |
+| [Selection.nextUntil([selector], [filter])](/javascript-api/k6-html/selection/selection-nextuntil-selector-filter) | Get all following siblings of each element up to but not including the element matched by the selector. |
+| [Selection.not(selector)](/javascript-api/k6-html/selection/selection-not-selector) | Remove elements from the set of matched elements |
+| [Selection.parent([selector])](/javascript-api/k6-html/selection/selection-parent-selector) | Get the parent of each element in the current set of matched elements, optionally filtered by a selector. |
+| [Selection.parents([selector])](/javascript-api/k6-html/selection/selection-parents-selector) | Get the ancestors of each element in the current set of matched elements, optionally filtered by a selector. |
+| [Selection.parentsUntil([selector], [filter])](/javascript-api/k6-html/selection/selection-parentsuntil-selector-filter) | Get the ancestors of each element in the current set of matched elements, up to but not including the element matched by the selector. |
+| [Selection.prevAll([selector])](/javascript-api/k6-html/selection/selection-prevall-selector) | Get all preceding siblings of each element in the set of matched elements, optionally filtered by a selector. |
+| [Selection.prev([selector])](/javascript-api/k6-html/selection/selection-prev-selector) | Get the immediately preceding sibling of each element in the set of matched elements. |
+| [Selection.prevUntil([selector], [filter])](/javascript-api/k6-html/selection/selection-prevuntil-selector-filter) | Get all preceding siblings of each element up to but not including the element matched by the selector. |
+| [Selection.size()](/javascript-api/k6-html/selection/selection-size) | Return the number of elements in the Selection. |
+| [Selection.slice(start [, end])](/javascript-api/k6-html/selection/selection-slice-start-end) | Reduce the set of matched elements to a subset specified by a range of indices. |
+| [Selection.text()](/javascript-api/k6-html/selection/selection-text) | Get the text content of the selection. |
+| [Selection.toArray()](/javascript-api/k6-html/selection/selection-toarray) | Retrieve all the elements contained in the Selection, as an array. |
+| [Selection.val()](/javascript-api/k6-html/selection/selection-val) | Get the current value of the first element in the set of matched elements. |
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-attr-name-.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-attr-name-.md
new file mode 100644
index 0000000000..02600d99cd
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-attr-name-.md
@@ -0,0 +1,36 @@
+---
+title: "Selection.attr(name)"
+excerpt: ""
+---
+Get the value of an attribute for the first element in the Selection.
+Mimics [jquery.attr](https://api.jquery.com/attr/)
+
+
+| Parameter | Type | Description |
+| ----------| ---- | ----------- |
+| name | string | The name of the attribute to get |
+
+
+### Returns
+
+| Type | Description |
+| ---- | ----------- |
+| string | The value of the attribute |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-children--selector--.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-children--selector--.md
new file mode 100644
index 0000000000..8a5e1b7c3e
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-children--selector--.md
@@ -0,0 +1,58 @@
+---
+title: "Selection.children([selector])"
+excerpt: ""
+---
+Get the children of each element in the set of matched elements, optionally filtered by a selector.
+Mimics [jquery.children](https://api.jquery.com/children/)
+
+| Parameter | Type | Description |
+| --------- | ---- | ----------- |
+| selector (optional) | string | A string containing a selector expression to match elements against. |
+
+
+### Returns
+
+| Type | Description |
+| ---- | ----------- |
+| [Selection](/javascript-api/k6-html/selection) | The children Selection. |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-closest-selector-.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-closest-selector-.md
new file mode 100644
index 0000000000..b98f9b3f8e
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-closest-selector-.md
@@ -0,0 +1,57 @@
+---
+title: "Selection.closest(selector)"
+excerpt: ""
+---
+For each element in the set, get the first element that matches the selector by testing the element itself and traversing up through its ancestors in the DOM tree.
+Mimics [jquery.closest](https://api.jquery.com/closest/)
+
+| Parameter | Type | Description |
+| --------- | ---- | ----------- |
+| selector | string | A string containing a selector expression to match elements against |
+
+
+### Returns
+
+| Type | Description |
+| ---- | ----------- |
+| [Selection](/javascript-api/k6-html/selection) | Selection. |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-contents--.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-contents--.md
new file mode 100644
index 0000000000..2f06e4bf51
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-contents--.md
@@ -0,0 +1,54 @@
+---
+title: "Selection.contents()"
+excerpt: ""
+---
+Get the children of each element in the set of matched elements, including text and comment nodes.
+Mimics [jquery.contents](https://api.jquery.com/contents/).
+
+### Returns
+
+| Type | Description |
+| ---- | ----------- |
+| [Selection](/javascript-api/k6-html/selection) | Selection. |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-data--key--.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-data--key--.md
new file mode 100644
index 0000000000..db5912656d
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-data--key--.md
@@ -0,0 +1,44 @@
+---
+title: "Selection.data([key])"
+excerpt: ""
+---
+Return the value at the named data store for the first element in the set of matched elements.
+Mimics [jquery.data](https://api.jquery.com/data/)
+
+| Parameter | Type | Description |
+| --------- | ---- | ----------- |
+| key (optional) | string | A string naming the piece of data to set. |
+
+
+### Returns
+
+| Type | Description |
+| ---- | ----------- |
+| string | The value at the named data store. |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-each-fn-.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-each-fn-.md
new file mode 100644
index 0000000000..1943debc3b
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-each-fn-.md
@@ -0,0 +1,52 @@
+---
+title: "Selection.each(fn)"
+excerpt: ""
+---
+Iterate over a [Selection](/javascript-api/k6-html/selection), executing a function for each matched element.
+Mimics [jquery.each](https://api.jquery.com/each/)
+
+
+| Parameter | Type | Description |
+| --------- | ---- | ----------- |
+| fn | function | A function to iterate all the Elements of the Collection. |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-eq-index-.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-eq-index-.md
new file mode 100644
index 0000000000..7a3e3c3e14
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-eq-index-.md
@@ -0,0 +1,62 @@
+---
+title: "Selection.eq(index)"
+excerpt: ""
+---
+Reduce the set of matched elements to the one at the specified index.
+Mimics [jquery.eq](https://api.jquery.com/eq/).
+
+
+| Parameter | Type | Description |
+| --------- | ---- | ----------- |
+| index | Number | An integer indicating the 0-based position of the element. |
+
+
+### Returns
+
+| Type | Description |
+| ---- | ----------- |
+| [Selection](/javascript-api/k6-html/selection) | A Selection. |
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-filter-selector-.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-filter-selector-.md
new file mode 100644
index 0000000000..6759946836
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-filter-selector-.md
@@ -0,0 +1,71 @@
+---
+title: "Selection.filter(selector)"
+excerpt: ""
+---
+Reduce the set of matched elements to those that match the selector or pass the function's test.
+Mimics [jquery.filter](https://api.jquery.com/filter/)
+
+
+| Parameter | Type | Description |
+| --------- | ---- | ----------- |
+| selector | function | A function used as a test for each element in the set. |
+| selector | string | A string containing a selector expression to match elements against. |
+| selector | [Selection](/javascript-api/k6-html/selection) | A selection to match elements against. |
+
+
+### Returns
+
+| Type | Description |
+| ---- | ----------- |
+| [Selection](/javascript-api/k6-html/selection) | The filter selection. |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-first--.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-first--.md
new file mode 100644
index 0000000000..9ba84180d7
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-first--.md
@@ -0,0 +1,55 @@
+---
+title: "Selection.first()"
+excerpt: ""
+---
+Reduce the set of matched elements to the first in the set.
+Mimics [jquery.first](https://api.jquery.com/first/).
+
+
+### Returns
+
+| Type | Description |
+| ---- | ----------- |
+| [Selection](/javascript-api/k6-html/selection) | The first element of the Selection. |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-html--.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-html--.md
new file mode 100644
index 0000000000..b7caa8a559
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-html--.md
@@ -0,0 +1,55 @@
+---
+title: "Selection.html()"
+excerpt: ""
+---
+Get the HTML contents of the first element in the set of matched elements.
+Mimics [jquery.html](https://api.jquery.com/html/)
+
+### Returns
+
+
+| Type | Description |
+| ---- | ----------- |
+| string | The HTML content of the first element in the set of matched elements. |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-is-selector-.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-is-selector-.md
new file mode 100644
index 0000000000..4d240143b6
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-is-selector-.md
@@ -0,0 +1,74 @@
+---
+title: "Selection.is(selector)"
+excerpt: ""
+---
+Check the current matched set of elements against a selector or element and return true if at least one of these elements matches the given arguments.
+Mimics [jquery.is](https://api.jquery.com/is/)
+
+
+| Parameter | Type | Description |
+| --------- | ---- | ----------- |
+| selector | function | A function used as a test for each element in the set |
+| selector | string | A string containing a selector expression to match elements against. |
+| selector | [Selection](/javascript-api/k6-html/selection) | A selection. |
+
+
+### Returns
+
+| Type | Description |
+| ---- | ----------- |
+| [Selection](/javascript-api/k6-html/selection) | The filter selection. |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-last--.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-last--.md
new file mode 100644
index 0000000000..533ec9311a
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-last--.md
@@ -0,0 +1,54 @@
+---
+title: "Selection.last()"
+excerpt: ""
+---
+Reduce the set of matched elements to the final one in the set.
+Mimics [jquery.last](https://api.jquery.com/last/).
+
+### Returns
+
+| Type | Description |
+| ---- | ----------- |
+| [Selection](/javascript-api/k6-html/selection) | The final element of the Selection. |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-map-fn-.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-map-fn-.md
new file mode 100644
index 0000000000..53e22f7461
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-map-fn-.md
@@ -0,0 +1,61 @@
+---
+title: "Selection.map(fn)"
+excerpt: ""
+---
+Pass each element in the current matched set through a function, producing a new Array containing the return values.
+Mimics [jquery.each](https://api.jquery.com/each/)
+
+
+| Parameter | Type | Description |
+| --------- | ---- | ----------- |
+| fn | function | A function to iterate all the Elements of the Collection. |
+
+
+### Returns
+
+| Type | Description |
+| ---- | ----------- |
+| Array | The array containing the return values. |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-nextAll--selector--.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-nextAll--selector--.md
new file mode 100644
index 0000000000..10adeaea23
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-nextAll--selector--.md
@@ -0,0 +1,49 @@
+---
+title: "Selection.nextAll([selector])"
+---
+Get all following siblings of each element in the set of matched elements, optionally filtered by a selector.
+Mimics [jquery.nextAll](https://api.jquery.com/nextAll/).
+
+| Parameter | Type | Description |
+| --------- | ---- | ----------- |
+| selector (optional) | string | A string containing a selector expression to match elements against |
+
+
+### Returns
+
+| Type | Description |
+| ---- | ----------- |
+| [Selection](/javascript-api/k6-html/selection) | A Selection. |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-nextUntil-selector-filter.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-nextUntil-selector-filter.md
new file mode 100644
index 0000000000..a0e285f77a
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-nextUntil-selector-filter.md
@@ -0,0 +1,60 @@
+---
+title: "Selection.nextUntil([selector], [filter])"
+---
+Get all following siblings of each element up to but not including the element matched by the selector.
+Mimics [jquery.nextUntil](https://api.jquery.com/nextUntil/)
+
+| Parameter | Type | Description |
+| --------- | ---- | ----------- |
+| selector (optional) | string \| [Selection](/javascript-api/k6-html/selection) \| `null` | A selector expression or object to match elements against. |
+| filter (optional) | string \| `null` | A selector expression to filter matched elements. |
+
+
+### Returns
+
+| Type | Description |
+| ---- | ----------- |
+| [Selection](/javascript-api/k6-html/selection) | A Selection. |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-not-selector-.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-not-selector-.md
new file mode 100644
index 0000000000..e4eea17442
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-not-selector-.md
@@ -0,0 +1,66 @@
+---
+title: "Selection.not(selector)"
+excerpt: ""
+---
+Remove elements from the set of matched elements.
+Mimics [jquery.not](https://api.jquery.com/not/)
+
+
+| Parameter | Type | Description |
+| --------- | ---- | ----------- |
+| selector | string | A string containing a selector expression to match elements against. |
+| selector | function | A function used as a test for each element in the set. |
+
+
+### Returns
+
+| Type | Description |
+| ---- | ----------- |
+| [Selection](/javascript-api/k6-html/selection) | A Selection. |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-parentsUntil-selector-filter.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-parentsUntil-selector-filter.md
new file mode 100644
index 0000000000..84781202cc
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-parentsUntil-selector-filter.md
@@ -0,0 +1,60 @@
+---
+title: "Selection.parentsUntil([selector], [filter])"
+---
+Get the ancestors of each element in the current set of matched elements, up to but not including the element matched by the selector.
+Mimics [jquery.parentsUntil](https://api.jquery.com/parentsUntil/)
+
+| Parameter | Type | Description |
+| --------- | ---- | ----------- |
+| selector (optional) | string \| [Selection](/javascript-api/k6-html/selection) \| `null` | A selector expression or object to match elements against. |
+| filter (optional) | string \| `null` | A selector expression to filter matched elements. |
+
+
+### Returns
+
+| Type | Description |
+| ---- | ----------- |
+| [Selection](/javascript-api/k6-html/selection) | A Selection. |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-serialize--.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-serialize--.md
new file mode 100644
index 0000000000..a646e4b6e7
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-serialize--.md
@@ -0,0 +1,38 @@
+---
+title: "Selection.serialize()"
+excerpt: ""
+---
+Encode a set of form elements as a string in standard URL-encoded notation for submission.
+Mimics [jquery.serialize](https://api.jquery.com/serialize/)
+
+### Returns
+
+| Type | Description |
+| ---- | ----------- |
+| string | The URL-encoded representation of the matched form or form elements. |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-serializeArray--.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-serializeArray--.md
new file mode 100644
index 0000000000..571ae1d3f5
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-serializeArray--.md
@@ -0,0 +1,39 @@
+---
+title: "Selection.serializeArray()"
+excerpt: ""
+---
+Encode a set of form elements as an array of names and values (`[{ name: "name", value: "value" }, ...]`).
+Mimics [jquery.serializeArray](https://api.jquery.com/serializeArray/)
+
+
+### Returns
+
+| Type | Description |
+| ---- | ----------- |
+| array | Array of names and values of the matched form or form elements. |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-serializeObject--.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-serializeObject--.md
new file mode 100644
index 0000000000..9754e5781a
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-serializeObject--.md
@@ -0,0 +1,37 @@
+---
+title: "Selection.serializeObject()"
+excerpt: ""
+---
+Encode a set of form elements as an object (`{ "inputName": "value", "checkboxName": "value" }`).
+
+### Returns
+
+| Type | Description |
+| ---- | ----------- |
+| object | Object representation of the matched form or form elements, key is field name and value is field value. |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-size--.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-size--.md
new file mode 100644
index 0000000000..7650edc8dc
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-size--.md
@@ -0,0 +1,55 @@
+---
+title: "Selection.size()"
+excerpt: ""
+---
+Return the number of elements in the Selection.
+Mimics [jquery.size](https://api.jquery.com/size/)
+
+
+### Returns
+
+| Type | Description |
+| ---- | ----------- |
+| Number | The number of elements in the Selection. |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-slice-start -- end--.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-slice-start -- end--.md
new file mode 100644
index 0000000000..5955b78b3a
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-slice-start -- end--.md
@@ -0,0 +1,65 @@
+---
+title: "Selection.slice(start [, end])"
+excerpt: ""
+---
+Reduce the set of matched elements to a subset specified by a range of indices.
+Mimics [jquery.slice](https://api.jquery.com/slice/)
+
+
+| Parameter | Type | Description |
+| --------- | ---- | ----------- |
+| start | Number | An integer indicating the 0-based position at which the elements begin to be selected. |
+| end | Number | An integer indicating the 0-based position at which the elements stop being selected. |
+| selector | [Selection](/javascript-api/k6-html/selection) | A selection. |
+
+
+### Returns
+
+| Type | Description |
+| ---- | ----------- |
+| [Selection](/javascript-api/k6-html/selection) | The new selection. |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-val--.md b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-val--.md
new file mode 100644
index 0000000000..2727050e69
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/50 Selection/Selection-val--.md
@@ -0,0 +1,56 @@
+---
+title: "Selection.val()"
+excerpt: ""
+---
+Get the current value of the first element in the set of matched elements.
+Mimics [jquery.val](https://api.jquery.com/val/).
+
+
+### Returns
+
+| Type | Description |
+| ---- | ----------- |
+| string | The value of the first element in the set of matched elements. |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/05 k6-html/Element -k6-html-.md b/src/data/markdown/docs/02 javascript api/05 k6-html/Element -k6-html-.md
new file mode 100644
index 0000000000..073927ae7f
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/05 k6-html/Element -k6-html-.md
@@ -0,0 +1,162 @@
+---
+title: "Element"
+category: "k6api-class"
+description: "An HTML DOM element as returned by the Selection API."
+---
+Represents a DOM element matched by a [Selection](/javascript-api/k6-html/selection),
+and provides an API to inspect the element content.
+
+Use [Selection.get(index)](/javascript-api/k6-html/selection/selection-get-index) to return an Element object.
+
+The Element object provides a similar API to the [DOM Element API](https://developer.mozilla.org/en-US/Web/API/Element) to retrieve element information.
+
+| Method | Description |
+|------------------------|--------------------------------------------------------------------|
+| nodeName | The name of the element. |
+| nodeType | The type of the element. |
+| nodeValue | The element value. |
+| id | The id of the element. |
+| innerHTML | Is a DOMString representing the markup of the element's content. |
+| textContent | The element content. |
+| ownerDocument | [Element](/javascript-api/k6-html/element) |
+| attributes | An array of attributes. |
+| firstChild | [Element](/javascript-api/k6-html/element) |
+| lastChild | [Element](/javascript-api/k6-html/element) |
+| childElementCount | The number of children elements. |
+| firstElementChild | [Element](/javascript-api/k6-html/element) |
+| lastElementChild | [Element](/javascript-api/k6-html/element) |
+| previousSibling | [Element](/javascript-api/k6-html/element) |
+| nextSibling | [Element](/javascript-api/k6-html/element) |
+| previousElementSibling | [Element](/javascript-api/k6-html/element) |
+| nextElementSibling | [Element](/javascript-api/k6-html/element) |
+| parentElement | [Element](/javascript-api/k6-html/element) |
+| parentNode | [Element](/javascript-api/k6-html/element) |
+| childNodes | Array of [Element](/javascript-api/k6-html/element) |
+| children | Array of [Element](/javascript-api/k6-html/element) |
+| classList | An array of class names. |
+| className | The class name string |
+| lang | The value of the lang attribute. |
+| toString | The element string representation. |
+| hasAttribute | Boolean |
+| getAttribute | getAttributeNode |
+| hasAttributes | Boolean |
+| hasChildNodes | Boolean |
+| isSameNode | Boolean |
+| isEqualNode | Boolean |
+| getElementsByClassName | Return an array of [Element](/javascript-api/k6-html/element). |
+| getElementsByTagName | Return an array of [Element](/javascript-api/k6-html/element). |
+| querySelector | Returns the first [Element](/javascript-api/k6-html/element) which matches the specified selector string relative to the element |
+| querySelectorAll | Returns all the [Element](/javascript-api/k6-html/element) which matches the specified selector string relative to the element |
+| contains | |
+| matches | Returns a Boolean indicating whether or not the element would be selected by the specified selector string|
+| namespaceURI | The namespace URI of the element. |
+| isDefaultNamespace | Returns a Boolean indicating whether the element has the default namespace.|
+
+
+Additionally, Element can provide more methods depending on the Element type.
+
+- **AnchorElement**: hash, host, hostname, port, username, password, origin, pathname, protocol, relist, search, text.
+
+- **ButtonElement**: form, formAction, formEnctype, formMethod, formNoValidate, formTarget, labels, name, value.
+
+- **CanvasElement**: width, height
+
+- **DataListElement**: options
+
+- **FieldSetElement**: elements, type, form
+
+- **FormElement**: elements, length, method
+
+- **InputElement**: form
+
+- **LabelElement**: control, form
+
+- **LegendElement**: form
+
+- **LinkElement**: relList
+
+- **MapElement**: areas, images
+
+- **ObjectElement**: form
+
+- **OptionElement**: disabled, form, index, label, text, value
+
+- **OutputElement**: value, labels
+
+- **ProgressElement**: max, value, position
+
+- **ScriptElement**: text
+
+- **SelectElement**: form, length, options, selectedOptions, selectedIndex, value
+
+- **StyleElement**: text
+
+- **TableElement**: caption, thead, tbody, tfoot, rows
+
+- **TableCellElement**: cellIndex, colSpan, rowSpan, headers
+
+- **TableRowElement**: cells, colSpan, sectionRowIndex, rowIndex
+
+- **VideoElement**: textTracks
+
+- **TitleElement**: text
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/06 k6-http.md b/src/data/markdown/docs/02 javascript api/06 k6-http.md
new file mode 100644
index 0000000000..671d60548d
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/06 k6-http.md
@@ -0,0 +1,5 @@
+---
+title: 'k6/http'
+---
+
+The k6/http module contains functionality for performing HTTP transactions.
diff --git a/src/data/markdown/docs/02 javascript api/06 k6-http/60 CookieJar.md b/src/data/markdown/docs/02 javascript api/06 k6-http/60 CookieJar.md
new file mode 100644
index 0000000000..ab7e856306
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/06 k6-http/60 CookieJar.md
@@ -0,0 +1,34 @@
+---
+title: "CookieJar (k6/http)"
+category: "k6api-class"
+description: "Used for storing cookies, set by the server and/or added by the client."
+---
+
+_CookieJar_ is an object for storing cookies, set by the server and/or added by the client. As described in the how-to guide on using [Cookies](/using-k6/cookies), k6 handles cookies automatically by default. If you need more control over cookies you can however create your own cookie jar and select it as the active jar (instead of the default one created by k6) for one or more requests.
+
+| Method | Description |
+| ---------------- | ----------- |
+| [cookiesForURL(url)](/javascript-api/k6-http/cookiejar/cookiejar-cookiesforurl-url) | Get Object of cookies where the key is the cookie name and the value is an array. |
+| [set(name, value, [options])](/javascript-api/k6-http/cookiejar/cookiejar-set-name-value-options) | Set a cookie in the jar by specifying name, value and some other optional settings like domain, path etc. |
+
+
+### Example
+
+
+
+```js
+import http from "k6/http";
+import { check } from "k6";
+
+export default function() {
+ let res = http.get("https://httpbin.org/cookies/set?my_cookie=hello%20world", { redirects: 0 });
+ let jar = http.cookieJar();
+ let cookies = jar.cookiesForURL("http://httpbin.org/");
+ check(res, {
+ "has cookie 'my_cookie'": (r) => cookies.my_cookie.length > 0,
+ "cookie has correct value": (r) => cookies.my_cookie[0] === "hello world"
+ });
+}
+```
+
+
diff --git a/src/data/markdown/docs/02 javascript api/06 k6-http/60 CookieJar/CookieJar-cookiesForUrl-url-.md b/src/data/markdown/docs/02 javascript api/06 k6-http/60 CookieJar/CookieJar-cookiesForUrl-url-.md
new file mode 100644
index 0000000000..cd1e931869
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/06 k6-http/60 CookieJar/CookieJar-cookiesForUrl-url-.md
@@ -0,0 +1,40 @@
+---
+title: 'CookieJar.cookiesForUrl(url)'
+excerpt: ''
+---
+
+| Parameter | Type | Description |
+| --------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| url | string | The URL for which to get cookies. |
+
+
+### Returns
+
+| Type | Description |
+| ---- | ----------- |
+| object | Object of cookies where the key is the cookie name and the value is an array. |
+
+
+### Example
+
+
+
+```js
+import http from 'k6/http';
+import { check } from 'k6';
+
+export default function() {
+ let res = http.get(
+ 'https://httpbin.org/cookies/set?my_cookie=hello%20world',
+ { redirects: 0 },
+ );
+ let jar = http.cookieJar();
+ let cookies = jar.cookiesForURL('http://httpbin.org/');
+ check(res, {
+ "has cookie 'my_cookie'": r => cookies.my_cookie.length > 0,
+ 'cookie has correct value': r => cookies.my_cookie[0] === 'hello world',
+ });
+}
+```
+
+
diff --git a/src/data/markdown/docs/02 javascript api/06 k6-http/60 CookieJar/CookieJar-set-name- value- -options--.md b/src/data/markdown/docs/02 javascript api/06 k6-http/60 CookieJar/CookieJar-set-name- value- -options--.md
new file mode 100644
index 0000000000..6ffce5fd61
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/06 k6-http/60 CookieJar/CookieJar-set-name- value- -options--.md
@@ -0,0 +1,40 @@
+---
+title: 'CookieJar.set(name, value, [options])'
+---
+
+Set a cookie in the jar by specifying name, value and some other optional settings like domain, path, etc.
+
+| Parameter | Type | Description |
+| --------- | -------- | ------------ |
+| name | string | Cookie name |
+| value | string | Cookie value |
+| options (optional) | object | Specific cookie settings: `domain`, `path`, `expires`, `max_age`, `secure` and `http_only`. |
+
+
+### Example
+
+
+
+```js
+import http from 'k6/http';
+import { check } from 'k6';
+
+export default function() {
+ let jar = http.cookieJar();
+ jar.set('https://httpbin.org/cookies', 'my_cookie', 'hello world', {
+ domain: 'httpbin.org',
+ path: '/cookies',
+ secure: true,
+ max_age: 600,
+ });
+ let res = http.get('https://httpbin.org/cookies');
+ check(res, {
+ 'has status 200': r => r.status === 200,
+ "has cookie 'my_cookie'": r => r.json().cookies.my_cookie !== null,
+ 'cookie has correct value': r =>
+ r.json().cookies.my_cookie == 'hello world',
+ });
+}
+```
+
+
diff --git a/src/data/markdown/docs/02 javascript api/06 k6-http/61 Response.md b/src/data/markdown/docs/02 javascript api/06 k6-http/61 Response.md
new file mode 100644
index 0000000000..5920e8dd20
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/06 k6-http/61 Response.md
@@ -0,0 +1,74 @@
+---
+title: 'Response (k6/http)'
+category: 'k6api-class'
+description: 'Returned by the http.* methods that generate HTTP requests.'
+---
+
+Response is used by the http.\* methods that generate HTTP request. Those methods return one (or more, in the case of `http.batch()`) Response objects that contain HTTP response contents and performance timing measurements.
+
+Note that in the case of redirects, all the information in the Response object will pertain to the last request (the one that doesn't get redirected).
+
+| Name | Type | Description |
+| ------------------------------------------------------------------------------------------------ | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Response.body` | string | Response body content.
See [Params.responseType](/javascript-api/k6-http/params-k6-http) and [options.discardResponseBodies](/using-k6/options) for how to discard the body when it's not needed (and to save memory) or when handling bodies with binary data. |
+| `Response.cookies` | object | Response cookies. The object properties are the cookie names and the value is an array of cookie objects (with `name`, `value`, `domain`, `path`, `httpOnly`, `secure`, `maxAge` and `expires` fields). |
+| `Response.error` | string | Error message if there was a non-HTTP error while trying to send the request. |
+| `Response.error_code` | number | [Error code](/javascript-api/error-codes) if there was a non-HTTP error or 4xx or 5xx HTTP error it will be set to a specific code that describes the error. (Added in 0.24.0) |
+| `Response.headers` | object | Key-value pairs representing all HTTP headers sent by the server. |
+| `Response.ocsp.produced_at` | number | If a stapled OSCP response was provided by server, the number of milliseconds elapsed since 1 January 1970 00:00:00 UTC, representing the time when this OCSP stapled response was signed by CA (or by CA entrusted OCSP responder) |
+| `Response.ocsp.this_update` | number | If a stapled OSCP response was provided by server, the number of milliseconds elapsed since 1 January 1970 00:00:00 UTC, representing the time at which the status being indicated was known to be correct. |
+| `Response.ocsp.next_update` | number | If a stapled OSCP response was provided by server, the number of milliseconds elapsed since 1 January 1970 00:00:00 UTC, representing the time when this OCSP stapled response will be refreshed with CA (or by CA entrusted OCSP responder). |
+| `Response.ocsp.revocation_reason` | string | The reason for revocation of the certificate (if that is the status), one of the following constants: `http.OCSP_REASON_UNSPECIFIED`, `http.OCSP_REASON_KEY_COMPROMISE`, `http.OCSP_REASON_CA_COMPROMISE`, `http.OCSP_REASON_AFFILIATION_CHANGED`, `http.OCSP_REASON_SUPERSEDED`, `http.OCSP_REASON_CESSATION_OF_OPERATION`, `http.OCSP_REASON_CERTIFICATE_HOLD`, `http.OCSP_REASON_REMOVE_FROM_CRL`, `http.OCSP_REASON_PRIVILEGE_WITHDRAWN` or `http.OCSP_REASON_AA_COMPROMISE`. |
+| `Response.ocsp.revoked_at` | number | If a stapled OSCP response was provided by server, the number of milliseconds elapsed since 1 January 1970 00:00:00 UTC, representing the time when this certificate was revoked (if that is the status). |
+| `Response.ocsp.status` | string | The status of the certificate, one of the following constants: `http.OCSP_STATUS_GOOD`, `http.OCSP_STATUS_REVOKED`, `http.OCSP_STATUS_UNKNOWN` or `http.OCSP_STATUS_SERVER_FAILED`. |
+| `Response.proto` | string | Protocol used to perform the transfer. Possible values are "HTTP/1.0", "HTTP/1.1", or "HTTP/2.0". |
+| `Response.remote_ip` | string | The IP address of the server handling the request. |
+| `Response.remote_port` | number | The port that was connected to on the server side. |
+| `Response.request.body` | string | Request body content. |
+| `Response.request.cookies` | object | Request cookies. The object properties are the cookie names and the value is an array of cookie objects (with `name`, `value` and `replace` fields). |
+| `Response.request.headers` | object | Request headers. |
+| `Response.request.method` | string | Request HTTP method. |
+| `Response.request.url` | string | Request URL. |
+| `Response.status` | number | HTTP status code returned by server. |
+| `Response.timings` | object | Performance timing information for the HTTP request. |
+| `Response.timings.blocked` | float | Containing time (ms) spent blocked before initiating request. |
+| `Response.timings.looking_up` (currently unavailable) | float | Containing time (ms) spent looking up host name in DNS. |
+| `Response.timings.connecting` | float | Containing time (ms) spent setting up TCP connection to host. |
+| `Response.timings.tls_handshaking` | float | Containing time (ms) spent handshaking TLS session with host. |
+| `Response.timings.sending` | float | Containing time (ms) spent sending request. |
+| `Response.timings.waiting` | float | Containing time (ms) spent waiting for server response. |
+| `Response.timings.receiving` | float | Containing time (ms) spent receiving response data. |
+| `Response.timings.duration` | float | Total time for the request (ms). It's equal to `sending + waiting + receiving`, i.e. how long did the remote server take to process the request and respond, without the initial DNS lookup/connection times. |
+| `Response.tls_cipher_suite` | string | If a TLS session was established, the cipher suite that was used. |
+| `Response.tls_version` | string | If a TLS session was established, the version of SSL/TLS that was used. |
+| `Response.url` | string | The URL that was ultimately fetched (i.e. after any potential redirects). |
+| `[Response.clickLink( [params] )](/javascript-api/k6-http/response/response-clicklink-params)` | function | Parses response as HTML, looks for a specific link and does the request-level equivalent of a click on that link. |
+| `Response.html()` | function | Returns an object that supports [Selection.find(selector)](/javascript-api/k6-html/selection/selection-find-selector). |
+| `Response.json([selector])` | function | Parses the response body data as JSON and returns a JS object or array. This call caches the deserialized JSON data, additional calls will return the cached data. An optional selector can be specified to extract a specific part of the data, see [here for selector syntax](https://github.com/tidwall/gjson#path-syntax). |
+| `[Response.submitForm( [params] )](/javascript-api/k6-http/response/response-submitform-params)` | function | Parses response as HTML, parses the specified form (defaults to looking for a "form" element) with option to override fields and then submits form taking form's `method` and `action` into account. |
+
+### Example
+
+
+
+```js
+import { check } from 'k6';
+import http from 'k6/http';
+
+export default function() {
+ let res = http.get('https://k6.io');
+ for (var p in res.headers) {
+ if (res.headers.hasOwnProperty(p)) {
+ console.log(p + ' : ' + res.headers[p]);
+ }
+ }
+ check(res, {
+ 'status is 200': r => r.status === 200,
+ 'caption is correct': r => r.html('h1').text() == 'Example Domain',
+ });
+}
+```
+
+
+
+_A k6 script that will make an HTTP request and print all HTTP response headers_
diff --git a/src/data/markdown/docs/02 javascript api/06 k6-http/61 Response/Response-clickLink- -params- -.md b/src/data/markdown/docs/02 javascript api/06 k6-http/61 Response/Response-clickLink- -params- -.md
new file mode 100644
index 0000000000..b94d9aa5de
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/06 k6-http/61 Response/Response-clickLink- -params- -.md
@@ -0,0 +1,37 @@
+---
+title: 'Response.clickLink( [params] )'
+excerpt: ''
+---
+
+Create and make a request corresponding to a link, found in the HTML of response, being clicked. By default it will look for the first `a` tag with a `href` attribute in the HTML, but this can be overridden using the `selector` option.
+
+This method takes an object argument where the following properties can be set:
+
+| Param | Type | Description |
+| -------- | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| selector | string | A selector string passed to [Selection.find(selector)](/javascript-api/k6-html/selection/selection-find-selector) to locate the link to click. By default this is `"a[href]"`. |
+| params | object | A [Params](/javascript-api/k6-http/params-k6-http) object that will be forwarded to the link click request. Can be used to set headers, cookies etc. |
+
+### Returns
+
+| Type | Description |
+| -------------------------------------------------------- | ----------------------- |
+| [Response](/javascript-api/k6-http/response-k6-http) | The link click response |
+
+### Example
+
+
+
+```js
+import http from 'k6/http';
+
+export default function() {
+ // Request page with links
+ let res = http.get('https://httpbin.org/links/10/0');
+
+ // Now, click the 4th link on the page
+ res = res.clickLink({ selector: 'a:nth-child(4)' });
+}
+```
+
+
diff --git a/src/data/markdown/docs/02 javascript api/06 k6-http/61 Response/Response-submitForm- -params- -.md b/src/data/markdown/docs/02 javascript api/06 k6-http/61 Response/Response-submitForm- -params- -.md
new file mode 100644
index 0000000000..0e35d058eb
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/06 k6-http/61 Response/Response-submitForm- -params- -.md
@@ -0,0 +1,43 @@
+---
+title: 'Response.submitForm( [params] )'
+excerpt: ''
+---
+
+Fill in and submit form found in HTML of response. By default it will look for the first `form` tag in the HTML, but this can be overridden using the `formSelector` option. To set/override the form fields you set properties of an object in the `fields` option.
+
+This method takes an object argument where the following properties can be set:
+
+| Param | Type | Description |
+| -------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| formSelector | string | A selector string passed to [Selection.find(selector)](/javascript-api/k6-html/selection/selection-find-selector) to locate the form to fill in and submit. By default this is `"form"`. |
+| fields | object | The form fields to set/override. The keys are the form fields names and the values are the form field values. |
+| submitSelector | string | A selector string used to locate the submit button in the form. By default this is `'[type="submit"]'`. |
+| params | object | A [Params (k6/http)](/javascript-api/k6-http/params-k6-http) object that will be forwarded to the form submit request. Can be used to set headers, cookies etc. |
+
+### Returns
+
+| Type | Description |
+| ------------------------------------------------------------------ | ------------------------- |
+| [Response (k6/http)](/javascript-api/k6-http/response-k6-http) | The form submit response. |
+
+### Example
+
+
+
+```js
+import http from 'k6/http';
+
+export default function() {
+ // Request page containing a form
+ let res = http.get('https://httpbin.org/forms/post');
+
+ // Now, submit form setting/overriding some fields of the form
+ res = res.submitForm({
+ formSelector: '//form[@action="/post"]',
+ fields: { custname: 'test', extradata: 'test2' },
+ submitSelector: 'mySubmit',
+ });
+}
+```
+
+
diff --git a/src/data/markdown/docs/02 javascript api/06 k6-http/FileData -k6-http-.md b/src/data/markdown/docs/02 javascript api/06 k6-http/FileData -k6-http-.md
new file mode 100644
index 0000000000..fe69c54f78
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/06 k6-http/FileData -k6-http-.md
@@ -0,0 +1,35 @@
+---
+title: "FileData (k6/http)"
+category: "k6api-class"
+description: "Used for wrapping data representing a file when doing multipart requests (file uploads)."
+---
+
+_FileData_ is an object for wrapping data representing a file when doing [multipart requests (file uploads)](/using-k6/multipart-requests-file-uploads). You create it by calling [http.file( data, [filename], [contentType] )](/javascript-api/k6-http/file-data-filename-contenttype).
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| FileData.data | string / bytes | The bytes representing the file contents. |
+| FileData.content_type | string | The content type that will be specified in the multipart request. |
+| FileData.filename | string | The filename that will be specified in the multipart request. |
+
+
+### Example
+
+
+
+```js
+import { sleep } from "k6";
+import { md5 } from "k6/crypto";
+import http from "k6/http";
+
+let binFile = open("/path/to/file.bin", "b");
+
+export default function() {
+ let f = http.file(binFile, "test.bin");
+ console.log(md5(f.data, "hex"));
+ console.log(f.filename);
+ console.log(f.content_type);
+}
+```
+
+
diff --git a/src/data/markdown/docs/02 javascript api/06 k6-http/Params -k6-http-.md b/src/data/markdown/docs/02 javascript api/06 k6-http/Params -k6-http-.md
new file mode 100644
index 0000000000..bd0354e715
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/06 k6-http/Params -k6-http-.md
@@ -0,0 +1,119 @@
+---
+title: 'Params (k6/http)'
+category: 'k6api-class'
+description: 'Used for setting various HTTP request-specific parameters such as headers, cookies, etc.'
+---
+
+_Params_ is an object used by the http.\* methods that generate HTTP requests. _Params_ contains request-specific options like e.g. HTTP headers that should be inserted into the request.
+
+| Name | Type | Description |
+| --------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Params.auth` | string | The authentication method used for the request. It currently supports `digest`, `ntlm`, and `basic` authentication methods. |
+| `Params.cookies` | object | Object with key-value pairs representing request scoped cookies (they won't be added to VU cookie jar) `{cookies: { key: "val", key2: "val2" }}`
You also have the option to say that a request scoped cookie should override a cookie in the VU cookie jar: `{cookies: { key: { value: "val", replace: true }}}` |
+| `Params.headers` | object | Object with key-value pairs representing custom HTTP headers the user would like to add to the request. |
+| `Params.jar` | object | http.CookieJar object to override default VU cookie jar with. Cookies added to request will be sourced from this jar and cookies set by server will be added to this jar. |
+| `Params.redirects` | number | The number of redirects to follow for this request. Overrides the global test option [`maxRedirects`](/using-k6/options). |
+| `Params.tags` | object | Key-value pairs where the keys are names of tags and the values are tag values. Response time metrics generated as a result of the request will have these tags added to them, allowing the user to filter out those results specifically, when looking at results data. |
+| `Params.timeout` | number | Request timeout to use in milliseconds. Default timeout is 60000ms(60 seconds). |
+| `Params.compression` | string | Sets whether the request body should be compressed. If set to `gzip` it will use gzip to compress the body and set the appropriate `Content-Length` and `Content-Encoding` headers.
Possible values: `gzip`, `deflate`, `br`, `zstd`, and any comma-separated combination of them (for stacked compression) |
+| `Params.responseType` | string | ResponseType is used to specify how to treat the body of the response. The three options are: - text: k6 will return it as a string. This might not be what you want in cases of binary data as the conversation to UTF-16 will probably break it. This is also the default if [discardResponseBodies](/using-k6/options) is set to false or not set at all. - `binary`: k6 will return an array of ints/bytes - `none`: k6 will return null as the body. The whole body will be ignored. This is the default when [discardResponseBodies](/using-k6/options) is set to true. |
+
+### Example of custom HTTP headers and tags
+
+_A k6 script that will make an HTTP request with a custom HTTP header and tag results data with a specific tag_
+
+
+
+### Example using http.batch() with Params
+
+Here is another example using [http.batch()](/javascript-api/k6-http/batch-requests) with a `Params` argument:
+
+
+
+### Example of Digest Authentication
+
+Here is one example of how to use the `Params` to Digest Authentication.
+
+
+
+```js
+import http from 'k6/http';
+import { check } from 'k6';
+
+export default function() {
+ // Passing username and password as part of URL plus the auth option will authenticate using HTTP Digest authentication
+ let res = http.get(
+ 'http://user:passwd@httpbin.org/digest-auth/auth/user/passwd',
+ { auth: 'digest' },
+ );
+
+ // Verify response
+ check(res, {
+ 'status is 200': r => r.status === 200,
+ 'is authenticated': r => r.json().authenticated === true,
+ 'is correct user': r => r.json().user === 'user',
+ });
+}
+```
+
+
+Example how to overwrite discardResponseBodies:
+
+### Example of overwrite discardResponseBodies
+
+
+
+```js
+import http from 'k6/http';
+
+export var options = { discardResponseBodies: true };
+export default function() {}
+export function setup() {
+ // Get 10 random bytes in as an array of ints/bytes, without the responseType the body will be null
+ const response = http.get('https://httpbin.org/bytes/10', {
+ responseType: 'binary',
+ });
+ // Print the array. Will look something like `176,61,15,66,233,98,223,196,43,1`
+ console.log(response.body);
+}
+```
+
+
diff --git a/src/data/markdown/docs/02 javascript api/06 k6-http/batch- requests -.md b/src/data/markdown/docs/02 javascript api/06 k6-http/batch- requests -.md
new file mode 100644
index 0000000000..0f85e00b52
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/06 k6-http/batch- requests -.md
@@ -0,0 +1,164 @@
+---
+title: "batch( requests )"
+description: "Issue multiple HTTP requests in parallel (like e.g. browsers tend to do)."
+---
+
+Batch multiple HTTP requests together, to issue them in parallel over multiple TCP connections.
+
+| Parameter | Type | Description |
+| --------- | -------------- | ---------------------------------------------------------------- |
+| requests | array \| object | An array or object containing requests, in string or object form |
+
+When each request is specified as an array, the order of the arguments for each request is as follows:
+
+
+### Returns
+
+| Type | Description |
+| ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| object | An object containing [Response](/javascript-api/k6-http/response-k6-http) objects.
It has integer keys when users pass an array as `requests` and string keys when named requests are used (see below). |
+
+
+| Position | Name | Type | Description |
+| -------- | ---- | ---- | ----------- |
+| 1 | method | string | Mandatory. The HTTP method of the request. One of GET, POST, PUT, PATCH, DELETE, HEAD or OPTION. |
+| 2 | url | string | Mandatory. The URL to request. |
+| 3 | body (optional) | string \| object | The body of the request if relevant. Can be set to `null` if not applicable but you want to set the last `params` argument. |
+| 4 | params (optional) | object | [Params](/javascript-api/k6-http/params-k6-http) like auth, custom headers and tags. |
+
+
+### Example with request as an array
+
+
+
+### Example with request objects
+
+You can also use objects to hold information about a request. Here is an example where we do that in order to send a POST request, plus use custom HTTP headers by adding a [Params](/javascript-api/k6-http/params-k6-http) object to the request:
+
+
+
+```js
+import http from 'k6/http';
+import { check } from 'k6';
+
+export default function() {
+ let req1 = {
+ method: 'GET',
+ url: 'https://httpbin.org/get',
+ };
+ let req2 = {
+ method: 'GET',
+ url: 'https://test.k6.io',
+ };
+ let req3 = {
+ method: 'POST',
+ url: 'https://httpbin.org/post',
+ body: {
+ hello: 'world!',
+ },
+ params: {
+ headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
+ },
+ };
+ let responses = http.batch([req1, req2, req3]);
+ // httpbin.org should return our POST data in the response body, so
+ // we check the third response object to see that the POST worked.
+ check(responses[2], {
+ 'form data OK': res => JSON.parse(res.body)['form']['hello'] == 'world!',
+ });
+}
+```
+
+
+
+_Note that the requests in the example above may happen in any order, or simultaneously. There is no guarantee that e.g. req1 will happen before req2 or req3_
+
+### Example with named requests
+
+Finally, you can also send in named requests by using an object instead of an array as the parameter to http.batch(). In the following example we do this, and we also show that it is possible to mix string URLs and request objects
+
+
+
+```js
+import http from 'k6/http';
+import { check } from 'k6';
+
+export default function() {
+ let requests = {
+ 'front page': 'https://k6.io',
+ 'features page': {
+ method: 'GET',
+ url: 'https://k6.io/features',
+ params: { headers: { 'User-Agent': 'k6' } },
+ },
+ };
+ let responses = http.batch(requests);
+ // when accessing results, we use the name of the request as index
+ // in order to find the corresponding Response object
+ check(responses['front page'], {
+ 'front page status was 200': res => res.status === 200,
+ });
+}
+```
+
+
diff --git a/src/data/markdown/docs/02 javascript api/06 k6-http/cookieJar--.md b/src/data/markdown/docs/02 javascript api/06 k6-http/cookieJar--.md
new file mode 100644
index 0000000000..4f901d2deb
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/06 k6-http/cookieJar--.md
@@ -0,0 +1,24 @@
+---
+title: "cookieJar()"
+description: "Get active HTTP Cookie jar."
+---
+
+Get the active cookie jar.
+
+| Type | Description |
+| ---------------------------------------------------------- | ------------------- |
+| [CookieJar](/javascript-api/k6-http/cookiejar-k6-http) | A CookieJar object. |
+
+### Example
+
+
+
+```js
+import http from 'k6/http';
+
+export default function() {
+ let jar = http.cookieJar();
+}
+```
+
+
diff --git a/src/data/markdown/docs/02 javascript api/06 k6-http/del- url- -body-- -params- -.md b/src/data/markdown/docs/02 javascript api/06 k6-http/del- url- -body-- -params- -.md
new file mode 100644
index 0000000000..aaeb79ab10
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/06 k6-http/del- url- -body-- -params- -.md
@@ -0,0 +1,18 @@
+---
+title: "del( url, [body], [params] )"
+description: "Issue an HTTP DELETE request."
+---
+
+Make a DELETE request.
+
+| Parameter | Type | Description |
+| --------- | ---- | ----------- |
+| url | string | Request URL (e.g. `http://example.com`). |
+| body (optional, discouraged) | string | object | Request body; objects will be `x-www-form-urlencoded`. This is discouraged, because sending a DELETE request with a body has [no defined semantics](https://tools.ietf.org/html/rfc7231#section-4.3.5) and may cause some servers to reject it. |
+| params (optional) | object | [Params](/javascript-api/k6-http/params-k6-http) object containing additional request parameters. |
+
+### Returns
+
+| Type | Description |
+| -------- | --------------------------------------------------------------------- |
+| Response | HTTP [Response](/javascript-api/k6-http/response-k6-http) object. |
diff --git a/src/data/markdown/docs/02 javascript api/06 k6-http/file- data- -filename-- -contentType- -.md b/src/data/markdown/docs/02 javascript api/06 k6-http/file- data- -filename-- -contentType- -.md
new file mode 100644
index 0000000000..48293aaab4
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/06 k6-http/file- data- -filename-- -contentType- -.md
@@ -0,0 +1,40 @@
+---
+title: "file( data, [filename], [contentType] )"
+description: "Create a file object that is used for building multi-part requests."
+---
+
+Create a file object that is used for building [Multipart requests (file uploads)](/using-k6/multipart-requests-file-uploads).
+
+| Parameter | Type | Description |
+| ----------- | -------------- | -------------------------------------------------------------------------------- |
+| data | string / bytes | An array or object containing requests, in string or object form. |
+| filename | string | The filename to specify for this field (or "part") of the multipart request. |
+| contentType | string | The content type to specify for this field (or "part") of the multipart request. |
+
+
+### Returns
+
+| Type | Description |
+| -------- | ------------------------------------------------------------------ |
+| [FileData](/javascript-api/k6-http/filedata-k6-http) | A FileData object. |
+
+### Example
+
+
+
+```js
+import { sleep } from 'k6';
+import { md5 } from 'k6/crypto';
+import http from 'k6/http';
+
+let binFile = open('/path/to/file.bin', 'b');
+
+export default function() {
+ let f = http.file(binFile, 'test.bin');
+ console.log(md5(f.data, 'hex'));
+ console.log(f.filename);
+ console.log(f.content_type);
+}
+```
+
+
+
+```js
+import http from 'k6/http';
+import { check, fail } from 'k6';
+
+export let options = { maxRedirects: 10 };
+
+const baseURL = 'https://dev-li-david.pantheonsite.io';
+
+export default function() {
+ // Fetch the login page, with the login HTML form
+ let res = http.get(baseURL + '/user/login');
+ // Extract hidden value needed to POST form
+ let formBuildID = res.body.match('name="form_build_id" value="(.*)"')[1];
+ // Create an Object containing the form data
+ let formdata = {
+ name: 'testuser1',
+ pass: 'testuser1',
+ form_build_id: formBuildID,
+ form_id: 'user_login',
+ op: 'Log in',
+ };
+ // Use http.request to send login POST request
+ res = http.request('POST', baseURL + '/usr/login', formdata, {
+ headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
+ });
+ // Verify that we ended up on the user page
+ check(res, {
+ 'login succeeded': res => res.url == `${baseURL}/users/testuser1`,
+ }) || fail('login failed');
+}
+```
+
+
diff --git a/src/data/markdown/docs/02 javascript api/07 k6-metrics.md b/src/data/markdown/docs/02 javascript api/07 k6-metrics.md
new file mode 100644
index 0000000000..64dea311c8
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/07 k6-metrics.md
@@ -0,0 +1,45 @@
+---
+title: 'k6/metrics'
+excerpt: 'k6 Custom Metrics API'
+---
+
+The metrics module provides functionality to create [custom metrics](/using-k6/metrics) of various types. All metrics (both the built-in ones and the custom ones) have a type. There are four different metrics types, and they are: `Counter`, `Gauge`, `Rate` and `Trend`.
+
+All values added to a custom metric can optionally be [tagged](/using-k6/tags-and-groups) which can be very useful when analysing the results after a test run.
+
+| Metric type | Description |
+| ------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------- |
+| [Counter](/javascript-api/k6-metrics/counter-k6-metrics) | A metric that cumulatively sums added values. |
+| [Gauge](/javascript-api/k6-metrics/gauge-k6-metrics) | A metric that stores the min, max and last values added to it. |
+| [Rate](/javascript-api/k6-metrics/rate-k6-metrics) | A metric that tracks the percentage of added values that are non-zero. |
+| [Trend](/javascript-api/k6-metrics/trend-k6-metrics) | A metric that allows for calculating statistics on the added values (min, max, average and percentiles). |
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/07 k6-metrics/70 Counter.md b/src/data/markdown/docs/02 javascript api/07 k6-metrics/70 Counter.md
new file mode 100644
index 0000000000..0a9e9acc41
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/07 k6-metrics/70 Counter.md
@@ -0,0 +1,96 @@
+---
+title: "Counter (k6/metrics)"
+---
+
+_Counter_ is an object for representing a custom cumulative counter metric. It is one of the four custom metric types.
+
+| Parameter | Type | Description |
+| --------- | ------- | ------------------------------ |
+| `name` | string | The name of the custom metric. |
+
+| Method | Description |
+| -------------------------------------------------------------------------------------------- | ---------------------------------- |
+| [Counter.add(value, [tags])](/javascript-api/k6-metrics/counter/counter-add-value-tags) | Add a value to the counter metric. |
+
+## Counter usage in Thresholds
+
+When `Counter` is used in a threshold expression, the variable must be called `count` or `rate` (lower case).
+For example:
+ - `count >= 200` // value of the counter must be larger or equal to 200
+ - `count < 10` // less than 10.
+
+### Examples
+
+
+
+```javaScript
+import http from "k6/http";
+import { Counter } from "k6/metrics";
+
+let CounterErrors = new Counter("Errors");
+
+export let options = { thresholds: { "Errors": ["count<100"] } };
+
+export default function() {
+ let res = http.get('https://test-api.k6.io/public/crocodiles/1/');
+ let contentOK = res.json("name") === 'Bert';
+ CounterErrors.add(!contentOK);
+};
+```
+
+
+
+
+
+```javaScript
+import { Counter } from 'k6/metrics';
+import { sleep } from 'k6';
+import http from 'k6/http';
+
+let allErrors = new Counter('error_counter');
+
+export let options = {
+ vus: 1,
+ duration: '1m',
+ thresholds: {
+ 'error_counter': [
+ 'count < 10', // 10 or fewer total errors are tolerated
+ ],
+ 'error_counter{errorType:authError}': [ // Threshold on a sub-metric (tagged values)
+ 'count <= 2', // max 2 authentication errors are tolerated
+ ]
+ }
+};
+
+export default function () {
+ let auth_resp = http.post('https://test-api.k6.io/auth/token/login/',
+ {username: 'test-user', 'password': 'supersecure'});
+
+ if (auth_resp.status >= 400){
+ allErrors.add(1, { errorType: 'authError' }); // tagged value creates submetric (useful for making thresholds specific)
+ }
+
+ let other_resp = http.get('https://test-api.k6.io/public/crocodiles/1/');
+ if (other_resp.status >= 400) {
+ allErrors.add(1); // untagged value
+ }
+
+ sleep(1);
+}
+```
+
diff --git a/src/data/markdown/docs/02 javascript api/07 k6-metrics/70 Counter/Counter-add-value- -tags--.md b/src/data/markdown/docs/02 javascript api/07 k6-metrics/70 Counter/Counter-add-value- -tags--.md
new file mode 100644
index 0000000000..a42948438d
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/07 k6-metrics/70 Counter/Counter-add-value- -tags--.md
@@ -0,0 +1,28 @@
+---
+title: "Counter.add(value, [tags])"
+---
+
+Add a value to the `Counter` metric.
+
+| Parameter | Type | Description |
+| --------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| value | number | The value to add to the counter. |
+| tags | object | Set of [tags](/using-k6/tags-and-groups) that will be tagged to the added data point (note that tags are added per data point and not for the entire metric). |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/07 k6-metrics/71 Gauge.md b/src/data/markdown/docs/02 javascript api/07 k6-metrics/71 Gauge.md
new file mode 100644
index 0000000000..15eaa133ff
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/07 k6-metrics/71 Gauge.md
@@ -0,0 +1,64 @@
+---
+title: 'Gauge (k6/metrics)'
+---
+
+_Gauge_ is an object for representing a custom metric holding only the latest value added. It is one of the four [custom metrics](/javascript-api/k6-metrics).
+
+| Parameter | Type | Description |
+| --------- | ------- | --------------------------------------------------------------------------------------------------- |
+| `name` | string | The name of the custom metric. |
+| `isTime` | boolean | A boolean indicating whether the values added to the metric are time values or just untyped values. |
+
+| Method | Description |
+| --------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
+| [Gauge.add(value, [tags])](/javascript-api/k6-metrics/gauge/gauge-add-value-tags) | Add a value to the gauge metric. Only the latest value added will be kept. |
+
+## Gauge usage in Thresholds
+
+When gauge is used in a threshold expression, the variable must be called `value` (lower case).
+For example:
+ - `value < 200`
+ - `value > 1`
+
+### Example
+
+
+
+```js
+import http from "k6/http";
+import { sleep } from 'k6';
+import { Gauge } from "k6/metrics";
+
+let GaugeContentSize = new Gauge("ContentSize");
+
+export let options = {
+ thresholds: {
+ "ContentSize": ["value<4000"],
+ }
+};
+
+export default function() {
+ let res = http.get("https://test-api.k6.io/public/crocodiles/1/");
+ GaugeContentSize.add(res.body.length);
+ sleep(1);
+}
+
+```
+
+
diff --git a/src/data/markdown/docs/02 javascript api/07 k6-metrics/71 Gauge/Gauge-add-value- -tags--.md b/src/data/markdown/docs/02 javascript api/07 k6-metrics/71 Gauge/Gauge-add-value- -tags--.md
new file mode 100644
index 0000000000..e308b3be45
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/07 k6-metrics/71 Gauge/Gauge-add-value- -tags--.md
@@ -0,0 +1,29 @@
+---
+title: "Gauge.add(value, [tags])"
+---
+
+Set the value of the `Gauge` metric.
+
+| Parameter | Type | Description |
+| --------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| value | number | The value to set the gauge to. |
+| tags | object | Set of [tags](/using-k6/tags-and-groups) that will be tagged to the added data point (note that tags are added per data point and not for the entire metric). |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/07 k6-metrics/72 Rate.md b/src/data/markdown/docs/02 javascript api/07 k6-metrics/72 Rate.md
new file mode 100644
index 0000000000..5ca5609ab4
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/07 k6-metrics/72 Rate.md
@@ -0,0 +1,73 @@
+---
+title: 'Rate (k6/metrics)'
+---
+
+_Rate_ is an object for representing a custom metric keeping track of the percentage of added values that are non-zero. It is one of the four [custom metrics](/javascript-api/k6-metrics).
+
+| Parameter | Type | Description |
+| --------- | ------- | --------------------------------------------------------------------------------------------------- |
+| `name` | string | The name of the custom metric. |
+
+| Method | Description |
+| -------------------------------------------------------------------------------- | ------------------------------- |
+| [Rate.add(value, [tags])](/javascript-api/k6-metrics/rate/rate-add-value-tags) ] | Add a value to the rate metric. |
+
+
+## Rate usage in Thresholds
+
+When `Rate` is used in a threshold expression, the variable must be called `rate` (lower case).
+For example:
+ - `rate < 0.1` // less than 10%
+ - `rate >= 0.9` // more or equal to 90%
+
+The value of the `rate` variable ranges between `0.00` and `1.00`.
+
+### Examples
+
+
+
+```javaScript
+import { Rate } from 'k6/metrics';
+import { sleep } from 'k6';
+import http from 'k6/http';
+
+let errorRate = new Rate('errorRate');
+
+export let options = {
+ vus: 1,
+ duration: '5m',
+ thresholds: {
+ 'errorRate': [
+ // more than 10% of errors will abort the test
+ { threshold: 'rate < 0.1', abortOnFail: true, delayAbortEval: '1m' }
+ ]
+ }
+};
+
+export default function () {
+ let resp = http.get('https://test-api.k6.io/public/crocodiles/1/');
+
+ errorRate.add(resp.status >= 400);
+
+ sleep(1);
+}
+```
+
diff --git a/src/data/markdown/docs/02 javascript api/07 k6-metrics/72 Rate/Rate-add-value- -tags--.md b/src/data/markdown/docs/02 javascript api/07 k6-metrics/72 Rate/Rate-add-value- -tags--.md
new file mode 100644
index 0000000000..8abcafa4d7
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/07 k6-metrics/72 Rate/Rate-add-value- -tags--.md
@@ -0,0 +1,30 @@
+---
+title: "Rate.add(value, [tags])"
+---
+
+Set the value of the `Rate` metric.
+
+| Parameter | Type | Description |
+| --------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| value | number | The value to add to the rate metric. |
+| tags | object | Set of [tags](/using-k6/tags-and-groups) that will be tagged to the added data point (note that tags are added per data point and not for the entire metric). |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/07 k6-metrics/73 Trend.md b/src/data/markdown/docs/02 javascript api/07 k6-metrics/73 Trend.md
new file mode 100644
index 0000000000..bcac287c00
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/07 k6-metrics/73 Trend.md
@@ -0,0 +1,86 @@
+---
+title: 'Trend (k6/metrics)'
+---
+
+_Trend_ is an object for representing a custom metric that allows for calculating different statistics on the added values (min, max, average or percentiles). It is one of the four [custom metrics](/javascript-api/k6-metrics).
+
+| Parameter | Type | Description |
+| --------- | ------- | --------------------------------------------------------------------------------------------------- |
+| `name` | string | The name of the custom metric. |
+| `isTime` | boolean | A boolean indicating whether the values added to the metric are time values or just untyped values. |
+
+| Method | Description |
+| --------------------------------------------------------------------------------- | -------------------------------- |
+| [Trend.add(value, [tags])](/javascript-api/k6-metrics/trend/trend-add-value-tags) | Add a value to the trend metric. |
+
+
+## Trend usage in Thresholds
+
+When `Trend` is used in a threshold expression, there are a range of variables that can be used.
+ - `avg` for average
+ - `min` for minimum
+ - `max` for maximum
+ - `med` for median
+ - `p(N)` for specific percentile. `N` is a number between `0.0` and `100.0` meaning the percentile value to look at, eg. `p(99.99)` means the 99.99th percentile.
+
+The unit of these variables and functions are all in milliseconds.
+
+### Example threshold expressions:
+
+ - `p(95) < 400` // 95% of requests must finish below 400ms
+ - `p(99) < 1000` // 99% of requests must finish within 1s.
+ - `p(50) < 200` // half of requests must finish within 200ms.
+ - `max < 3000` // the slowest request must finish within 3s.
+
+
+
+> ### ⚠️ Don't use `min` and `max` in thresholds.
+> We don't recommend using `min` and `max` for specifying thresholds because these
+> values represent outliers. Use percentiles instead.
+
+
+
+```javaScript
+import { Trend } from 'k6/metrics';
+import { sleep } from 'k6';
+import http from 'k6/http';
+
+let serverWaitingTimeOnLogin = new Trend('serverWaitingTimeOnLogin', true);
+
+export let options = {
+ vus: 1,
+ duration: '1m',
+ thresholds: {
+ 'serverWaitingTimeOnLogin': [
+ 'p(95) < 200',
+ ],
+ }
+};
+
+export default function () {
+ let resp = http.post('https://test-api.k6.io/auth/token/login/', { username: 'test-user', 'password': 'supersecure' });
+
+ serverWaitingTimeOnLogin.add(resp.timings.waiting);
+ sleep(1);
+}
+```
\ No newline at end of file
diff --git a/src/data/markdown/docs/02 javascript api/07 k6-metrics/73 Trend/Trend-add-value- -tags--.md b/src/data/markdown/docs/02 javascript api/07 k6-metrics/73 Trend/Trend-add-value- -tags--.md
new file mode 100644
index 0000000000..22b5370bb6
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/07 k6-metrics/73 Trend/Trend-add-value- -tags--.md
@@ -0,0 +1,28 @@
+---
+title: "Trend.add(value, [tags])"
+---
+
+Add a value to the `Trend` metric.
+
+| Parameter | Type | Description |
+| --------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| value | number | The value to add to the trend metric. |
+| tags | object | Set of [tags](/using-k6/tags-and-groups) that will be tagged to the added data point (note that tags are added per data point and not for the entire metric). |
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/08 k6-ws.md b/src/data/markdown/docs/02 javascript api/08 k6-ws.md
new file mode 100644
index 0000000000..c875fcdd94
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/08 k6-ws.md
@@ -0,0 +1,94 @@
+---
+title: "k6/ws"
+excerpt: "k6 WebSocket API"
+---
+
+The ws module provides a [WebSocket](https://en.wikipedia.org/wiki/WebSocket) client implementing the [WebSocket protocol](http://www.rfc-editor.org/rfc/rfc6455.txt).
+
+| Class | Description |
+| ----- | ----------- |
+| [Socket](/javascript-api/k6-ws/socket) | WebSocket client used to interact with a WS connection. |
+
+
+| Function | Description |
+| ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [connect( url, params, callback )](/javascript-api/k6-ws/connect-url-params-callback) | Create a WebSocket connection, and provides a [Socket](/javascript-api/k6-ws/socket) client to interact with the service. The method returns a [Response](/javascript-api/k6-http/response-k6-http) object and blocks the test finalization until the connection is closed. |
+
+
+### WebSocket built-in metrics
+
+`k6` will automatically collect some metrics when interacting with a WebSocket service through the `k6/ws` API.
+
+| Metric name | Type | Description |
+| ------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------ |
+| ws\_connecting | Trend | Total duration for the WebSocket connection request. |
+| ws\_session\_duration | Trend | Duration of the WebSocket session. Time between the start of the connection and the end of the VU execution. |
+| ws\_sessions | Counter | Total number of started WebSocket sessions. |
+| ws\_ping | Trend | Duration between a ping request and its pong reception |
+| ws\_msgs\_sent | Counter | Total number of messages sent through [Socket.send(data)](/javascript-api/k6-ws/socket/socket-send-data) |
+| ws\_msgs\_received | Counter | Total number of received messages [Socket.on('message', callback)](/javascript-api/k6-ws/socket/socket-on-event-callback). |
+
+Check out the [Results output article](/getting-started/results-output) for more information about how to process the metric information.
+
+### Example
+
+
+
+```js
+import ws from 'k6/ws';
+import { check } from 'k6';
+
+export default function() {
+ var url = 'ws://echo.websocket.org';
+ var params = { tags: { my_tag: 'hello' } };
+
+ var response = ws.connect(url, params, function(socket) {
+ socket.on('open', function open() {
+ console.log('connected');
+ socket.send(Date.now());
+
+ socket.setInterval(function timeout() {
+ socket.ping();
+ console.log('Pinging every 1sec (setInterval test)');
+ }, 1000);
+ });
+
+ socket.on('ping', function() {
+ console.log('PING!');
+ });
+
+ socket.on('pong', function() {
+ console.log('PONG!');
+ });
+
+ socket.on('pong', function() {
+ // Multiple event handlers on the same event
+ console.log('OTHER PONG!');
+ });
+
+ socket.on('message', function(message) {
+ console.log(`Received message: ${message}`);
+ });
+
+ socket.on('close', function() {
+ console.log('disconnected');
+ });
+
+ socket.on('error', function(e) {
+ if (e.error() != 'websocket: close sent') {
+ console.log('An unexpected error occured: ', e.error());
+ }
+ });
+
+ socket.setTimeout(function() {
+ console.log('2 seconds passed, closing the socket');
+ socket.close();
+ }, 2000);
+ });
+
+ check(response, { 'status is 101': r => r && r.status === 101 });
+}
+//VU execution won't be completely finished until the connection is closed.
+```
+
+
diff --git a/src/data/markdown/docs/02 javascript api/08 k6-ws/80 Socket.md b/src/data/markdown/docs/02 javascript api/08 k6-ws/80 Socket.md
new file mode 100644
index 0000000000..73e291faf1
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/08 k6-ws/80 Socket.md
@@ -0,0 +1,14 @@
+---
+title: "Socket"
+---
+
+`Socket` is a WebSocket client to interact with a WebSocket connection. You can use it to listen various events happening on the WebSocket connection and send messages to the server. Additionally, you can use socket.setTimeout() and socket.setInterval() to execute code in the background, or repeatedly, while the WebSocket connection is open.
+
+| Method | Description |
+| ------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [Socket.close()](/javascript-api/k6-ws/socket/socket-close) | Close the WebSocket connection. |
+| [Socket.on(event, callback)](/javascript-api/k6-ws/socket/socket-on-event-callback) | Set up an event listener on the connection for any of the following events: - open - message - ping - pong - close - error. |
+| [Socket.ping()](/javascript-api/k6-ws/socket/socket-ping) | Send a ping. |
+| [Socket.send(data)](/javascript-api/k6-ws/socket/socket-send-data) | Send data. |
+| [Socket.setInterval(callback, interval)](/javascript-api/k6-ws/socket/socket-setinterval-callback-interval) | Call a function repeatedly at certain intervals, while the connection is open. |
+| [Socket.setTimeout(callback, period)](/javascript-api/k6-ws/socket/socket-settimeout-callback-delay) | Call a function with a delay, if the connection is open. |
diff --git a/src/data/markdown/docs/02 javascript api/08 k6-ws/80 Socket/Socket-close--.md b/src/data/markdown/docs/02 javascript api/08 k6-ws/80 Socket/Socket-close--.md
new file mode 100644
index 0000000000..4b742c7d0e
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/08 k6-ws/80 Socket/Socket-close--.md
@@ -0,0 +1,25 @@
+---
+title: "Socket.close()"
+---
+
+Close the WebSocket connection.
+
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/08 k6-ws/80 Socket/Socket-on-event- callback-.md b/src/data/markdown/docs/02 javascript api/08 k6-ws/80 Socket/Socket-on-event- callback-.md
new file mode 100644
index 0000000000..4c32bfa171
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/08 k6-ws/80 Socket/Socket-on-event- callback-.md
@@ -0,0 +1,82 @@
+---
+title: "Socket.on(event, callback)"
+---
+
+Set up callback functions for various events on the WebSocket connection. Multiple handlers can be defined for the same event.
+
+
+| Parameter | Type | Description |
+| --------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| event | string | The event name to define a callback for. |
+| callback | function | The function to call when the event happens. |
+
+| Event name | Description |
+| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| open | Emitted when the connection is established |
+| message | Emitted when a message is received from the server. |
+| ping | Emitted when a ping is received from the server. The client will automatically send back a `pong`. |
+| pong | Emitted when a pong is received from the server. |
+| close | Emitted when the connection is closed by the client [Socket.close()](/javascript-api/k6-ws/socket/socket-close) or when the server sends the `close` event with code status 1000 (normal closure). |
+| error | Emitted when an error occurs. Non-normal closure errors will be forwarded. |
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/08 k6-ws/80 Socket/Socket-ping--.md b/src/data/markdown/docs/02 javascript api/08 k6-ws/80 Socket/Socket-ping--.md
new file mode 100644
index 0000000000..6edaf7f305
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/08 k6-ws/80 Socket/Socket-ping--.md
@@ -0,0 +1,30 @@
+---
+title: "Socket.ping()"
+---
+
+Send a ping. Ping messages can be used to verify that the remote endpoint is responsive.
+
+
+### Example
+
+
+
+```js
+import ws from 'k6/ws';
+
+export default function() {
+ var url = 'ws://echo.websocket.org';
+ var response = ws.connect(url, null, function(socket) {
+ socket.on('open', function() {
+ socket.on('pong', function() {
+ // As required by the spec, when the ping is received, the recipient must send back a pong.
+ console.log('connection is alive');
+ });
+
+ socket.ping();
+ });
+ });
+}
+```
+
+
diff --git a/src/data/markdown/docs/02 javascript api/08 k6-ws/80 Socket/Socket-send-data-.md b/src/data/markdown/docs/02 javascript api/08 k6-ws/80 Socket/Socket-send-data-.md
new file mode 100644
index 0000000000..7dc1187b11
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/08 k6-ws/80 Socket/Socket-send-data-.md
@@ -0,0 +1,31 @@
+---
+title: "Socket.send(data)"
+---
+
+Send a data string through the connection. Binary data is not currently supported.
+You can use `JSON.stringify` to convert a JSON or JavaScript values to a JSON string.
+
+
+| Parameter | Type | Description |
+| --------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| data | string | The data to send. |
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/08 k6-ws/80 Socket/Socket-setInterval-callback- interval-.md b/src/data/markdown/docs/02 javascript api/08 k6-ws/80 Socket/Socket-setInterval-callback- interval-.md
new file mode 100644
index 0000000000..882e5a4142
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/08 k6-ws/80 Socket/Socket-setInterval-callback- interval-.md
@@ -0,0 +1,44 @@
+---
+title: "Socket.setInterval(callback, interval)"
+---
+
+Call a function repeatedly, while the WebSocket connection is open.
+
+
+| Parameter | Type | Description |
+| --------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| callback | function | The function to call every `interval` milliseconds. |
+| interval | number | The number of milliseconds between two calls to `callback`. |
+
+### Example
+
+
+
+```js
+import ws from 'k6/ws';
+import { check } from 'k6';
+
+export default function() {
+ var url = 'ws://echo.websocket.org';
+ var params = { tags: { my_tag: 'hello' } };
+
+ var res = ws.connect(url, params, function(socket) {
+ socket.on('open', function open() {
+ console.log('connected');
+
+ socket.setInterval(function timeout() {
+ socket.ping();
+ console.log('Pinging every 1sec (setInterval test)');
+ }, 1000);
+ });
+
+ socket.on('pong', function() {
+ console.log('PONG!');
+ });
+ });
+
+ check(res, { 'status is 101': r => r && r.status === 101 });
+}
+```
+
+
diff --git a/src/data/markdown/docs/02 javascript api/08 k6-ws/80 Socket/Socket-setTimeout-callback- delay-.md b/src/data/markdown/docs/02 javascript api/08 k6-ws/80 Socket/Socket-setTimeout-callback- delay-.md
new file mode 100644
index 0000000000..9ed5e8546c
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/08 k6-ws/80 Socket/Socket-setTimeout-callback- delay-.md
@@ -0,0 +1,44 @@
+---
+title: "Socket.setTimeout(callback, delay)"
+---
+
+Call a function at a later time, if the WebSocket connection is still open then.
+
+
+| Parameter | Type | Description |
+| --------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| callback | function | The function to call when `delay` has expired. |
+| delay | number | The delay time, in milliseconds. |
+
+
+### Example
+
+
+
+```js
+import ws from 'k6/ws';
+import { sleep } from 'k6';
+
+export default function() {
+ console.log('T0: Script started');
+ var url = 'ws://echo.websocket.org';
+ var response = ws.connect(url, null, function(socket) {
+ console.log('T0: Entered WebSockets run loop');
+ socket.setTimeout(function() {
+ console.log('T0+1: This is printed');
+ }, 1000);
+ socket.setTimeout(function() {
+ console.log('T0+2: Closing socket');
+ socket.close();
+ }, 2000);
+ socket.setTimeout(function() {
+ console.log('T0+3: This is not printed, because socket is closed');
+ }, 3000);
+ });
+ console.log('T0+2: Exited WebSockets run loop');
+ sleep(2);
+ console.log('T0+4: Script finished');
+}
+```
+
+
diff --git a/src/data/markdown/docs/02 javascript api/08 k6-ws/connect- url- params- callback -.md b/src/data/markdown/docs/02 javascript api/08 k6-ws/connect- url- params- callback -.md
new file mode 100644
index 0000000000..20bd2d4c8a
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/08 k6-ws/connect- url- params- callback -.md
@@ -0,0 +1,46 @@
+---
+title: "connect( url, params, callback )"
+description: "Create a WebSocket connection, and provides a Socket client to interact with the service."
+---
+
+Initiate a WebSocket connection to a remote host.
+
+Calling connect will block the VU finalization until the WebSocket connection is closed. Instead of continuously looping the main function (`export default function() { ... }`) over an over, each VU will be halted listening to async events and executing their event handlers until the connection is closed.
+
+The following events can close the connection:
+
+- remote host close event.
+- [Socket.close()](/javascript-api/k6-ws/socket/socket-close).
+- k6 VU interruption based on test configuration or CLI commands.
+
+| Parameter | Type | Description |
+| --------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| url | string | Request URL (e.g. "ws://echo.websocket.org"). |
+| params | object | [Params](/javascript-api/k6-http/params-k6-http) object containing additional request parameters. |
+| callback | function | The callback function that will be called when the WebSocket connection is initiated. A [Socket](/javascript-api/k6-ws/socket) object will be passed to the function, and this object can be used to set up callbacks etc when things happen on the WebSocket connection |
+
+### Returns
+
+| Type | Description |
+| -------- | --------------------------------------------------------------------- |
+| [Response](/javascript-api/k6-http/response-k6-http) | HTTP Response object. |
+
+### Example
+
+
diff --git a/src/data/markdown/docs/02 javascript api/09 Error Codes.md b/src/data/markdown/docs/02 javascript api/09 Error Codes.md
new file mode 100644
index 0000000000..6cb427ce21
--- /dev/null
+++ b/src/data/markdown/docs/02 javascript api/09 Error Codes.md
@@ -0,0 +1,45 @@
+---
+title: 'Error Codes'
+excerpt: ''
+---
+
+Error codes, introduced in k6 0.24.0, are unique numbers that can be used to identify and handle different application and network errors more easily. For the moment, these error codes are applicable only for errors that happen during HTTP requests, but they will be reused and extended to support other protocols in future k6 releases.
+
+When an error occurs, its code is determined and returned as both the `error_code` field of the [`http.Response`](/javascript-api/k6-http/response-k6-http) object, and also attached as the `error_code` [tag](/using-k6/tags-and-groups) to any [metrics](/using-k6/metrics) associated with that request. Additionally, for more details, the `error` metric tag and `http.Response` field will still contain the actual string error message.
+
+Error codes for different errors are as distinct as possible, but for easier handling and grouping, codes in different error categories are also grouped in broad ranges. The current error code ranges are:
+
+- 1000-1099 - General errors
+- 1100-1199 - DNS errors
+- 1200-1299 - TCP errors
+- 1300-1399 - TLS errors
+- 1400-1499 - HTTP 4xx errors
+- 1500-1599 - HTTP 5xx errors
+- 1600-1699 - HTTP/2 specific errors
+
+The following specific error codes are currently defined:
+
+- 1000: A generic error that isn't any of the ones listed below.
+- 1010: A non-TCP network error - this is a place holder there is no error currently known to trigger it.
+- 1100: A generic DNS error that isn't any of the ones listed below.
+- 1101: No IP for the provided host was found.
+- 1110: Blacklisted IP was resolved or a connection to such was tried to be established.
+- 1200: A generic TCP error that isn't any of the ones listed below.
+- 1201: A "broken pipe" on write - the other side has likely closed the connection.
+- 1202: An unknown TCP error - We got an error that we don't recognize but it is from the operating system and has `errno` set on it. The message in `error` includes the operation(write,read) and the errno, the OS, and the original message of the error.
+- 1210: General TCP dial error.
+- 1211: Dial timeout error - the timeout for the dial was reached.
+- 1212: Dial connection refused - the connection was refused by the other party on dial.
+- 1220: Reset by peer - the connection was reset by the other party, most likely a server.
+- 1300: General TLS error
+- 1310: Unknown authority - the certificate issuer is unknown.
+- 1311: The certificate doesn't match the hostname.
+- 1400 to 1499: error codes that correspond to the [HTTP 4xx status codes for client errors](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_errors)
+- 1500 to 1599: error codes that correspond to the [HTTP 5xx status codes for server errors](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#5xx_Server_errors)
+- 1600: A generic HTTP/2 error that isn't any of the ones listed below.
+- 1610: A general HTTP/2 GoAway error.
+- 1611 to 1629: HTTP/2 GoAway errors with the value of the specific [HTTP/2 error code](https://tools.ietf.org/html/rfc7540#section-7) added to 1611.
+- 1630: A general HTTP/2 stream error.
+- 1631 to 1649: HTTP/2 stream errors with the value of the specific [HTTP/2 error code](https://tools.ietf.org/html/rfc7540#section-7) added to 1631.
+- 1650: A general HTTP/2 connection error.
+- 1651 to 1669: HTTP/2 connection errors with the value of the specific [HTTP/2 error code](https://tools.ietf.org/html/rfc7540#section-7) added to 1651.
diff --git a/src/data/markdown/docs/03 cloud/01 Creating and running a test/01 Test Builder.md b/src/data/markdown/docs/03 cloud/01 Creating and running a test/01 Test Builder.md
new file mode 100644
index 0000000000..f25304f051
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/01 Creating and running a test/01 Test Builder.md
@@ -0,0 +1,83 @@
+---
+title: "Test Builder"
+excerpt: "Details on using the k6 Request Builder to generate test scripts and take the guess work out of scripting"
+---
+
+## Background
+
+The k6 Test Builder allows you to utilize a graphical interface to create a test script.
+Based on your inputs, we will automatically generate the proper required JavaScript to
+execute the test within the app or from the command line. Use the Test Builder to help
+speed up your scripting efforts.
+
+> ### HAR Import
+>
+> The test builder also accepts importing a HAR file. When creating your HAR file, you
+> should filter out third party requests and be mindful of your session length. Too many
+> requests as a result of a long journey or third party requests will be overwhelming.
+
+## Test Builder Configuration
+
+The top configuration section allows to:
+
+- `Create` (save) or `Create and Run` your test
+- Give your test a meaningful name
+- Import a HAR file
+- Configure ramping, VUs, and duration
+
+To input a HAR file, simply click on `IMPORT HAR` on the right, and select your file to be converted.
+We will automatically populate the Test Builder with your requests, including any `Headers` sent.
+You are able to modify/delete various parts of the requests to meet your requirements.
+
+
+
+
+## Test Builder Requests
+
+Whether you are importing a HAR file or starting from a blank slate, the `REQUESTS` section
+allows you to explicitly control requests, the data sent with them, and even save data from the response.
+
+Requests will be listed in order on the left. You can reorganize requests by clicking and dragging.
+You can also duplicate or delete requests when hovering over a specific request.
+To add a new request, click `ADD REQUEST`. Your test will execute in the order of these requests.
+
+To modify requests, move over to the right side of the `REQUESTS` section. You are able to:
+
+
+- Give your request a name to better describe it.
+- Change the `HTTP METHOD` by using the drop down prepopulated with `GET`.
+- Change the URL/Endpoint (This is predefine as `http://test.k6.io/` for example purposes)
+- Specify Headers (If you have imported a HAR file, we will include some Headers here)
+- Specify Query Parameters
+- Create Checks
+- Capture a variable (Helpful for dealing with dynamic data, such as authentication tokens)
+- For POST/PUT/PATCH, you can also specify a request body (JSON, Text, or File Content)
+
+> ### Examples
+>
+> We also include some examples of common actions. This is accessible by using the
+> `Test builder examples` drop down in the title bar of the section. Use these for
+> inspiration and guidance as you use the test builder.
+>
+>
+> **NOTE:** Choosing one of the examples will replace the current requests in the Test Builder.
+
+
+
+## Test Builder Script
+
+After you have completed building your requests. You can click on the `` in the
+top right corner of the title bar to view the script we have generated for you.
+
+This script is syntactically correct and may be used run right from the web app.
+You may wish to copy it to your local IDE to place in version control, parameterize data,
+or add more business logic. It's highly recommended to add some Thresholds.
+
+If this is your first time using the Test Builder or k6. We recommend taking a moment to
+familiarize yourself with the generated script and how the different parts relate to inputs.
+For example, the option object reflects your configuration, names of requests are comments above the
+actual requests, checks are implemented with requests, and more.
+
+## See Also
+
+- [Projects](/cloud/analyzing-results/analysis-tab)
diff --git a/src/data/markdown/docs/03 cloud/01 Creating and running a test/02 In-app script editor.md b/src/data/markdown/docs/03 cloud/01 Creating and running a test/02 In-app script editor.md
new file mode 100644
index 0000000000..b71433fd8f
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/01 Creating and running a test/02 In-app script editor.md
@@ -0,0 +1,34 @@
+---
+title: "In-app script editor"
+excerpt: "How to use the k6 in-app script editor"
+---
+
+
+
+> ### Limitations of the in-app editor
+>
+> The in-app editor has access to all built-in k6 modules and remote modules available via
+> the web. If you need to import a custom library or file for parameterization, you
+> must trigger your test using the CLI.
+
+
+
+## Background
+
+The in-app script is designed to allow you to quickly write and mock up test scripts right within the web app. We believe most users will quickly graduate to using k6 as a CLI and their IDE of choice locally. However, organizational security rules vary from organization to organization and some may not be able to install a program without review from their security team. The script editor allows you to utilize just about all features of k6 right within the web app.
+
+Use the script editor as a stepping stone, if needed, before you move to running tests from the command line.
+
+## Usage
+
+Usage of the script editor is straight forward and you can use it like any other editor. Note some of the built in functionality to aide you in scripting
+
+
+- Built in examples
+ - Clicking on any example from the drop down will launch a side by side window for you to use as guidance to adapt your script.
+- Validation/error checking
+ - If you have a syntactical error, we will alert you of that/prevent you from running the script. If you have such an error you will see `There are validation errors, please fix them in order to run the test` above the example drop down.
+- Code Folding
+ - We allow you to fold/collapse blocks of code for easier reading. You can fold by using the down arrow next to the line numbers.
+- Variable highlighting
+ - Selecting any variable will result in other references to that variable being highlighted in your script
diff --git a/src/data/markdown/docs/03 cloud/01 Creating and running a test/03 Recording a test script.md b/src/data/markdown/docs/03 cloud/01 Creating and running a test/03 Recording a test script.md
new file mode 100644
index 0000000000..cd02627e7c
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/01 Creating and running a test/03 Recording a test script.md
@@ -0,0 +1,45 @@
+---
+title: 'Recording a test script'
+excerpt: 'A guide on how to use the k6 Cloud Chrome extension to record user behavior to quickly create load test scripts.'
+---
+
+## Background
+
+
+The k6 Cloud Test Script Recorder Chrome extension allows you to generate the bulk of your test scripts simply by browsing like a user would on your site or web app. The script created gives you a foundation which you can further edit, as required.
+
+The k6 Cloud Chrome extension will capture everything – every single HTTP(s) request being loaded into the browser as you click – including ads, images, documents, etc., so you get a far more accurate read of what’s going on. Just press “record”, start browsing and when complete, the script will automatically upload to your k6 Cloud account.
+
+>### Consider this:
+> The Chrome extension will not record other tabs or pop up windows. If you need to capture this information, you should check out [converting from a HAR file](/using-k6/session-recording-har-support).
+
+*Note:* Before you begin, please be sure to force refresh the k6 Cloud app to ensure you are on the most recent version of the k6 Cloud app.
+
+## Here's how to start:
+
+ 1. Download and install the k6 Browser Recorder.
+
+ 2. **Start a recording**
+ Open the extension by clicking the k6 logo, and press "Start recording" to begin recording the current browser tab. Now browse like a user would or how you want our Virtual Users to execute. We suggest basing this on _real user behavior_ - don't try to visit every single page on your site or app. Focus on common journeys.
+
+
+ 3. **Stop recording**
+ When done, press "Stop recording", you'll be taken to the app to review the recorded test script
+
+
+ 4. **Save your test scripts**
+ Save the recorded script in any of your projects.
+ If any _third party requests_ or requests to download assets were made during the recording those requests will be filtered out by default.
+ Would you want to include some of the requests in the _third party list_ simply deselect the ones you want to include then hit save.
+
+
+ 5. **You can now edit your script as necessary.** k6 Cloud's in app IDE will update in real time to alert you of any syntax errors. You may need to edit your script to deal with CSRF tokens, adding advanced business logic, creating custom metrics, etc.
+
+ 6. **Once done, press run to start your test**
+
+
+> ## Important things to note
+>
+> - The default configuration will be a 12 minute test that ramps to 10 Virtual Users over 1 minute, stays at 10 for 10 minutes, then ramps back to 0 over 1 minute. You can change this in the stages section of the script. Refer to [this article](/test-types/introduction) for more information on ramping configurations.
+> - No load zone is specified and it will run out of Ashburn by default. You can specify different load zones by adding a `ext.loadimpact.distribution` option. See [this article](/using-k6/options) for more information
+> - We have set `discardResponseBodies: true`. This will discard all response bodies by default.
diff --git a/src/data/markdown/docs/03 cloud/01 Creating and running a test/04 Converters.md b/src/data/markdown/docs/03 cloud/01 Creating and running a test/04 Converters.md
new file mode 100644
index 0000000000..46e27f4204
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/01 Creating and running a test/04 Converters.md
@@ -0,0 +1,53 @@
+---
+title: 'Converters'
+redirect: 'https://k6.io/docs/integrations#converters'
+---
+
diff --git a/src/data/markdown/docs/03 cloud/01 Creating and running a test/05 Scheduling a test.md b/src/data/markdown/docs/03 cloud/01 Creating and running a test/05 Scheduling a test.md
new file mode 100644
index 0000000000..42f6e54f2a
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/01 Creating and running a test/05 Scheduling a test.md
@@ -0,0 +1,29 @@
+---
+title: 'Scheduling Tests'
+excerpt: 'A guide on how to schedule your load tests to run in the future or on a schedule within the k6 Cloud Web UI.'
+---
+
+## Background
+
+It's not always feasible to be able to trigger a test to run when you need it. The scheduling option in k6 Cloud allows you to configure a test to execute at a particular time, and on a regular interval, if needed.
+
+Some reasons include, but are not limited to:
+- You need to test a production system and want to do it during hours with minimal usage
+- You want to build a performance trend to monitor for regressions (but aren't ready to integrate it as a step in a CI Pipeline
+
+
+## Scheduling
+
+You have the ability to schedule any tests that currently exists in your k6 Cloud account that has been executed on our cloud service (you can not schedule a locally run test through the web UI). You may also schedule tests that you create within the web UI after saving your configuration.
+
+You can schedule any of your tests from the page with the performance trending graph as shown below. This is helpful if you have triggered a cloud test from the command line and want to automatically run it regularly (without using a CI tool)
+
+
+
+## Scheduling options
+
+In both cases, after clicking "Schedule" you are presented with the following options. You are able to run a test now or at a later date. You can also set the execution to repeat on an Hourly, Daily, Weekly, or Monthly interval. You can also control how long the test will run for, either after a set number of occurrences, or after a certain date. There is some very granular control here, so do explore the option.
+
+
+
+Finally - we do recommend setting up [notifications](/cloud/integrations/notifications) and [thresholds](/using-k6/thresholds) to complete an automated loop. Schedule your test to run and get notified if the test has passed or failed.
diff --git a/src/data/markdown/docs/03 cloud/01 Creating and running a test/06 Running a test from the CLI.md b/src/data/markdown/docs/03 cloud/01 Creating and running a test/06 Running a test from the CLI.md
new file mode 100644
index 0000000000..cc6a8b1bd9
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/01 Creating and running a test/06 Running a test from the CLI.md
@@ -0,0 +1,47 @@
+---
+title: 'Cloud tests from the CLI'
+excerpt: 'How to run cloud tests from the k6 CLI.'
+---
+
+## Background
+
+Running tests within the web app is helpful when getting a feel for the tool or
+building a proof of concept. However, many users will find great flexibility
+when using k6 to trigger tests from the command line.
+
+Reasons for triggering cloud tests from the command line include:
+
+- Integrating testing in CI/CD pipelines
+- Storing test scripts in local version control
+- Modularization of scripts for collaboration and easier maintenance
+- Preference to work in your local environment
+
+
+## Quick Start to using the CLI for cloud tests
+
+Assuming you have k6 installed and a script saved locally, the first step would
+be to authenticate against the k6 Cloud, like so:
+
+
+
+```shell
+k6 login cloud
+```
+
+
+
+Alternatively, you could also get your token from the [API token
+page](https://app.k6.io/account/api-token) and set the
+environment variable `K6_CLOUD_TOKEN` or use `k6 login cloud --token YOUR_TOKEN`.
+
+Once authenticated, you can trigger a test by using the `cloud` command:
+
+
+
+```shell
+k6 cloud nameOfYourScript.js
+```
+
+
+For more in depth instructions, please refer to our full article on
+[cloud execution](/using-k6/cloud-execution#getting-started)
diff --git a/src/data/markdown/docs/03 cloud/01 Creating and running a test/images/01 Test Builder/test-builder-config.png b/src/data/markdown/docs/03 cloud/01 Creating and running a test/images/01 Test Builder/test-builder-config.png
new file mode 100644
index 0000000000..4faab2f884
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/01 Creating and running a test/images/01 Test Builder/test-builder-config.png differ
diff --git a/src/data/markdown/docs/03 cloud/01 Creating and running a test/images/01 Test Builder/test-builder-requests.png b/src/data/markdown/docs/03 cloud/01 Creating and running a test/images/01 Test Builder/test-builder-requests.png
new file mode 100644
index 0000000000..ec6a9a5c83
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/01 Creating and running a test/images/01 Test Builder/test-builder-requests.png differ
diff --git a/src/data/markdown/docs/03 cloud/01 Creating and running a test/images/03 Recording a test script/Step 2.png b/src/data/markdown/docs/03 cloud/01 Creating and running a test/images/03 Recording a test script/Step 2.png
new file mode 100644
index 0000000000..ba280d0eb9
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/01 Creating and running a test/images/03 Recording a test script/Step 2.png differ
diff --git a/src/data/markdown/docs/03 cloud/01 Creating and running a test/images/03 Recording a test script/Step 3.png b/src/data/markdown/docs/03 cloud/01 Creating and running a test/images/03 Recording a test script/Step 3.png
new file mode 100644
index 0000000000..270bd41c59
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/01 Creating and running a test/images/03 Recording a test script/Step 3.png differ
diff --git a/src/data/markdown/docs/03 cloud/01 Creating and running a test/images/03 Recording a test script/Step 4.png b/src/data/markdown/docs/03 cloud/01 Creating and running a test/images/03 Recording a test script/Step 4.png
new file mode 100644
index 0000000000..dec2dd5f95
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/01 Creating and running a test/images/03 Recording a test script/Step 4.png differ
diff --git a/src/data/markdown/docs/03 cloud/01 Creating and running a test/images/05 Scheduling a test/schedule-options.png b/src/data/markdown/docs/03 cloud/01 Creating and running a test/images/05 Scheduling a test/schedule-options.png
new file mode 100644
index 0000000000..5a0695659d
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/01 Creating and running a test/images/05 Scheduling a test/schedule-options.png differ
diff --git a/src/data/markdown/docs/03 cloud/01 Creating and running a test/images/05 Scheduling a test/scheduling.png b/src/data/markdown/docs/03 cloud/01 Creating and running a test/images/05 Scheduling a test/scheduling.png
new file mode 100644
index 0000000000..8ed37f7e7a
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/01 Creating and running a test/images/05 Scheduling a test/scheduling.png differ
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/01 Overview.md b/src/data/markdown/docs/03 cloud/02 Analyzing Results/01 Overview.md
new file mode 100644
index 0000000000..f68a64eab0
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/02 Analyzing Results/01 Overview.md
@@ -0,0 +1,93 @@
+---
+title: 'Overview'
+excerpt: 'An overview of using k6 Cloud Results as a premiere analysis tool'
+---
+
+## Background
+
+As part of the k6 Cloud offering, k6 Cloud Results enables you to visualize, store, analyze, and trend your test results. All tests that utilize k6 Clouds Results will be analyzed by our Performance Insights algorithms to detect patterns associated with performance issues.
+
+As you continue to use k6 Cloud Results, we will also automatically create trending graphs so that you can keep track of how performance of your system changes over time. This is helpful for identifying creeping performance issues before they become larger problems.
+
+## Test Navigation and Metadata
+
+The top of the page provides a breadcrumb menu and an overview of details about your test.
+
+The breadcrumb menu allows to quickly navigate between the latest runs of the test, the test page or all the tests in the current project.
+
+
+
+Additionally, you can see metadata about the current test. Status, Duration, VUs, Regions used, and who started a test. To the write, you have various buttons and menus to let you re-run, share, compare, configure, or delete your test.
+
+
+
+## Performance Overview
+
+The Performance Overview section displays high level data for your test. If the test is running live metrics are displayed.
+
+
+
+After the test has finished the section is updated to show HTTP failures and peak RPS in place of Active VUs and current RPS. If any Performance Alerts have been detected, we will also display that information to you. In this test, our automated algorithms did not find any problems.
+
+
+
+The first signal of a good or bad result will generally be in the Performance Overview panel. Here are the most common patterns to consider.
+
+Typical signs of a good result:
+
+- Response time has a flat trend for the duration of the test
+- Request rates follow the same ramping pattern as Virtual Users(if VUs increase, so does request rate)
+
+Typical signs of a performance issue/bottleneck
+
+- Response times rise during the test
+- Response times rise, then quickly bottom out and stay flat
+- Request rates do not rise with VUs (and response times start to increase)
+
+This is not an all inclusive list. You should use these patterns as a first indicator of good or bad performance of your test.
+
+## Result Tabs
+
+The result tabs allow you to dig into the specific result data sets from your test. We present the following tabs to organize your result data:
+
+| Tab Name | Definition | Add to analysis? | Sorting |
+| ---------- | ------------------------------------------------------------------------------- | ---------------- | ----------------------- |
+| Thresholds | List of your Thresholds in the order they are defined in your script (if used). | Yes | In order defined |
+| Checks | List of Checks, organized into Groups (if used). | Yes | By group, or list (all) |
+| HTTP | List of HTTP requests made, organized into Groups (if used). | Yes | By group, or list (all) |
+| Websocket | List of Websocket requests made, organized into groups (if used). | Yes | By group, or list (all) |
+| Analysis | Tab used to compare data for analysis | N/A | N/A |
+| Script | Script used to run your test (k6 cloud tests only) | N/A | N/A |
+
+These tabs let you dig into your test data in a visual and error-driven way. You are able to click on any metric to expand a graph to dig deeper. You can also add these graphs to the Analysis tab. This allows you to look for interesting correlations in your result data. Within each tab note the ✓ or ✕ next to the individual metrics if failures were encountered. In the example below, we have two checks with failures which are clearly apparent.
+
+
+
+Refer to these articles for more specific information on:
+
+- [Thresholds](/cloud/analyzing-results/threshold-tab)
+- [Checks](/cloud/analyzing-results/checks-tab)
+- [HTTP Table](/cloud/analyzing-results/http-tab)
+
+## Analysis
+
+The analysis tab enables you to analyze and compare metrics. This is helpful for viewing very specific pieces of your data and finding correlations. Added metrics will first appear as a small chart. You can change your aggregation or select Filters to visualize the data in different ways. Finally, you can use the + to add the data to the large chart for comparison.
+
+Here are some general tips to consider when adding metrics and using this tab.
+
+- Ensure that VUs and Request rate follow the same trend.
+- Add and compare interesting requests from the HTTP and Websocket tabs to compare with other metrics
+- Add the load generator CPU and Memory consumption metrics to ensure they are not saturated (metrics only available for tests run in the cloud)
+- Add thresholds that have been exceeded
+- Add checks that have failures
+- Add metrics for endpoints that you have specific SLAs/SLOs on
+
+The above list is not meant to be all inclusive, rather a starting point in helping you dig into performance related issues so you can identify them.
+
+## See Also
+
+- [Performance Insights](/cloud/analyzing-results/performance-trending)
+- [Thresholds](/cloud/analyzing-results/threshold-tab)
+- [Checks](/cloud/analyzing-results/checks-tab)
+- [HTTP Table](/cloud/analyzing-results/http-tab)
+- [Analysis and Comparison Tab](/cloud/analyzing-results/test-comparison)
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/02 Performance Insights.md b/src/data/markdown/docs/03 cloud/02 Analyzing Results/02 Performance Insights.md
new file mode 100644
index 0000000000..c7c083eb54
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/02 Analyzing Results/02 Performance Insights.md
@@ -0,0 +1,152 @@
+---
+title: 'Performance Insights'
+excerpt: 'Performance Insights are automated algorithms designed to help highlight performance issues automatically'
+---
+
+## Background
+
+k6 Cloud's Performance Insights are algorithms built into k6 Cloud Test Results. Our algorithms are automatically executed as part of test result processing. This happens when you run a cloud test `k6 cloud myScript.js` or when you stream a local execution to the cloud `k6 run myScript.js -o cloud`.
+
+> ### Using Performance Insights
+>
+> In order to utilize Performance Insights, all you need to do is run a test. The algorithms automatically analyze
+> the raw metrics and data. If we find something, we will let you know in the Performance Overview section at the top of your test
+
+## Throughput Limit
+
+This alert is raised when a throughput limit has been detected. The number of active in-flight requests continue to grow as the number of Virtual Users are increasing, while the request rate (finished requests) has flatlined. This is indicative that the system under test is overloaded, thus resulting in higher response times. We recommend that you correlate the performance bottleneck with data from an APM and/or server monitoring tool. After making changes, you should run your tests again at the same Virtual User level, to verify if your changes have improved performance on the system under test.
+
+## Increased HTTP failure rate
+
+This alert is raised when a period of elevated HTTP errors has been detected (10% higher than in the beginning of the test). There could be a number of reasons for this, e.g. web server configuration (timeouts, rate limiting etc.) or internal errors caused by saturation of a resource (CPU, memory, disk I/O or database connections). It typically means the target system is close to its performance limit.
+
+**Note:** Failed responses are often returned much faster than successful responses. Consequently, an increased HTTP error rate may produce misleading request rate and response time metrics.
+
+## High HTTP failure rate
+
+The total number of HTTP(s) errors is higher than 15% during the first 100 completed script iterations.
+
+Errors that occur early on are typically not considered to be performance related. Our algorithms also have not detected an increase in the error rate as load has increased.
+With that in mind, there are a number of non-performance related reasons for errors, which includes, but is not limited to:
+
+- You're making invalid requests:
+ - Invalid URLs, eg. with a typo in it or a hostname that is not in the public DNS system.
+ - Missing required headers, eg. authentication/authorization headers or user-agent.
+ - Sending the wrong body data.
+- You're trying to test a system that's behind a firewall.
+- You're hitting a rate limit.
+
+**Note:** Failed responses are often returned much faster than successful responses.
+
+## Not Enough Training Data
+
+This alert is raised because our Smart Results algorithms need at least 100 complete VU iterations of training data plus an additional 15 seconds to produce meaningful output. Your test did not complete the 100 VU iterations necessary for the training data. We recommend increasing the test duration to get the full benefits of Performance Insights.
+
+## Test Health and Informational Performance Insights
+
+Test Health Performance Insights are alerts that intend to highlight test or script related issues. These issues, if not addressed, can either skew your results or make result analysis harder to parse through. These alerts are often quickly solved through changes in the test script or test configuration.
+
+**Important**: The `Third Party Content` and `Too Many URLs` alerts are more informational alerts. Depending on what you are testing, it may be appropriate to disregard these alerts. High CPU or Memory usage **should never** be ignored.
+
+## Third Party Content
+
+**This is an best practice alert, we strongly recommend you remove third party requests from your test**
+
+This alert is raised when we detect many different domains in a test. This is typically caused by your test script containing requests to 3rd party resources such as CDNs, social media scripts, analytic tools, etc. It's recommended to remove third party requests as it may violate the terms of service of that third party, that third party may throttle your requests skewing the percentiles of your results, or you may have no ability to impact performance of that third party.
+
+_Special Notes:_
+
+- You may have a valid reason to test your CDN. Most CDNs charge based on usage so your tests could result in additional costs from your CDN.
+- Your system under test may utilize multiple domains, in which case you can ignore this alert.
+
+## Too Many URLs
+
+**This is an best practice alert, we strongly recommend you aggregate dynamic URLs as it will make analysis easier**
+
+This alert is raised when we detect more than 500 unique URLs in your test results. This is commonly caused by a URL that contains a query parameter or other ID that is unique per iteration. e.g. tokens, session IDs, etc.
+
+In the following example, our query parameter would produce large number of URL metrics:
+
+
+
+```javascript
+for (var id = 1; id <= 600; id++) {
+ http.get(`http://test.k6.io/?ts=${id}`);
+}
+// But you can group all these URL metrics together
+// in our result analysis using the name tag,
+// making it easier for you to interpret the data.
+// Note that you must use the name tag for grouping.
+
+for (var id = 1; id <= 600; id++) {
+ http.get(`http://test.k6.io/?ts=${id}`, {
+ tags: { name: 'test.k6.io?ts' },
+ });
+}
+```
+
+
+
+_Note:_ In some cases, the unique URL may be generated by a third party resource. As mentioned in the Third Party Content alert, it is a best practice to not include third party resources in your test scripts.
+
+## Too Many Groups
+
+**This is an best practice alert, we recommend reviewing how you use the [Group name](/javascript-api/k6/group-name-fn) in your test script.**
+
+This alert is raised when we detect a high number of groups in your test script. The most common reason for this alert is an incorrect usage of the [Group name](/javascript-api/k6/group-name-fn) using it for aggregating different HTTP requests, or within a loop statement. When aggregating URLs, please use the name tag.
+
+Groups are meant to organize and provide an overview of your result tests allowing you a BDD-style of testing. By allowing this organization, you can quickly find specific parts of your test. For example, the point where users are on a certain page or taking specific actions.
+
+
+
+If you want to group multiple HTTP requests, we suggest you use the [URL grouping](/using-k6/http-requests#url-grouping) feature of k6 to aggregate data into a single URL metric.
+
+## High Load Generator CPU Usage
+
+**This is a Test Health Alert. You should address this to ensure accurate results**
+
+This alert is raised when we detect high utilization of the load generator CPU during a test. Over utilization of the load generator can skew your test results producing data that varies from test to test and unpredictably. Virtual Users will naturally try to execute as quickly as possible. The exact cause of over utilization can vary, but is likely due to one of the following reasons:
+
+- Lack of sleep times in your scripts
+ - Sleep times help with pacing and emulating real user behaviour
+- High RPS per VU
+ - When testing API endpoints you may configure your test to aggressively request an endpoint.
+- Large number of requests in a single request batch
+ - Requests made in a request batch will be made in parallel up to the default or defined limits
+- Large amounts of data are returned in responses resulting in high memory utilization
+ - When the memory of the load generator reaches near total consumption, the garbage collection efforts of the Load Generator can cause increase CPU utilization.
+- A JavaScript exception is being thrown early in VU execution. This results in an endless restart loop until all CPU cycles are consumed.
+
+Possible fixes:
+
+- Increase sleep times where appropriate
+- Increase the number of VUs to produce less RPS per VU (thus the same total load)
+- Utilize multiple load zones to spread VUs out across multiple regions
+
+## High Load Generator Memory Usage
+
+**This is a Test Health Alert. You should address this to ensure accurate results**
+
+This alert is raised when we detect high utilization of load generator memory during a test. When memory is highly utilized in a test, it can result in some unexpected behaviour or failures. It may also cause high CPU utilization as garage collection efforts consume more and more of the CPU cycles.
+
+Possible fixes:
+
+- Utilize the test option `discardResponseBodies` to throw away the response body by Default
+ - Use `responseType:` to capture the responseBodies you may require
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/03 Threshold Tab.md b/src/data/markdown/docs/03 cloud/02 Analyzing Results/03 Threshold Tab.md
new file mode 100644
index 0000000000..39e3422dad
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/02 Analyzing Results/03 Threshold Tab.md
@@ -0,0 +1,23 @@
+---
+title: "Threshold Tab"
+excerpt: "The Threshold Tab allows you to visually inspect the performance of your Thresholds during a k6 test. "
+---
+
+## Cloud Results: Thresholds
+
+The Threshold Tab allow you to visually inspect and analyze `Thresholds` in your test. The number in the tab represents passing Thresholds / Total Thresholds so you can quickly see if something needs your attention.
+
+Further within this tab, you are able to:
+
+- Easily see failing checks. In the example below, our `check_failure_rate` custom metric is failing. Take notice of the ✓ or ✕ on the left side of each row.
+- Expand a threshold to view it's graph. In our example below, the expanded threshold is below the threshold of 100 ms
+- Add the chart to the `Analysis Tab` for further correlation with other data
+
+
+
+Next, [Checks Tab](/cloud/analyzing-results/checks-tab)
+
+
+## See Also
+
+For more information on defining `Thresholds` in your test, please refer to our documentation on [Thresholds](/using-k6/thresholds)
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/04 Checks Tab.md b/src/data/markdown/docs/03 cloud/02 Analyzing Results/04 Checks Tab.md
new file mode 100644
index 0000000000..5d7ff658ea
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/02 Analyzing Results/04 Checks Tab.md
@@ -0,0 +1,24 @@
+---
+title: "Checks Tab"
+excerpt: "The Checks tab allow you to visualize performance of your checks in your k6 test"
+---
+
+## Cloud Results: Checks
+
+The Checks Tab allow you to visually inspect and analyze `Checks` in your test. The number in the tab represents passing Checks / total Checks so you can quickly see if something needs your attention.
+
+As you further examine this tab, you are able to:
+
+- Easily see `checks` that have failures. Take notice of the ✓ or ✕ on the left side of each row.
+ - In the example below, the `Check` "is welcome header present" is succeeding only 32.7% of the time
+- Expand a `Check` to view it's graph. We can see how many failures occur at different points in the test.
+- Add the chart to the `Analysis Tab` for further correlation with other data
+
+
+
+Next, [HTTP Tab](/cloud/analyzing-results/http-tab)
+
+
+## See Also
+
+For more information on using `Checks` in your test, please refer to our documentation on [Checks](/using-k6/checks)
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/05 HTTP Tab.md b/src/data/markdown/docs/03 cloud/02 Analyzing Results/05 HTTP Tab.md
new file mode 100644
index 0000000000..622b4256cf
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/02 Analyzing Results/05 HTTP Tab.md
@@ -0,0 +1,23 @@
+---
+title: "HTTP Tab"
+excerpt: "The HTTP tab allows you to inspect individual requests in your k6 test"
+---
+
+## Cloud Results: HTTP Tab
+
+The HTTP Tab allow you to inspect individual HTTP requests made in your test. The number in the tab represents total passing HTTP Requests / Total HTTP Requests. This provides a quick hint to any failing requests. Displayed in the tab will be a row for each HTTP request by resource, method used, and status code returned. If an endpoint has multiple request methods or status codes, we separate them. Note the login endpoint which was requested via a POST but has had two different status codes returned, 200 and 302.
+
+
+On this tab, we can easily see `HTTP` requests with failures that have failures. Take notice of the ✓ on the left of each row. If we had failures they would be marked with a ✕
+
+
+
+When you click on a row to expand, you can also:
+
+- View additional metrics for the request, such as time spent handshaking
+- Change the aggregation (Mean, Median, Min, Max, Std Deviation, or 95th percentile)
+- Add the chart (plus additional metrics) to the analysis tab.
+
+
+
+Next, [Analysis Tab](/cloud/analyzing-results/analysis-tab)
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/06 Analysis Tab.md b/src/data/markdown/docs/03 cloud/02 Analyzing Results/06 Analysis Tab.md
new file mode 100644
index 0000000000..31608b7125
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/02 Analyzing Results/06 Analysis Tab.md
@@ -0,0 +1,25 @@
+---
+title: "Analysis Tab"
+excerpt: "The Analysis tab allows you to compare and correlate data from your k6 test."
+---
+
+## Cloud Results: Analysis Tab
+
+The Analysis Tab allow you to gather all interesting data points from your test to compare and correlate. Any metrics you that you click on `ADD CHART TO ANALYSIS` will show up here. In our example below, we've added some metrics from the previous three articles in this section. The number in the tab, will show how many metrics have been added, for quick reference.
+
+By default the comparison chart will be blank, we've added VUs and response time from the `ADD NEW METRIC` button in the top right corner. Clicking on this button will open a modal for you to add more metrics:
+
+
+
+Other things you can do on this tab:
+
+
+- When viewing the chart, hovering over any single point will show you data from that point in the test.
+- View metrics you added from previous tabs. They will show up below the main chart.
+ - You may also change aggregation of these metrics in this tab or filter on tags
+- Add small charts to the larger chart by clicking on the "+" in the top right corner of the small charts
+- Add additional metrics to the small chart area by clickin `ADD NEW METRIC` in the small chart area
+
+
+
+Next, [Test Comparison](/cloud/analyzing-results/test-comparison)
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/07 Test Comparison.md b/src/data/markdown/docs/03 cloud/02 Analyzing Results/07 Test Comparison.md
new file mode 100644
index 0000000000..972d2f3090
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/02 Analyzing Results/07 Test Comparison.md
@@ -0,0 +1,71 @@
+---
+title: "Test comparison"
+excerpt: "Use the k6 Cloud Results test comparison feature to compare data across different test runs."
+---
+
+
+
+> ### Test Comparison is for comparing runs of the same Test Script
+>
+> When using test comparison, you may only compare tests from the same series of test runs. You are not able to compare two different test scripts.
+
+
+
+The test comparison feature built-in to k6 Cloud Results that allows you to compare the results of two different test runs of the same test script. You can compare high-level metrics, individual checks and URL endpoints. You may wish to compare against a previous test run to look for a measurable difference in some change you made. Or you may be comparing against a known baseline.
+
+## Setting a baseline test
+
+Comparing results against a known [baseline](#phase-2---baseline-testing-scaling-your-tests-and-complex-cases) is a core part of the General Methodology for [performance testing](/testing-guides/automated-performance-testing). Baseline tests are important as they allow you to compare against a control to look for differences. Baseline tests should produce enough load to contain meaningful data and ideal results. In other words, a heavy stress test isn't a good baseline. Think much smaller.
+
+In order to set your baseline, open up the results for the test run you wish to be your baseline. Click on the three dots in the top right corner -> set as Baseline test run. Baseline tests are exempt from data retention policies.
+
+
+
+## Selecting test runs to compare
+
+To compare two test runs, open up one of the test runs. Then select the test run you want to compare it to using the select drop down on the right side of the test result page, just above the Performance Overview section.
+
+
+
+## Test Comparison Mode
+
+After you select a test you will be brought into comparison mode. While in this mode you will see two charts in the Performance Overview section and are able to change the base and target test you are comparing. This lets you quickly change between different test runs and visually see if there are any obvious performance differences.
+
+
+
+## Thresholds Tab Test Comparison
+
+In the thresholds tab, additional data is added to the table for the base and target test run These columns will show the current vs compared test run's Threshold `value` for each Threshold and the `pass/fail` status. Clicking on any threshold will display a separate threshold chart for each test run.
+
+
+
+## Checks Tab Test Comparison
+
+In the checks tab, additional data is added to the table for the base and target test run. These column will show the difference in `Success Rate`, `Success Count` and `Fail Count` between the current and compared test runs. clicking on any Check will display a separate checks charts for each test run.
+
+
+
+## HTTP Tab Test comparison
+
+In the HTTP Tab, additional data is added to the table for the base and target test run. Here you can compare `Count`, `p95`, and `p99` metrics for individual HTTP requests.
+
+Clicking on a row will also show two separate charts, one for each test run. You can also change aggregation of the data to add additional metrics, such as timing breakdown for each HTTP request.
+
+
+
+Next, [Sharing Results](/cloud/analyzing-results/test-results-menu#share-test-results)
+
+
+
+
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/08 Test Results Menu.md b/src/data/markdown/docs/03 cloud/02 Analyzing Results/08 Test Results Menu.md
new file mode 100644
index 0000000000..95c4c1a1d0
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/02 Analyzing Results/08 Test Results Menu.md
@@ -0,0 +1,54 @@
+---
+title: "Test Results Menu"
+excerpt: "Additional options available in the test results menu"
+---
+
+The Test Results menu allows you to take some more actions on your specific test.
+
+
+
+## Export data
+
+Starts a data export. For more information on the structure of the export, please refer to this [documentation](/cloud/analyzing-results/result-export)
+
+
+## Share test results
+
+Generates a URL that you can use to share test results.
+
+
+
+
+> ### Test Result Sharing URL
+>
+> The generated URL does not require a user to be authenticated to view. If you want to share sensitive results, considering add users as [Team Members](/cloud/project-and-team-management/team-members) instead.
+>
+> **Note**: The URL is not generated until after you choose the option to share.
+
+
+
+
+
+## Delete test results
+
+Deletes the current test result.
+
+
+
+> ### Test Deletion is not reversible
+>
+>
+
+
+
+## Set as baseline
+
+Sets the current test run as your baseline test. You are able to specify one test run per test as baseline. This allows you to compare performance over a longer period of time.
+
+
+
+## Create Note
+
+The `Create Note` option launches a modal window with a text box. You can use this to enter notes regarding the test, changes made, or anything that may be worth noting about your test.
+
+
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/09 Performance Trending.md b/src/data/markdown/docs/03 cloud/02 Analyzing Results/09 Performance Trending.md
new file mode 100644
index 0000000000..695e85d3bf
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/02 Analyzing Results/09 Performance Trending.md
@@ -0,0 +1,20 @@
+---
+title: "Performance Trending"
+excerpt: "The performance trending graph allows you to quickly see how performance changes over between test runs"
+---
+
+## Background
+
+The performance trending graph is automatically created as you continue to run your tests. It's intended to provide a high level overview of your test performance over time. The bars on the graph also signal the status of a specific test. You are able to view the performance trending graph both from the dashboard. In both cases we plot the `p95` response time metric for all HTTP requests from the test run.
+
+## Dashboard Performance Trending
+
+Directly from the dashboard you can see all of your tests and the status of the test runs. This view is helpful to get a high level view of how performance is trending over time. In our example below, we can see `Insights Demo with Cloud Execution` is currently running, but has quite a few failures before this test run. Our script, `api.js` is passing and trending down, which is a good sign.
+
+
+
+## Test Performance Trending
+
+By clicking on the name of any of your tests will bring you to a performance trending graph for that specific test run. We show more data points over time in this graph. You can see more information by hovering over any bar in the graph. This test has stable response times between test runs, but is failing by [Thresholds](/using-k6/thresholds)
+
+
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/10 Result Export.md b/src/data/markdown/docs/03 cloud/02 Analyzing Results/10 Result Export.md
new file mode 100644
index 0000000000..615e95a625
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/02 Analyzing Results/10 Result Export.md
@@ -0,0 +1,37 @@
+---
+title: 'Result Export'
+excerpt: 'Structure for the CSV export for cloud results'
+---
+
+Test result data can be exported after a test has finished and data processing complete. To do so, use the [test results menu](/cloud/analyzing-results/test-results-menu) in the top right of a test result and select `Export Data`. The data will be exported as a `.tar.gz` file with a `.csv` contained inside.
+
+## Structure of the CSV data
+
+The CSV data has the following columns of data:
+
+
+
+Here's example data, units (where necessary) and description of each field present in the CSV data.
+
+| Column | Example | Data/Unit | Description |
+| --------------- | -------------------------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
+| `time` | 2019-03-25 11:12:48.927949+00:00 | datetime (UTC) | The ISO-8601 timestamp when this data point was captured (when the HTTP request was made). |
+| `metric` | http_req_duration | string | The metric name that this data point represents. |
+| `group_id` | e1158ec16fa10dcfd16f4bd7309e2c55 | string | The ID of the k6 [`group()`](/using-k6/tags-and-groups) from where this request was made. |
+| `response_time` | 2.008016 | number (ms) | The HTTP response time of the request that this data point represents (if `count` > 1 then this will be an aggregate value, the average). |
+| `url` | http://test.k6.io/style.css | string | The URL requested. |
+| `method` | GET | string | The HTTP method of the request that this data point represents. |
+| `status` | 200 | number | The HTTP response status code of the request that this data point represents. |
+| `count` | 1.0 | number | Number of samples that this data point represents (if > 1 `response_time` is an aggregate value). |
+| `load_zone` | amazon:us:ashburn | string | The load zone where the request(s) was made from. |
+| `tags` | staticAsset=true | string | Pipe (`|`) separated list of `name=value` tags as specified for the request in the script. |
+
+### Future
+
+The exported CSV file currently only contains data from the primary HTTP response time metric (`http_req_duration`). In the future we'll expand the export feature with more HTTP data, WebSocket data, Checks data, Thresholds data as well as Custom metrics data.
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/01 Overview/checks-tab-with-failures.png b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/01 Overview/checks-tab-with-failures.png
new file mode 100644
index 0000000000..afcce7461c
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/01 Overview/checks-tab-with-failures.png differ
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/01 Overview/finished-performance-overview.png b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/01 Overview/finished-performance-overview.png
new file mode 100644
index 0000000000..11d164a2c5
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/01 Overview/finished-performance-overview.png differ
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/01 Overview/running-performance-overview.png b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/01 Overview/running-performance-overview.png
new file mode 100644
index 0000000000..c56fc43b08
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/01 Overview/running-performance-overview.png differ
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/01 Overview/test-metadata.png b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/01 Overview/test-metadata.png
new file mode 100644
index 0000000000..1ea30d742a
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/01 Overview/test-metadata.png differ
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/01 Overview/test-run-navigation.png b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/01 Overview/test-run-navigation.png
new file mode 100644
index 0000000000..3930479fe9
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/01 Overview/test-run-navigation.png differ
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/03 Threshold Tab/thresholds-tab.png b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/03 Threshold Tab/thresholds-tab.png
new file mode 100644
index 0000000000..3a634403c8
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/03 Threshold Tab/thresholds-tab.png differ
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/04 Checks Tab/checks-tab.png b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/04 Checks Tab/checks-tab.png
new file mode 100644
index 0000000000..93b19381fb
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/04 Checks Tab/checks-tab.png differ
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/05 HTTP Tab/http-tab-graph.png b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/05 HTTP Tab/http-tab-graph.png
new file mode 100644
index 0000000000..a15bed1e6a
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/05 HTTP Tab/http-tab-graph.png differ
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/05 HTTP Tab/http-tab.png b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/05 HTTP Tab/http-tab.png
new file mode 100644
index 0000000000..a1204624fb
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/05 HTTP Tab/http-tab.png differ
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/06 Analysis Tab/add-metric-modal.png b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/06 Analysis Tab/add-metric-modal.png
new file mode 100644
index 0000000000..01c66a566a
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/06 Analysis Tab/add-metric-modal.png differ
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/06 Analysis Tab/analysis-tab.png b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/06 Analysis Tab/analysis-tab.png
new file mode 100644
index 0000000000..cffcd544a6
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/06 Analysis Tab/analysis-tab.png differ
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/07 Test Comparison/checks-comparison.png b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/07 Test Comparison/checks-comparison.png
new file mode 100644
index 0000000000..0feea46f66
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/07 Test Comparison/checks-comparison.png differ
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/07 Test Comparison/comparison-mode.png b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/07 Test Comparison/comparison-mode.png
new file mode 100644
index 0000000000..a64ea257ef
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/07 Test Comparison/comparison-mode.png differ
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/07 Test Comparison/http-comparison.png b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/07 Test Comparison/http-comparison.png
new file mode 100644
index 0000000000..5908670a40
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/07 Test Comparison/http-comparison.png differ
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/07 Test Comparison/select-test-comparison.png b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/07 Test Comparison/select-test-comparison.png
new file mode 100644
index 0000000000..a7723e08b4
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/07 Test Comparison/select-test-comparison.png differ
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/07 Test Comparison/set-baseline-test.png b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/07 Test Comparison/set-baseline-test.png
new file mode 100644
index 0000000000..83f7ef927a
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/07 Test Comparison/set-baseline-test.png differ
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/07 Test Comparison/thresholds-comparison.png b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/07 Test Comparison/thresholds-comparison.png
new file mode 100644
index 0000000000..ae3a7061c6
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/07 Test Comparison/thresholds-comparison.png differ
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/08 Test Results Menu/set-baseline.png b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/08 Test Results Menu/set-baseline.png
new file mode 100644
index 0000000000..d4027eaafa
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/08 Test Results Menu/set-baseline.png differ
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/08 Test Results Menu/test-note.png b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/08 Test Results Menu/test-note.png
new file mode 100644
index 0000000000..db3239f499
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/08 Test Results Menu/test-note.png differ
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/08 Test Results Menu/test-results-menu.png b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/08 Test Results Menu/test-results-menu.png
new file mode 100644
index 0000000000..3dbaea0487
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/08 Test Results Menu/test-results-menu.png differ
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/08 Test Results Menu/test-share.png b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/08 Test Results Menu/test-share.png
new file mode 100644
index 0000000000..6062897357
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/08 Test Results Menu/test-share.png differ
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/09 Performance Trending/dashboard-perf-trending.png b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/09 Performance Trending/dashboard-perf-trending.png
new file mode 100644
index 0000000000..6072681132
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/09 Performance Trending/dashboard-perf-trending.png differ
diff --git a/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/09 Performance Trending/performance-trending.png b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/09 Performance Trending/performance-trending.png
new file mode 100644
index 0000000000..2cdb51ca73
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/02 Analyzing Results/images/09 Performance Trending/performance-trending.png differ
diff --git a/src/data/markdown/docs/03 cloud/03 Integrations/02 CI.md b/src/data/markdown/docs/03 cloud/03 Integrations/02 CI.md
new file mode 100644
index 0000000000..4fcbfcf12e
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/03 Integrations/02 CI.md
@@ -0,0 +1,20 @@
+---
+title: 'CI'
+excerpt: 'Overview of Integrations page in k6 Cloud web UI'
+---
+
+## K6 as a CLI
+
+One of the main features in k6 is its ability to act as a command line interface with k6 cloud. This makes it effortless to integrate into your CI/CD pipelines and making sure that your build is free of performance regressions.
+
+Our [Integrations](/integrations) section contains guides for all major CI tools with more on the horizon.
+
+## Converters
+
+With k6 being an open source project, community contributed to multiple converters that make it easier to port your JMeter or Postman scripts to k6. Our Har to k6 converter can help you quickly convert HAR files exported from any browser or third party application.
+
+There is more information available in our [Integrations](/integrations) section.
+
+***
+
+Check out our [Automated performance testing guide too!](/testing-guides/automated-performance-testing)
diff --git a/src/data/markdown/docs/03 cloud/03 Integrations/03 Notifications.md b/src/data/markdown/docs/03 cloud/03 Integrations/03 Notifications.md
new file mode 100644
index 0000000000..f8bc5f0907
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/03 Integrations/03 Notifications.md
@@ -0,0 +1,140 @@
+---
+title: 'Notifications'
+excerpt: ''
+---
+
+Notifications allow you to subscribe to events happening in your organizations/projects. You can receive notifications to be aware when:
+
+- A test has started.
+ - With option to notify on "manual" or "scheduled" tests.
+- A test has completed
+ - With option to notify based on specific result statuses, eg. only on test failure (like a [threshold](/using-k6/thresholds) failing).
+
+You will likely want to use notifications when you schedule your performance tests and/or configure them into your Continuous Integration pipeline.
+
+k6 supports two different notification options:
+
+- Slack
+- WebHook
+
+**Note:** Notifications are configured per organization by the organization owner or an admin member.
+
+
+
+## Slack
+
+Slack is a messaging app for teams. Follow these instructions to configure Slack notifications:
+
+1. From Slack, add a Custom Integration and select Incoming WebHook app.
+2. Select or create a channel and copy the generated WebHook URL.
+3. From the k6 web app, select "Integrations" from the left menubar, and from there select "Setup" for Slack.
+4. Add Slack WebHook URL into the URL input field and click Save Changes or Test Hook.
+
+
+
+---
+
+## WebHooks
+
+When an event is triggered, we'll send a HTTP POST request to the configured URL with a JSON payload containing event specific data. The format is explained in the following section.
+
+---
+
+## Notification events
+
+Headers sent with all requests
+
+| Header | Description |
+| ------------------ | --------------------------------------------------------------------- |
+| X-LoadImpact-ID | Unique ID for this request |
+| X-LoadImpact-Event | Name of the event |
+| User-Agent | User agent for webhook requests always start with `LoadImpactWebHook` |
+
+
+
+## Status Codes
+
+| Status | Description
+|------- | ------------
+| -2 | Created
+| -1 | Validated
+| 0 | Queued
+| 1 | Initializing
+| 2 | Running
+| 3 | Finished
+| 4 | Timed out
+| 5 | Aborted by user
+| 6 | Aborted by system
+| 7 | Aborted by script error
+| 8 | Aborted by threshold
+| 9 | Aborted by limit
+
+---
+
+## Test notification channel event
+
+Test event that can be triggered from the UI to test webhook
+
+Example JSON body:
+```json
+{
+"event": "test.notification_channel"
+}
+```
diff --git a/src/data/markdown/docs/03 cloud/03 Integrations/04 Token.md b/src/data/markdown/docs/03 cloud/03 Integrations/04 Token.md
new file mode 100644
index 0000000000..0685376827
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/03 Integrations/04 Token.md
@@ -0,0 +1,106 @@
+---
+title: 'Token'
+excerpt: 'How to authenticate with k6 Cloud token'
+---
+
+Before you can interact with the k6 Cloud service, whether it's for streaming results or running tests in the cloud, you'll need to authenticate. Your Auth Token is what enables this and allows you to interact with the k6 Cloud using the k6 CLI or through the REST API. To get your Auth Token, please visit this [page](https://app.k6.io/account/token).
+
+Below are some examples on how to utilize the token to authenticate.
+
+
+
+
+> ### Google/Github Single Sign-On Users
+For Single Sign-On (SSO) users, `k6 login cloud` requires a k6 cloud account email and password. You will need to create a password by using [Forgot Password](), or you'll instead need to get your API authentication token from the app and supply that explicitly: `k6 login cloud --token YOUR_API_AUTH_TOKEN`.
+See below for more information.
+
+
+
+
+
+> ### Docker Users
+If you're running k6 in a Docker container you'll need to make sure that the k6 config file where the k6 cloud API authentication information (an API authentication token) will be stored to is persisted via a Docker volume to the host machine using the `-c/--config PATH/TO/CONFIG_FILE` CLI flag, e.g. `docker run -i -v /path/on-host:/path/in-container/ loadimpact/k6 login cloud -c /path/in-container/config.json`.
+
+
+
+
+
+> ### Integrating with CI
+If you are integrating k6 into your CI pipeline, we recommend using one of the token methods to authenticate and not exposing your username/password within your CI configuration files or as variables.
+
+
+
+
+
+## Authenticate with email/password
+
+You can forego using a token and use your k6 cloud email/password credentials by entering the following command into your terminal:
+
+
+
+```shell
+k6 login cloud
+```
+
+
+
+
+
+This will login to your account, fetch (and create of necessary) your k6 cloud API authentication token, and save it to a [k6 configuration file](#using-config-file).
+
+## Authenticating with API token
+
+If you're a Google/Github Single Sign-On (SSO) user or if you have a use case where using your k6 cloud account credentials is not appropriate you can choose to enter your k6 cloud API authentication token directly by entering the following command into your terminal:
+
+
+
+
+## API Token as an environment variables
+
+You can also authenticate with your k6 cloud API authentication token via environment variables. If you make sure the `K6_CLOUD_TOKEN` has been set to your k6 cloud API authentication token k6 will pick it up when executing.
+
+## Authentication with a config file
+
+You can also directly add your k6 cloud API authentication token to a configuration file. Either in the default path that k6 will look for it by default:
+
+
+
+
+or by specifying the `-c/--config PATH/TO/CONFIG_FILE` CLI flag.
+
+When your k6 cloud API authentication token has been added to the config file, it should look something like this (removing any other config options from the file):
+
+
diff --git a/src/data/markdown/docs/03 cloud/03 Integrations/images/03 Notifications/k6-notifications-slack-webhook.png b/src/data/markdown/docs/03 cloud/03 Integrations/images/03 Notifications/k6-notifications-slack-webhook.png
new file mode 100644
index 0000000000..27d0ed3abd
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/03 Integrations/images/03 Notifications/k6-notifications-slack-webhook.png differ
diff --git a/src/data/markdown/docs/03 cloud/03 Integrations/images/03 Notifications/slack-webhook-setup.png b/src/data/markdown/docs/03 cloud/03 Integrations/images/03 Notifications/slack-webhook-setup.png
new file mode 100644
index 0000000000..a9b3f3661f
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/03 Integrations/images/03 Notifications/slack-webhook-setup.png differ
diff --git a/src/data/markdown/docs/03 cloud/04 Project and Team Management/01 Organizations.md b/src/data/markdown/docs/03 cloud/04 Project and Team Management/01 Organizations.md
new file mode 100644
index 0000000000..8166f32d31
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/04 Project and Team Management/01 Organizations.md
@@ -0,0 +1,37 @@
+---
+title: 'Organizations'
+excerpt: 'Explanation of organizations and the hierarchy in the k6 web app'
+---
+
+
+
+> Running tests in another Organization
+> If you have been invited to another organization as a Team Member, you must specify a projectId in `ext.loadimpact.projectId` in order to use that organization's subscription to run your test.
+
+
+
+## Background
+
+Organizations are a hierarchical tier within k6. Organizations are owned by a single user (the account owner).
+
+## Using Organizations
+
+By default, all users have one Organization within their k6 account, this is automatically created and assigned during account registration. If you purchase a subscription, it is associated with the organization. As an organization owner, you may invite [Team Members](/cloud/project-and-team-management/team-members) as either Admins or Project Members. These users will be able to utilize the subscription and access projects in the organization.
+
+If you have been invited to another user's Organization, you will have access based on the role the owner assigned to you (Admin or Project Member). You may utilize the subscription associated with that Organization.
+
+> ### Note on Organizations
+>
+> Most users will only require 1 organization for their subscription. Some larger companies may wish to use multiple organizations to manage multiple unique subscriptions.
+
+## Hierarchy Diagram
+
+Please refer to the following diagram to visualize the relationship of different aspects of the web application
+
+
+
+
+## See also
+
+- [Projects](/cloud/project-and-team-management/projects)
+- [Team Members](/cloud/project-and-team-management/team-members)
diff --git a/src/data/markdown/docs/03 cloud/04 Project and Team Management/02 Projects.md b/src/data/markdown/docs/03 cloud/04 Project and Team Management/02 Projects.md
new file mode 100644
index 0000000000..c5859faaf1
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/04 Project and Team Management/02 Projects.md
@@ -0,0 +1,26 @@
+---
+title: 'Projects'
+excerpt: 'Keep your tests and team members organized with projects, a foldering system built into the k6 web app'
+---
+
+## Background
+
+Projects are a way to stay organized within your account in k6. In the simpliest terms, projects can be considered a foldering system which you can use to organize your tests. Projects are assigned on a per organization level. Organization owners and admins can invite users to be members of a project. Only Read/Write members can be explicitly restricted from accessing a project.
+
+## Using Projects
+
+Projects are a simple foldering system. They are flexible enough to allow you to use them in a way that makes sense to you, but simple enough to not lose information in a deep nested structure.
+
+Here are some ways we have seen users utilize Projects to stay organized:
+
+- Per team: Each team is given their own project for them to do their work and collaborate
+- Per component: A project is created for each component or service you are testing.
+- Per brand: E-commerce customers may want to use projects per brand to stay organized
+- Per Customer: When dealing with custom software, you may wish to organize by customer to ensure each unique system is tested
+- Per Major Release: After your systems go through a major change, you may wish to create a new project to organize the most recent data
+
+## Running CLI Tests in a Specific Project
+
+If you are using the CLI to trigger your tests, you will need to specify a projectId in order to use the correct subscription and organize your results in the correct project. You will need to get the project ID from the top left corner of the dashboard:
+
+
diff --git a/src/data/markdown/docs/03 cloud/04 Project and Team Management/03 Team Members.md b/src/data/markdown/docs/03 cloud/04 Project and Team Management/03 Team Members.md
new file mode 100644
index 0000000000..f0b6a54e62
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/04 Project and Team Management/03 Team Members.md
@@ -0,0 +1,59 @@
+---
+title: 'Team Members'
+excerpt: 'Guide on inviting Team Members to your k6 account for collaboration'
+---
+
+
+
+> Team Members must specify a projectId
+> Invited Team members must specify a `projectId` in `options.ext.loadimpact.projectId` of the options object of their test in order to use the subscription of the organization they have been invited to.
+
+
+
+## Background
+
+The Team Member functionality allows you to invite others users to gain access to your Organization and Subscription within the k6 web app. This make it easy to collaborate and share results to key stakeholders across your company.
+
+---
+
+## Adding Team Members
+
+To add Team Members, click "Members" under "Organization Settings" in the drop down menu in the top left corner.
+
+
+
+---
+
+Next, click "Invite New Members"
+
+
+
+---
+
+Then, within the modal window, enter the email address and select a role for the user. For the Project Member permission role, users can be specifically assigned to projects. Admins are able to see all projects
+
+
+
+---
+
+## Specify a projectId
+
+
diff --git a/src/data/markdown/docs/03 cloud/04 Project and Team Management/images/01 Organizations/organization-hierarchy-diagram.png b/src/data/markdown/docs/03 cloud/04 Project and Team Management/images/01 Organizations/organization-hierarchy-diagram.png
new file mode 100644
index 0000000000..1cb7f6e7a3
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/04 Project and Team Management/images/01 Organizations/organization-hierarchy-diagram.png differ
diff --git a/src/data/markdown/docs/03 cloud/04 Project and Team Management/images/02 Projects/projectID.png b/src/data/markdown/docs/03 cloud/04 Project and Team Management/images/02 Projects/projectID.png
new file mode 100644
index 0000000000..934892ad42
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/04 Project and Team Management/images/02 Projects/projectID.png differ
diff --git a/src/data/markdown/docs/03 cloud/04 Project and Team Management/images/03 Team Members/drop-down-menu.png b/src/data/markdown/docs/03 cloud/04 Project and Team Management/images/03 Team Members/drop-down-menu.png
new file mode 100644
index 0000000000..5e28532816
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/04 Project and Team Management/images/03 Team Members/drop-down-menu.png differ
diff --git a/src/data/markdown/docs/03 cloud/04 Project and Team Management/images/03 Team Members/invite-modal.png b/src/data/markdown/docs/03 cloud/04 Project and Team Management/images/03 Team Members/invite-modal.png
new file mode 100644
index 0000000000..497fd7e8cd
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/04 Project and Team Management/images/03 Team Members/invite-modal.png differ
diff --git a/src/data/markdown/docs/03 cloud/04 Project and Team Management/images/03 Team Members/invite-new-members.png b/src/data/markdown/docs/03 cloud/04 Project and Team Management/images/03 Team Members/invite-new-members.png
new file mode 100644
index 0000000000..0b8e74aa02
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/04 Project and Team Management/images/03 Team Members/invite-new-members.png differ
diff --git a/src/data/markdown/docs/03 cloud/05 Billing & User Menu/01 Settings.mdx b/src/data/markdown/docs/03 cloud/05 Billing & User Menu/01 Settings.mdx
new file mode 100644
index 0000000000..1e6acca9d6
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/05 Billing & User Menu/01 Settings.mdx
@@ -0,0 +1,6 @@
+---
+title: "Settings"
+excerpt: ""
+---
+
+Not sure what to put in this doc? You can only change your org name....
diff --git a/src/data/markdown/docs/03 cloud/05 Billing & User Menu/02 Subscription.md b/src/data/markdown/docs/03 cloud/05 Billing & User Menu/02 Subscription.md
new file mode 100644
index 0000000000..3248ec5d8f
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/05 Billing & User Menu/02 Subscription.md
@@ -0,0 +1,26 @@
+---
+title: 'Subscription'
+excerpt: 'Details of what is available within the k6 subscription menu'
+---
+
+## Background
+
+The subscription menu gives you a simple view of the limits of your current plan as well as how many tests remain for your current period.
+
+## Your Subscription
+
+Details of your current active subscription and any add-ons you may have. Note the counter in the right corner displaying usage for the current period of your subscription.
+
+
+
+## Upgrades
+
+If you have paid online with a credit card, you may upgrade at any time. We will prorate your existing subscripition towards the cost of a new one.
+
+## Downgrades
+
+To downgrade your subscription, you may select a new plan at any time. We will bill the new cost immediately and start the new plan at the conclusion of your current period.
+
+## Cancelation / Data Retention
+
+You may cancel your online subscription at any time through the web app. When canceling you are able to opt into Data Retention to save your result data longer term / between projects. If you do not choose data retention all test result data is deleted 7 days after your subscription expires. When canceling you may use your plan through the end of the current period.
diff --git a/src/data/markdown/docs/03 cloud/05 Billing & User Menu/03 Billing.md b/src/data/markdown/docs/03 cloud/05 Billing & User Menu/03 Billing.md
new file mode 100644
index 0000000000..20dbfc4c19
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/05 Billing & User Menu/03 Billing.md
@@ -0,0 +1,41 @@
+---
+title: 'Billing'
+excerpt: 'Update and view information such as Billing address, VAT, Credit Cards, and receipts'
+---
+
+
+
+> VAT for EU Organizations
+> If you are making a purchase from within the EU, Please be sure to enter your VAT number before purchase.
+> If you do not enter a VAT number, we must collect VAT and are unable to refund VAT if you present a valid number later on.
+> Due to regulations, all purchases made within Sweden will include VAT.
+
+
+
+## Background
+
+The billing allows you to manages things such as billing address, VAT numbers, payment methods and receipts. This menu is only accessible to Account Owners and Admins. The billing menu can be accessed by clicking on the Account Menu -> `Billing`
+
+## Billing Information
+
+Use this section to update your billing email, billing address and VAT (if applicable). To update this information click "Update Billing Information"
+
+
+
+---
+
+## Credit Cards
+
+Use this section to add/remove/change your Credit Card on file. When updating cards, please remove old/expired cards to ensure no lapse in service. To add a card, click `Add New Card`
+
+---
+
+## Payments and Receipts
+
+The Payments section will include all of your receipts for purchases made with a Credit Card in our web app. If you have paid via wire / invoice please reach out to support for help on retrieving historical payment details.
+
+---
+
+## Invoicing and Wire Transfer
+
+For annual agreements we do offer wire transfer / invoicing as a method of payment. In order to get started, please reach out to sales@k6.io.
diff --git a/src/data/markdown/docs/03 cloud/05 Billing & User Menu/images/02 Subscription/subscription.png b/src/data/markdown/docs/03 cloud/05 Billing & User Menu/images/02 Subscription/subscription.png
new file mode 100644
index 0000000000..c541d0eba9
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/05 Billing & User Menu/images/02 Subscription/subscription.png differ
diff --git a/src/data/markdown/docs/03 cloud/05 Billing & User Menu/images/03 Billing/update-billing.png b/src/data/markdown/docs/03 cloud/05 Billing & User Menu/images/03 Billing/update-billing.png
new file mode 100644
index 0000000000..5126b6c733
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/05 Billing & User Menu/images/03 Billing/update-billing.png differ
diff --git a/src/data/markdown/docs/03 cloud/06 Cloud FAQ/01 Pricing.md b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/01 Pricing.md
new file mode 100644
index 0000000000..2e13b0b36e
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/01 Pricing.md
@@ -0,0 +1,65 @@
+---
+title: "Pricing FAQ"
+excerpt: "Frequently asked questions about k6 cloud pricing and subscriptions"
+---
+
+
+This document contains some of our most frequently asked questions about pricing. If your question isn't answered here, please contact [support](mailto:support@k6.io).
+
+
+## Does k6 have a concept of VU Hours?
+
+No - There is no concept of VU hours for our plans. You can run all your tests up to the maximum limits as defined by your subscription.
+
+## What tests count against my monthly limit?
+
+Only tests executed from or streamed to the k6 cloud will count against your total number of tests. Specifically tests run with the `cloud` command or `-o cloud` flag. e.g. `k6 cloud myScript.js` or `k6 run myScript.js -o cloud`
+
+## Can I pay with a PO or Wire transfer?
+
+Yes - please contact sales or support to initiate the process
+
+## Do you offer discounts for: Non-profits? Gov't organizations? Education institutions? Start-ups?
+
+Yes we offer discounts on our base subscriptions. Please contact [sales](mailto:sales@k6.io.com?subject=Not-for-profit%2FStart-up%2FEducational%20Discount%20Inquiry) to confirm your eligibility and a custom quote
+
+## Do plans auto renew?
+
+Yes - our online plans will auto renew, however they can be canceled at any time in app, for any reason.
+
+## Can I upgrade or downgrade my plan?
+
+Yes - You can upgrade or downgrade.
+
+Upgrades result in a prorated amount being applied towards your new plan. For example, if you are 15 days into a month and upgrade, about 50% of your current subscription would be applied towards the new plan's cost.
+
+Downgrades are charged immediately but do not start until the next billing cycle. You retain the ability to test with your current plan until the next billing cycle starts.
+
+## Can I specify a billing contact to receive monthly receipts?
+
+Yes - within the billing menu, you can specify a billing email address. We will send a copy of the receipt to this email upon each renewal.
+
+## How do I get an invoice/receipt for my purchase?
+
+These are located in the billing menu
+
+To get a invoice/receipt for your purchase:
+Click drop down next to your name in app -> billing
+Scroll down to the “Payments” category.
+Click the “View receipt” button.
+
+You can choose to either save or print the receipt. Your receipt number is considered your invoice number.
+
+## My receipt details aren't correct, help!
+
+Please update the billing details in the billing menu. This will regenerate the receipts with proper address, company name and other details.
+
+## I've been charged VAT but have a valid VAT number
+
+For Swedish organizations - we must charge this as we are based in Sweden
+
+For other EU organizations - please be sure to enter your VAT number in the billing menu. If you have forgotten to add your VAT number and it is the same calendar month as your charge, please contact support for potential options on adjusting the charge.
+
+## Do you offer professional services or help with scripting?
+
+Yes - we have a professional services team that can be engaged to assist in your testing. This team can be utilized to just give a hand with scripting or execute entire projects based on your need. Please contact [sales](mailto:sales@k6.io) for more information. Note: Projects need to be scoped and typically require a 1-2 week lead time, depending on availability.
diff --git a/src/data/markdown/docs/03 cloud/06 Cloud FAQ/02 Data Retention.md b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/02 Data Retention.md
new file mode 100644
index 0000000000..0867928ee2
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/02 Data Retention.md
@@ -0,0 +1,45 @@
+---
+title: "What is Data Retention?"
+excerpt: "What is k6 data retention and how does it work?"
+---
+
+
+
+> ### Data Retention
+>
+> Data is retained on a rolling basis. Test result data older than what is specified in
+> your plan is automatically deleted. If you need to save data, please be sure to export,
+> set the test as baseline, or purchase a period of data retention that meets your
+> requirements.
+
+
+
+
+## What is Data Retention?
+
+Generally speaking data retention is continued storage of an organization's data for various reasons. k6 differentiates between test result data and your user data (projects, profiles, etc.). In terms of data retention, we are referring only to test result data. Your specific user data and test configurations are saved indefinitely on your user profile.
+
+## How do I save my baseline tests?
+
+You can select a single test run per test as a baseline test. The purpose of this is to serve as a point of comparison for future tests. Baseline tests are exempt from data retention rules and are saved indefinitely. To mark a test as baseline, use the three dot menu in the top right corner of your test run and click `Set as Baseline`
+
+
+
+
+## How long is my data retained?
+
+Data is retained on a rolling basis, depending on your subscription. For plans with 1 month of data retention, we will retain data for 30 days from the test run. After that period the data is deleted. This rolling period only applies while you have an active subscription. If you cancel your subscription, data is retained for 7 days past subscription expiration.
+
+> ### Buying Data Retention
+>You can purchase a data retention plan during cancelation of your subscription. This allows you to retain your result data at a lower rate between testing periods.
+
+## Can I export my data?
+
+Yes, data can be exported. To export data from a specific test run, please click on the three dot menu in the top right corner of your test run -> export.
+
+## When can I purchase Data Retention
+
+A period data retention is automatically included in every subscription plan. The time your data is retained depends on specific plan you have purchased. For more info on specific plans and corresponding data retention periods please visit our [pricing](https://k6.io/pricing/) page.
+
+> ### Longer Periods of Retention
+> For periods of data retention longer than specified in our plans, please reach out to support for pricing information.
diff --git a/src/data/markdown/docs/03 cloud/06 Cloud FAQ/03 IP addresses Used k6 cloud.md b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/03 IP addresses Used k6 cloud.md
new file mode 100644
index 0000000000..0e8b320b82
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/03 IP addresses Used k6 cloud.md
@@ -0,0 +1,34 @@
+---
+title: "What IP addresses are used by the k6 cloud?"
+excerpt: "List of the IP addresses used by the k6 cloud"
+---
+
+This article contains the various IP addresses k6 uses to generate load for cloud based tests and other services. The most common reason for needing this information is to open your firewall to allow tests to reach the staging/test environment from a cloud based test. If you are streaming results to k6 Cloud utilizing `k6 run myscript.js -o cloud` you may only need to allow traffic against ingest.k6.io on port 443.
+
+Other methods, such as header or query parameter whitelisting, may also fit your requirements. Refer to [this article](/cloud/cloud-faq/how-to-open-your-firewall-to-k6-cloud-service-for-cloud-executed-tests) for more information on those methods.
+
+## Load Zones
+
+k6 uses AWS for cloud load generators. For the IP addresses used in the different load zones and filtering methods please refer directly to [Amazon](http://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html).
+
+If you prefer to view the ranges directly, within the above link, the [ip-ranges.json](https://ip-ranges.amazonaws.com/ip-ranges.json) file provides the updated list of IP addresses used by our load generators. In order to know which IP ranges can be used, you need to filter the `service` of type EC2 and the `region` of the selected load zone/s in your test configuration.
+
+The zone codes are mapped as follows:
+
+
+Code | Name
+---------------|--------------------------
+us-east-1 | US East (Ashburn)
+us-east-2 | US East (Columbus)
+us-west-1 | US West (Palo Alto)
+us-west-2 | US West (Portland)
+ca-central-1 | Canada (Montreal)
+eu-west-1 | EU (Dublin)
+eu-central-1 | EU (Frankfurt)
+eu-west-2 | EU (London)
+ap-northeast-1 | Asia Pacific (Tokyo)
+ap-northeast-2 | Asia Pacific (Seoul)
+ap-southeast-1 | Asia Pacific (Singapore)
+ap-southeast-2 | Asia Pacific (Sydney)
+ap-south-1 | Asia Pacific (Mumbai)
+sa-east-1 | South America (São Paulo)
diff --git a/src/data/markdown/docs/03 cloud/06 Cloud FAQ/04 Debugging test scripts.md b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/04 Debugging test scripts.md
new file mode 100644
index 0000000000..22c3e4d73a
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/04 Debugging test scripts.md
@@ -0,0 +1,77 @@
+---
+title: "What is the best way to debug my load test scripts"
+excerpt: "Tips and tricks to help debug your load test scripts efficiently"
+---
+
+## Background
+
+A common task to any development is debugging your code to make sure it's producing the expect output and results. k6 utilizes JavaScript as the scripting language for writing your load tests. Because tests are written in real code, you can and should debug your tests scripts before running them. Utilize the tips in this document to aid you in speeding up your script development.
+
+
+## Tip 1: Use k6 locally to debug your scripts
+
+While there is an code editor built into the k6 web application, it has limited debugging abilities. Using k6 locally, you can actually execute your test scripts on a small scale to quickly see how the script executes.
+
+
+## Tip 2: Debug locally only.
+
+Building on tip 1 above, you want to avoid streaming your results to our cloud using `-o cloud` and avoid running the test using the cloud service. There are two reasons for this:
+
+1. Tests that run in or stream to our cloud will count against any limits you may have
+2. Execution is slower when streaming or executing in the cloud. We want debugging to be a fast iterative process.
+
+
+
+```C
+k6 run myScript.js
+```
+
+
+
+When debugging, you'll likely be making many changes as you work through your scripts to ensure they work as expected. The data sent or run from the cloud won't be of much value, so just keep it local until you need to run a larger test.
+
+
+## Tip 3: Use flags to limit execution when debugging
+
+It's likely that you've configured Virtual Users and/or duration in your script. adding the flags `-i 1 -u 1` will instruct k6 to execute 1 iteration with 1 Virtual User.
+
+
+
+```C
+k6 run myScript.js -i 1 -u 1
+```
+
+
+
+**Note**: 1 Virtual User and 1 iteration is also the default execution for k6. If you have not defined any VUs or iterations in your test, k6 will execute with 1.
+
+
+## Tip 4: Use builtin debugging options
+
+Sometimes you need to understand more details about the requests being sent and response received. Using `--http-debug` as a flag allows you to do just that. You can also print full response bodies by using `--http-debug="full"`
+
+
+
+```C
+k6 run myScript.js --http-debug="full"
+```
+
+
+
+**Note**: If your test script has a large number of HTTP requests, this will produce a large output.
+
+
+## Tip 5: Print info to the terminal window with console.log(); when debugging
+
+Sometimes it's just easier to print some information to the terminal window. Feel free to use `console.log();` to print useful information to the terminal window. Perhaps you want to examine some JSON returned in a response, a specific response body, or even just know if you've correctly entered/exited loops or IF statements.
+
+To take the above a step further, consider the following snippet of code. We are making a GET request, saving the response to `res` and then logging the complete response object. Now we can examine it to find exactly what we may be looking for to adapt our test script.
+
+
diff --git a/src/data/markdown/docs/03 cloud/06 Cloud FAQ/05 I was invited to an organization and I cannot run tests.md b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/05 I was invited to an organization and I cannot run tests.md
new file mode 100644
index 0000000000..2e067b68ad
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/05 I was invited to an organization and I cannot run tests.md
@@ -0,0 +1,41 @@
+---
+title: "I was invited to an organization and I cannot run tests"
+excerpt: "How to correctly specify/choose a correct project to run your tests in k6"
+---
+
+## Purpose
+
+The Organizations, Projects, and Team Member functionality enables account administrators to organize and control access to their k6 account and subscription for collaboration purposes. However, newly invited members, not being familiar with this structure, sometimes ask us questions or get stuck when trying to run tests.
+
+For example:
+
+>I was invited to an organization with a subscription. However, When I try to run tests, I get an error that my subscription doesn't have enough Virtual Users/exceeds the duration/uses too many load zones. Our subscription allows for the test I want to run. What is wrong and how do I fix this?
+
+It's important to note that every user in k6 is an owner of organization. Organizations can contain multiple Projects. Each Project can contain multiple tests. k6 subscriptions are associated with an Organization. In almost all cases, this error is a result of trying to run a test in an Organization without a subscription (likely your own default organization).
+
+## How do I change my Organization to fix this?
+
+
+## In the web interface
+
+If you are running tests from the web interface, you will need to use the menu in the left side bar, to select a project within the organization with a subscription. The ogranization can be changed from the dropdown User menu in the top left corner. In the image below, our user is a member of two organizations, "LoadImpact" and "Second Organization". In this example "LoadImpact" is our primary organization associated with the users account and "Second Organization" is one which the user has been invited to. In order to run tests using the subscription that was purchased and associated with "Second Organization" we would need to select a Project associated with it. Once you have selected the Project, the project ID will be displayed below the project name in your main overview (top left). You can simply click the copy button next to it.
+
+
+
+## From the command line
+
+If you are using k6 to trigger tests from the command line, you will need to specify, in your test configuration, the project that should be used to run a test. By default, k6 will use the default Organization and default Project associated with a users account. In order to do this, the `projectId` must be set as a [test configuration option](/using-k6/options) within the `ext` object of your script.
+
+
diff --git a/src/data/markdown/docs/03 cloud/06 Cloud FAQ/06 What's the Difference Between k6 Cloud's Version 3.0 (Lua) and 4.0(JavaScript).md b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/06 What's the Difference Between k6 Cloud's Version 3.0 (Lua) and 4.0(JavaScript).md
new file mode 100644
index 0000000000..eedb936000
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/06 What's the Difference Between k6 Cloud's Version 3.0 (Lua) and 4.0(JavaScript).md
@@ -0,0 +1,346 @@
+---
+title: "What's the Difference Between LoadImpact's Version 3.0 (Lua) and k6 Cloud 4.0(JavaScript)"
+excerpt: "A brief overview of the differences between LoadImpact 3.0 (Lua) and k6 Cloud 4.0 (JS/k6) products"
+---
+
+## Purpose
+
+An overview of some key differences between k6 Cloud (JS) and LoadImpact (Lua)
+
+## Overview
+
+From a general performance testing perspective the 3.0 and 4.0 products are more or less the same:
+
+1. You create one or more user scenarios that step through a particular process of your target system that you want to test.
+2. You then combine your user scenario(s) with a traffic simulation profile that specifies how many Virtual Users (VUs) should be concurrently executing the user scenario(s) at different points in time of the test.
+3. You execute your test, metrics data is collected and you are presented with results.
+
+## Differences between 3.0 and 4.0 products
+When looking more closely though there are some differences in how you accomplish step 1, 2 and 3 above.
+
+A big difference is in the workflow that you can accomplish with each respective product.
+
+The 3.0 product is completely cloud based, user scenarios and test configuration are created/edited and stored in the LoadImpact cloud service, and running tests is also done exclusively from the cloud. This also means the target system that is being tested needs to be accessible from the public Internet.
+
+With the 4.0 product we've opened up the platform in two important ways. First, the core load testing software, [k6](https://github.com/loadimpact/k6), is now an open source tool, and secondly it can be used both [on-premise](/getting-started/running-k6) as well as from the k6 Cloud service via our [cloud execution](/using-k6/cloud-execution) functionality. The user scenarios and test configuration has been merged into one, it's now all just JavaScript code, so very version control friendly.
+
+This brings us to an important difference, in the 4.0 product you're responsible for storing and version controlling your tests (the JavaScript combining user scenario and test configuration), and the k6 Cloud service can provide you with result storage, visualization and trending, as well as geographically distributed cloud execution of tests.
+
+## User scenario
+
+In the 3.0 product user scenarios described using Lua code. You can end up with the Lua code in various ways, by using one of the recorder options, the Postman converter or hand coding it, but at the end of the day the output of all these various ways is a piece of Lua code.
+
+In the 4.0 product user scenarios are described using JavaScript, the ES6 version of JS to be precise. This means it's not only a more familiar language to most developers/testers but it also introduces a nice addition compared to the 3.0 product: support for modules, allowing code to be modularized and reused across tests and teams.
+
+See the Lua to JS migration guide down below for more information on how to migrate your Lua user scenarios to JS.
+
+## Test configuration
+
+In the 3.0 product you compose one or more user scenarios into a separate entity known as a "Test" (aka "Test configuration"), and then add additional configuration like traffic simulation profile and thresholds. This is done through the LoadImpact WebApp UI.
+
+In the 4.0 product the equivalent configuration options are specified in the script itself:
+
+
+
+```JavaScript
+export let options = {
+ // Stages represents the traffic ramping profile that will be used in the test,
+ // controlling the VU concurrency throughout the duration of the test
+ 'stages': [
+ // Linear ramp-up from 0 to 50 VUs for 60s
+ { 'target': 50, 'duration': '60s' },
+
+ // Stay constant at 50 VUs for 60s
+ { 'target': 50, 'duration': '60s' },
+
+ // Linear ramp-down from 50 to 0 VUs for 60s
+ { 'target': 0, 'duration': '60s' }
+ ],
+
+ // Use thresholds to set your metric targets, thresholds are used to pass/fail tests
+ // and for controlling automatic test termination
+ thresholds: {
+ // Add a threshold mark test as failed is 95th percentile of overall response time goes above 500ms
+ 'http_req_duration': 'p(95)<500',
+
+ // Add another threshold to fail and abort the test if the threshold hits 1s
+ 'http_req_duration': {'trigger': 'p(95)<1000', 'abortOnFail': true}
+ }
+};
+```
+
+
+
+***
+
+## Lua to JS migration guide
+
+Lua and JavaScript (JS) share most of the fundamental logical constructs and control flow mechanisms that are commonly found in general purpose programming languages. Same goes for the load testing oriented APIs that we've added in each respective product. This section will look at how to convert Lua APIs into the JS equivalent.
+
+## High-level differences
+
+On highest level there are some differences to be aware of before we continue on into more details.
+
+## Loading of builtin modules and APIs
+
+In Lua all the available functionality is loaded by default, APIs can be called right away without explicit loading/importing, while In JS you need to explicitly import the builtin modules and APIs that you want to use:
+
+
+
+## Scope of VU code
+
+In Lua VUs execute the script from top to bottom over and over, while in JS VUs execute the global scope (aka "init code") once to initialize, and then executes the "main function" (`export default function`) over and over:
+
+
+
+
+```lua linenos
+// The VU code is the same as global scope, and gets run over and over by a VU
+client.sleep(3)
+```
+
+```JavaScript
+// Imports and other global scope code
+export default function() {
+ // The VU code, that gets run over and over by a VU
+}
+```
+
+
+
+
+## Converting Lua APIs to JS APIs
+
+## Client sleep/think time
+
+Below you have examples on how to have a VU sleep or think for a specific amount of time (in the example below for 3 seconds), pausing the VU execution:
+
+
+
+
+
+## Making requests
+
+To make HTTP requests there are a number of different Lua APIs available. In the end they're all wrappers around the `http.request_batch()` API. Below you can see a comparison for Lua and JS:
+
+
+
+```lua linenos
+-- Send a single GET request
+http.get("https://httpbin.org/")
+-- Send a single POST request
+http.post("https://httpbin.org", "key=val&key2=val")
+-- Send several requests in parallel
+http.request_batch({
+ { "GET", "https://httpbin.org/" },
+ { "POST", "https://httpbin.org/", "key=val&key2=val" }
+})
+```
+
+```JavaScript
+import http from "k6/http";
+export default function() {
+ // Send a single GET request
+ http.get("https://httpbin.org/");
+ // Send a single POST request
+ http.post("https://httpbin.org", "key=val&key2=val");
+ // Send several requests in parallel
+ http.batch([
+ "https://httpbin.org/",
+ { method: "POST", url: "https://httpbin.org/", body: "key=val&key2=val" }
+ ]);
+}
+```
+
+
+
+
+
+See the [HTTP API](/using-k6/http-requests) docs for k6 for more information and examples.
+
+## Group requests and logic into transactions/pages
+In the 3.0 product there's a concept of pages. Lua code in between calls to `http.page_start()` and `http.page_end()` will be be measured to provide a page load times in the results. The equivalent in JS would be to use [`Groups`](/using-k6/tags-and-groups#groups):
+
+
+
+
+## Data store
+
+In the 3.0 product there's a concept of a Datastore. A CSV file that you can upload to the service and then attach to your user scenario for accessing and using the data in your user scenario logic.
+
+In the 4.0 product there's no specific concept of a Datastore, but in k6 you have two different ways to separate test parameterization data from script logic.
+
+Both of the examples below can be run with:
+
+
+
+```JavaScript
+import { sleep } from "k6";
+import { users } from "./userData.js"
+export default function() {
+ let user = users[__VU - 1];
+ console.log(`${user.username}, ${user.password}`);
+ sleep(3);
+}
+```
+
+
+## Custom metrics
+
+Beyond the standard metrics collected by the 3.0 product you can also collect custom metrics using the `results.custom_metric()` API in the example below. The equivalent in JS would be to use the [`Trend`](/javascript-api/k6-metrics/trend-k6-metrics) custom metric:
+
+
+
+```lua linenos
+-- Track the time-to-first-byte (TTFB)
+local res = http.get("https://httpbin.org/")
+result.custom_metric("time_to_first_byte", res.time_to_first_byte)
+```
+
+```JavaScript
+import {group} from "k6";
+import http from "k6/http";
+import {Trend} from "k6/metrics";
+let ttfbMetric = new Trend("time_to_first_byte");
+export default function() {
+ group("My page", function() {
+ let res = http.get("https://httpbin.org/");
+ ttfbMetric.add(res.timings.waiting);
+ });
+}
+```
+
+
+
+
+For more information, see our docs on [custom metrics](/using-k6/metrics#custom-metrics) (Additional metrics for `Counter`, `Gauge` and `Rate` are available beyond the `Trend` one used above).
diff --git a/src/data/markdown/docs/03 cloud/06 Cloud FAQ/07 Filtering Domains.mdx b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/07 Filtering Domains.mdx
new file mode 100644
index 0000000000..7ed9868057
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/07 Filtering Domains.mdx
@@ -0,0 +1,32 @@
+---
+title: "Why should I filter domains in my load test?"
+excerpt: "Reasons why you should filter domains in your load test and how to achieve that both in-app and using k6 locally"
+---
+
+TODO fix links, We should consider how much we need this article. References things only related to v3.0 - e.g. enter website urls
+
+## Background
+
+Nearly all apps, sites, and services on the web make requests to external resources. It's likely that an app or site you are testing includes any or all of the following: CDNs, marketing trackers (Facebook, Twitter, etc.), analytics tools (Google Analytics), marketing automation trackers (Hubspot, Marketo, Eloqua), developer tools (Fullstory, HotJar, etc.) and more.
+
+
+## Why should I filter domains?
+
+You should filter your domains for all or some of the following reasons:
+
+- External resources may generate unique IDs, which could produce a lot of extra URLs. This would make reviewing results harder to parse through
+- External resources may throttle your requests generated from a load test, this could produce skewed results or even trigger a threshold when it should not have been.
+- External resources typically don't want to be a part of a load test and including them may violate your TOS with that third party
+- In most cases, even if you did notice a performance problem with a 3rd party you normally will have no way to fix that issue
+- Most CDNs charge based on usage, so making requests against the CDN could have financial costs associated with the test. *Note:* You may have a valid reason to test your CDN. We have seen users specifically test CDNs in the past for various reasons.
+
+## Filtering test scripts created in-app
+There are a few ways to filter your domains with k6. If you are using the URL analyzer or HAR file upload in-app, you can utilize the `Domain` option. This allows you to enter domains you specifically want to include within your test. e.g. If I was testing `app.example.com` I would use `example.com` in the `Domain` option.
+
+For both the in-app URL analyzer and HAR file upload, we would ignore requests to other domains when creating the script.
+
+If you are scripting in-app, it's unlikely you would manually write those third party requests, therefore no filter option is needed
+
+## Filtering when using k6's built in HAR file converter
+
+If you are not using one of the in-app options to create your script, you are likely using the built in HAR file converter available in k6. You can convert a HAR file from the command line using `k6 convert myHarFile.har -O myScript.js`. This command would convert the entire contents of the target HAR file in a script with the output denoted.
diff --git a/src/data/markdown/docs/03 cloud/06 Cloud FAQ/08 Open Firewall k6 Cloud.md b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/08 Open Firewall k6 Cloud.md
new file mode 100644
index 0000000000..383e5ef46b
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/08 Open Firewall k6 Cloud.md
@@ -0,0 +1,92 @@
+---
+title: "How to Open Your Firewall to k6 Cloud service For Cloud Executed Tests"
+excerpt: "A guide with different methods to open your firewall to k6 cloud service execution traffic for load testing"
+---
+
+## Purpose
+
+If you are running a `k6 cloud` test, you will be utilizing k6's cloud infrastructure. These are dynamically allocated from our cloud providers and we do not know the source IP until the test is running.
+
+**If you are streaming results to k6 Cloud utilizing `k6 run -o cloud myscript.js` you SHOULD NOT need to whitelist anything.**
+
+To open your firewall to k6 cloud traffic, you have multiple options. Depending on your business needs, one may be a better fit than another.
+
+
+1. Open up your firewall to the whole range of AWS IP addresses used by the load zones where you want to run your load test from. To use AWS to generate traffic, you will have to open up your firewall to a large IP range.
+
+2. Use HTTP headers, URL query parameters, or unique data that identifies the traffic as belonging to your load test, This requires that your firewall has support for scanning application payload data and apply rules based on what it finds.
+
+
+Here is a more samples on how to complete the different options above:
+
+## Opening up your firewall to all IPs potentially used in the test
+
+We list the full range of IP addresses used in [this article](/cloud/cloud-faq/what-ip-addresses-are-used-by-the-k6-cloud). You will need to whitelist the IP ranges for the load zones you are utilizing. Please note the JSON file at the bottom of the article.
+
+## Using HTTP headers or URL query parameters to send an identifying token
+
+You can add custom HTTP headers to any request in your script. You'll need to add the header to every single request.
+
+
+
+
+If you're not dependent on having the simulated users in your load test to be a certain user agent, you can also use the `userAgent` option to set the "User-Agent" header for all subsequent requests. That header could then contain your token value and you would not have to modify every single HTTP request in your script. In the below example the user agent is set to `MyK6UserAgentString/1.0`
+
+
+
+```JavaScript
+// Set a custom User Agent globally in your test options.
+export let options = {
+ userAgent: "MyK6UserAgentString/1.0"
+};
+```
+
+
+
+
+You might also use query parameters, if it doesn't interfere with the functionality of your application:
+
+
+
+```JavaScript
+// Add query parameters to your requests with a unique piece of data
+export default function() {
+ http.get("http://test.k6.io/?firewall_token=TOKEN_STRING");
+}
+```
+
+
+
+Another option would be to request content from a certain hostname that is not in the DNS, but your site would of course need to be configured to respond to requests for that hostname. This is how you do it on the k6 cloud's side:
+
+
+
+```JavaScript
+// In your options, map your a unique/unused/secret hostname to the IP of the server.
+export let options = {
+ hosts: {
+ "https://very_difficult.to.guess.hostname.com": "1.2.3.4"
+ }
+};
+// Make your requests to that hostname
+export default function() {
+ http.get("https://very_difficult.to.guess.hostname.com/");
+}
+```
+
+
+
+Of course, this last solution requires that your firewall terminates SSL traffic, otherwise it will not see the Host header in unencrypted form. You could also use unencrypted HTTP, but get a bit less security.
diff --git a/src/data/markdown/docs/03 cloud/06 Cloud FAQ/09 Calculating Virtual Users.md b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/09 Calculating Virtual Users.md
new file mode 100644
index 0000000000..87438c5228
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/09 Calculating Virtual Users.md
@@ -0,0 +1,73 @@
+---
+title: "Calculating Virtual Uses with Google Analytics"
+excerpt: "A guide on how to use data from Google Analytics to calculate the number of Virtual Users required for load and performance testing with k6 Cloud."
+---
+
+To calculate the number of Virtual Users you need to test with, you should consider this formula:
+
+>Virtual Users = (Hourly Sessions x Average Session Duration in seconds) / 3,600
+
+Google Analytics and other tools are great for seeing where your users are coming from, and it also offers plenty of data that can help you create realistic load tests.
+
+Google Analytics tracks new visitors (“Users”) and how long they stay on your site. During their stay — the "Session" — they will perform actions (page loads, AJAX requests) that cause traffic to be generated that will load your servers.
+
+The formula above takes it's inputs and determines how many users are in the middle of a "Session" at any one time, meaning they are currently active on the site and generating traffic the servers have to handle.
+
+
+**Where do I get this data in Google Analytics?**
+
+
+1. Login to your Google Analytics account
+2. Click the “Reporting” tab across the top
+3. Select “Audience” in the sidebar menu
+4. Click “Overview”
+5. Set the time period you want to base your data on in the top-right corner
+6. And the data you need is right in front of you!
+
+Check out the screenshot below to get an idea of the view and where you’ll find sessions and average session duration.
+
+**Note:** This screenshot is from a small site’s Google Analytics dashboard. We redacted the name in the top-right corner in the name of privacy!
+
+
+
+And that’s it! As you can see, Google made this data pretty easy to find.
+
+### How to design your load test
+
+One good way of determining what traffic to subject your site to during a load test is to check your peak hours of traffic in Google Analytics, figure out how many sessions you faced then, and perform a test that generates a similar kind of load in a similar [pattern](/test-types/introduction). You probably want to add some margin to it also — to ensure that you can handle higher traffic levels than your latest peak.
+
+The reason we want to find the traffic peak and not just use the average level for the whole month is that, in most cases, average traffic will be quite low. It’s quite common for sites to have regular, recurring peak periods where they experience maybe 2-3x the average traffic levels, so it is important to test for that level of traffic, at the very least.
+
+Some sites or services may also have occasional (or regular) extreme traffic peaks. It can be due to the nature of the site — perhaps it’s a new release your customers are eager to try, your app that is gaining popularity as the next bit thing, a site declaring the result of an election, or a site selling concert tickets that are released at a certain date and time.
+
+It can also be because of user behaviour. Maybe your app provides dinner recipes, which means everyone logs on just before dinner. Regardless, such sites can have peaks that are much higher than 10x the longtime average for the site. In this case it is even more important to load test at traffic levels way beyond the average to ensure the system doesn’t break down when it counts.
+
+So how do we do this? Here’s the Google Analytics dashboard for a small example site that has had a (relatively) big traffic spike. For this little site, nearly 40 percent of November 2015’s traffic came on a single day — Nov. 25. Keep in mind this is example data for a super small site.
+
+
+
+Here’s the basic math we used to analyze the data:
+
+The site averaged .08 concurrent sessions for the entire month.
+
+- 2,591 **monthly** sessions x 82 seconds per session / 3600 = 59.0172
+- 59.0172 / 720 (30 days in November x 24h per day = 720) = .08 average concurrent users in November
+
+
+However, if you calculate the average concurrent sessions for just Nov. 25, you get 1.05 — that is more than 10x the monthly number. And if you calculate the average concurrent sessions between 3 p.m. and 4 p.m. on that day, when most of the traffic spike happened, the average number of concurrent sessions is 7.2. While not a huge number by itself, it is almost 100x the monthly average.
+
+
+
+This illustrates how important it is to look at the right numbers, or the right time frames, when designing your load test. Even if you do not have a huge spike like in this case, chances are that you will still see temporary peaks that can reach perhaps 10x your average traffic level.
+
+No matter the size of your company or the amount of traffic you typically handle, a sudden increase in traffic by nearly 100x definitely has the potential to degrade performance for the user, so spike tests are always a good idea before marketing initiatives, funding announcements, new feature rollouts and just for the sake of always being prepared.
+
+
+***
+
+See also:
+- [Virtual Users](/cloud/cloud-faq/what-are-vus-virtual-users)
+- [Creating tests in k6 Cloud](/cloud/creating-and-running-a-test)
+- [Code Samples and Scripting Examples](/examples)
+- [Test configuration options](/using-k6/options)
+- [Test ramping configurations](/test-types/introduction)
diff --git a/src/data/markdown/docs/03 cloud/06 Cloud FAQ/11 Test status codes.md b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/11 Test status codes.md
new file mode 100644
index 0000000000..580be63b4e
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/11 Test status codes.md
@@ -0,0 +1,74 @@
+---
+title: "Test Status codes"
+excerpt: "List of the different test statuses that can be returned by k6 cloud service, with reasons and fixes for dealing with such a status."
+---
+
+## Purpose
+
+Explanation of the different test statuses in k6 along with the code returned. The code returned here is different than what is returned by k6.
+
+Status | Description
+-------|------------------------
+-2 | Created
+-1 | Validated
+0 | Queued
+1 | Initializing
+2 | Running
+3 | Finished
+4 | Timed out
+5 | Aborted by user
+6 | Aborted by system
+7 | Aborted by script error
+8 | Aborted by threshold
+9 | Aborted by limit
+
+
+
+Every successful test, will go through the following statuses. The time from Created -> Running, is typically very short and hardly noticeable as you use the platform.
+
+## Created
+A test that is newly created, but has not yet been validated.
+
+## Validated
+A test which has finished initial validation, but has not been queued to run yet.
+
+## Queued
+A test which has entered our queue. Once it is picked up by a test worker, it will begin initializing.
+
+## Initializing
+A test which has been assigned to Load Generators, but has not yet started to make HTTP requests.
+
+## Running
+A test which is actively making HTTP(s) or websocket requests
+
+## Finished
+A test which has finished running. If thresholds were used, no thresholds have failed.
+
+***
+
+When a does not finish as expected, you the test will have one of the following statues.
+
+
+## Timed Out
+A test which has not received or sent any information for a long time
+
+## Aborted (by user)
+A test which was aborted by the user. Tests aborted by user count against your total usage.
+
+## Aborted (by system)
+A test that was aborted by the system. These tests typically abort due to a fatal error occuring. If the test fails before launch, there may be an underlying issue with the Load Zone, unrelated to k6. If the test aborts during execution, it may be due to overutilization of the Load Generators. In this case, we suggest you look at the CPU and Memory utilization and add or increase sleep times. You may also want to set the option `discardRepsonseBodies` to `true`, to lower memory pressure.
+
+## Aborted (script error)
+A test that was aborted due to an error in your script. For example, if you were to capture data from the response body of a request that you reuse in a future request. If the first request were to fail, your future request would contain a null value. Sudden script errors can suggest a performance issue. Fix the performance issue or add error handling to account for these cases.
+
+## Aborted (by threshold)
+A test that exceeded your defined threshold value and that threshold was given the option to automatically abort the test.
+
+## Aborted (by limit)
+A test that has exceeded one or more of the following limits:
+- There are "too many" (>40) groups in a test
+- There are "too many" (>10,000) metrics reported
+- The duration is longer than 60 mins (for tests longer than 60 min, please contact us)
+- The max VUs is higher than 20,000 VUs (for tests higher than 20k, please contact us)
+
+If your test has too many groups, please reduce their number. If your test has too many metrics, please use URL grouping to combine similar URLs. You should also remove external requests from your test script. Each URL captured will account for 7 individual metrics that we keep track of. External requests can quickly produce a large number of metrics that aren't helpful to the understanding performance of the System Under Test.
diff --git a/src/data/markdown/docs/03 cloud/06 Cloud FAQ/12 Virtual Users.md b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/12 Virtual Users.md
new file mode 100644
index 0000000000..b13dce5ddc
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/12 Virtual Users.md
@@ -0,0 +1,44 @@
+---
+title: "What are VUs (Virtual Users)?"
+excerpt: "Definition of what Virtual Users are in context of k6 cloud service."
+---
+
+## Background
+
+k6 cloud's definition of Virtual Users(VUs) along with supplemental information to cover common questions about VUs.
+
+Virtual Users(VUs) are the entities in k6 cloud service that execute your test script and make HTTP(s) or websocket requests. VUs are concurrent and will continuously iterate through the default function until they ramp down or the test ends. Any number of VUs will create a number of sessions a factor larger than their total count, depending on test and script length.
+
+For example, if you ran a test with 10 VUs for 10 minutes and the default function took each VU 30 seconds to complete, you would see roughly 200 completions/total sessions generated from this test. This is approximate and will vary based on your ramping configuration.
+
+## Virtual Users in context of Web Apps/Websites
+
+Virtual Users are designed to act and behave like real users/browsers would. That is, they are capable of making multiple network connnections in parallel, just like a real user in a browser would. When using a `http.batch()` request, HTTP requests are sent in parallel. Further, you can even control the specifics of this behavior through the [batch](/using-k6/options#batch) and [batchPerHost](/using-k6/options#batchPerHost) options. The default is 10 connections in parallel and per host.
+
+
+
+
+## Virtual Users in context of APIs
+
+When testing individual API endpoints, you can take advantage of each VU making multiple requests each to produce requests per second(rps) a factor higher than your VU count. e.g. Your test may be stable with each VU making 10 rps each. If you wanted to reach 1000 RPS, you may only need 100 VUs in that case. This will vary based on what you are testing and the amount of data returned. For more information on testing APIs, please refer to our article [API Load Testing](/testing-guides/api-load-testing)
+
+
+Virtual Users are using multiple parallel network connections, they will be opening multiple concurrent network connections and transferring resources in parallel. This results in faster page loads, more stress on the target server, and more realistic result data set. **Not all load testing tools operate in this more complex and realistic fashion**
+
+## Calculating the number of Virtual Users needed
+
+Calculating the number of virtual users can be done by using this formula:
+
+
+
+```
+VUs = (hourly sessions * average session duration in seconds)/3600
+```
+
+
+
+You may want to use this formula multiple times, with different data such as sessions in your busiest/peak hour, a normal hour, etc. When setting up your test, if your user journey (default function) mimics an average user session, the number of VUs determined by the formula would produce the amount of sessions you entered if you ran your test for an hour.
diff --git a/src/data/markdown/docs/03 cloud/06 Cloud FAQ/13 (find new home) load-testing-methodology.mdx b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/13 (find new home) load-testing-methodology.mdx
new file mode 100644
index 0000000000..8abb1caba6
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/13 (find new home) load-testing-methodology.mdx
@@ -0,0 +1,75 @@
+---
+title: Basic Load Testing Methodology
+excerpt: A simple methodology to help you start testing
+---
+
+
+## Purpose
+
+This methodology is intended to walk through the high level steps that will help you get started and running more meaningful tests, faster. The best tests are the ones that simulate the most realistic conditions and user behavior. However, simple testing is better than no testing. It's easy to become overwhelmed if you attempt to do everything all at once. Treat testing like you would development, _start small and iterate, iterate, iterate._
+
+## What am I testing?
+
+If you have not already, you start thinking about any or all of the following:
+
+* What are my users doing?
+ - What specific actions do they take the most?
+ - What actions are most critical on my app/website?
+* What API endpoints are utilized the most?
+ - What API endpoints are most critical?
+* What response times are acceptable to my users?
+ - What response times are acceptable to me?
+* What SLAs, contracts, or regulations must I adhere to?
+
+### When do I run tests?
+
+As the world shifts left with DevOps, testing earlier in the development cycle is becoming the best practice. After an initial testing project, many users decide to continue to run tests, at a smaller scale, so they can identify performance issues immediately after the line of code that caused it, is built.
+
+### Virtual Users or Requests Per Second?
+
+This depends on what you are testing, and there is a good chance you want to think in terms of both. Virtual Users are complex workers that can open multiple connections in parallel, thus making multiple requests per second.
+
+## Virtual Users
+When testing anything that is "User journey" related, webapps, websites, or API endpoints in a specific order you should think in terms of Virtual Users. It's important to also note that Virtual Users are concurrent, unless specified otherwise, they will continue to iterate through their script until the test is complete. A small number of Virtual Users can create a number of sessions magnitudes higher than their count. _This is a very common point of overestimation we see._
+
+## Requests per second
+When testing individual API endpoints it makes more sense to think in terms of request per second. As mentioned above, LoadImpact's virtual users are complex and can make multiple requests per second each. For example, if you wanted to test an endpoint with 100 rps you wouldn't need 100 virtual users in nearly all cases.
+
+## Calculating Virtual Users
+
+We recommend looking into any analytics tools you may have. If they list any metric for concurrent users, you can likely use that. If not, you can instead look for:
+
+- Hourly Sessions
+- Average session duration for those Users
+
+If you are looking to stress your system to see what happens as you exceed your busiest traffic, you should look for the Peak hourly sessions and it's coordinating average session duration.
+
+For any tests you may run on a regular basis, as part of a CI pipeline or otherwise, you should instead look for your average hourly sessions, or lower, depending on your needs.
+
+With these two metrics, you can determine the number of Virtual Users needed, using the following formula:
+
+`VUs = (Peak Hourly Sessions * Average Session Duration in Seconds) / 3600`
+
+Depending on your goals, you may want to increase this number to provide a cushion beyond your expectations (15-30% is typical).
+
+## Plan your first tests
+
+You should plan to run the following tests:
+
+1. Baseline Test "Performace under ideal conditions"
+ - Small test relative to your total Virtual User needs
+ - Run for at least 5-10 minutes
+ - Used to set a baseline metric for you to compare future tests against
+ - You may want to set Thresholds based on this test
+2. Stress test "Where do things break?"
+ - The test you likely will run the most
+ - Used to gradually increase load and identify performance problems
+ - Iterate often- analyze results, make changes, verify with another test
+3. Load Test "Are my changes working?"
+ - The test you run to see if all your hard work in step 2 paid off
+ - Used to verify your system handles the load through the entire test
+4. Continuous test "Is my performance regressing as new code/infrastructure updates are deployed?"
+ - Used to monitor for performance regressions over time
+ - Larger than a baseline test but smaller than a load test
+ - Most commonly integrated as part of automation, such as a CI pipeline
+
diff --git a/src/data/markdown/docs/03 cloud/06 Cloud FAQ/14 (find new home) General Methodology.mdx b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/14 (find new home) General Methodology.mdx
new file mode 100644
index 0000000000..e666088ca8
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/14 (find new home) General Methodology.mdx
@@ -0,0 +1,95 @@
+---
+layout: classic-docs
+title: General Methodology
+description: A general load testing methodology to help you strategize and get started.
+categories: [guides]
+order: 0
+redirect_from:
+ - /4.0/testing-methodologies/application-testing-methodology/
+ - /4.0/testing-methodologies/
+---
+
+
+## Background
+
+This guide will speak from a high level on topics related to Load and Performance testing.
+
+As developers and testers we love to jump straight into the tools, but successful testing starts with successful planning. The intent of this document is to provide additional guidance to best prepare you for testing and to meet your testing goals. This methodology assumes that some initial performance testing is being done before automating testing in a CI/CD pipeline. Testing can be broken down into the following phases.
+
+
+## Phase 0 - It's a new tool, go explore!
+
+If you are like us here at k6. You will probably want to spend some time clicking around, trying things without any guidance, and seeing what happens when you click that button (yes, that one). Go ahead and do that, think of questions you may have about the tool, they may get answered here. If not, you can always ask us.
+
+
+## Phase 1 - Planning, Test Configuration, and Validation
+
+Phase 1 is further broken down into multiple parts. Before you get started with real testing, we recommend that you:
+
+### Planning
+
+- What are the most important parts of the system I am testing?
+ - _Perhaps a handful of API endpoints are most critical to the proper function of your system. e.g. Login_
+- What are my expected outcomes?
+ - _Is there historical performance testing or events I can use to predict initial outcomes? e.g. During a new release we experienced heavy traffic of users trying our new features out, the response times of our login process was degraded_
+- What other business rules should I consider?
+ - _Has the business implemented any SLAs or other rules that relate to performance. e.g. certain response times, availability, etc._
+- What environment am I testing?
+ - _Production? A testing environment that is identical to production? A testing environment that is scaled down?_
+ - _A test environment that matches production is the most ideal, but not always available. What other considerations should I make to ensure that users aren't disrupted_
+
+
+Once you have thought about these high level items, you should next move into creating and configuring your tests.
+
+### Test Configuration
+
+Here are some tips to consider when you start to write/record your first test script:
+
+- What are the most common actions my user take as they relate to the important components I want to test?
+ - _Login generally tends to be one important part of an application. What are others? If testing user journeys, what logical order do users of your application follow?_
+ - _Don't get caught up on trying to test everything, focus on the most important parts. So skip(for now) that feature that a handful of users use on a regular basis_
+- How much load should I put on my target system?
+ - _If testing individual components, such as API endpoints, think in terms of requests per Second_
+ - _If testing user journeys, such as users visiting page to page or taking multiple actions, think in terms of concurrent users._
+- What test patterns will I execute?
+ - _Different tests will tell you different things. Refer to this article for an explanation of the different patterns:_ [Ramping configurations](/test-types/introduction)
+ - _Generally, this order will work for most when establishing a testing process: Baseline test, stress test, load test, spike test (if applicable)_
+- What data do I need?
+ - _Using the login example, testing the same user logging in will usually only test how well your system can cache responses. What data do you need to be parameterized to support your test executions?_
+
+Keeping the above tips in mind, you should now start writing your scripts by hand or by using our [Chrome extension](/chrome-extension/) or the built in [HAR file converter](/using-k6/session-recording-har-support)to create a test script. **It's best to start small and then expand your test coverage. Treat writing your test scripts as you would code you are writing for your application by breaking it down into smaller, more manageable pieces.** A lot of value can be found in simple tests against the most important components.
+
+**Best Practice Alert:** k6 supports modularization. The script you write to perform a login function with a random user, can later become it's own module in your load testing library. This can be shared with your team through version control or other means.
+
+### Validation
+
+As you are writing your scripts and before you run them at a larger scale it's important to run validations (smoke tests) to ensure that the test works as intended. These tests are typically run with a very low number of Virtual Users for a very short amount of time. For speed, it's recommended you run these locally with output to `stdout`. In other words, don't run a validation using cloud infrastructure or streamed into the cloud for analysis.
+
+## Phase 2 - Baseline Testing, Scaling your tests, and Complex Cases
+
+If you take the time to consider all your initial planning, the next steps become much easier to complete and require less specific instruction.
+
+### Baseline testing
+
+It's not recommended to run your first test at full throttle and the maximum number of Virtual Users. When testing, it is critical to always be thinking comparatively. Your first test should then be a **baseline test.** A baseline test is a test at an ideal number of concurrent users/requests per second and run for a long enough duration to produce a clear stable result. This baseline test will give you initial performance metrics for you to compare to future test runs. The ability to compare will help highlight performance issues more quickly.
+
+**Common question** "What is ideal as it relates to baseline testing above?"
+**Answer:** A number of Virtual Users you know your system can handle well. If you aren't sure, try 1 - 10 Virtual Users.
+
+**For example:** Does your application generally receive 500 concurrent users at any given time? You should be running your baseline tests below that.
+
+### Scaling your Tests
+
+After your baseline tests are complete, it's time to start to run larger tests to detect performance problems. You should utilize the Stress Test pattern to scale / step your tests up through different levels of concurrency to detect degradations. As you find these degradations and make adjustments you will iterate on the test multiple times until a satisfactory level of performance is met.
+
+Regardless of the complexity of your test cases, the testing you do in this step will provide the most information to take action on to improve performance. Once you have finished iterating through tests at this stage, verified by acceptable test runs that finish, you should move to a load test pattern to verify the system under test can handle an extended duration at the goal level of load.
+
+### Complex Cases
+
+If, like most users, you started by writing small simple test cases, now is the time to expand them. You may want to repeat this second phase to look for deeper performance problems, ones that could only show up when multiple components are under load.
+
+**Best practice Alert:** If you have been modularizing your test scripts up to this point, this step may be as easy as including them into a "master" test case.
+
+## Phase 3 - Ongoing performance Testing
+
+The final step in our methodology is one that is long term. Up until now you have spent a good deal of time and effort creating your test cases, executing your tests, fixing various issues, and improving performance. You can continue to receive returns on the time investment made by including performance testing into your Continuous integration pipelines or just by running tests on a regular basis manually.
diff --git a/src/data/markdown/docs/03 cloud/06 Cloud FAQ/images/02 data retention/set-as-baseline.png b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/images/02 data retention/set-as-baseline.png
new file mode 100644
index 0000000000..d359273865
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/images/02 data retention/set-as-baseline.png differ
diff --git a/src/data/markdown/docs/03 cloud/06 Cloud FAQ/images/05 team member org id/projects-in-app.png b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/images/05 team member org id/projects-in-app.png
new file mode 100644
index 0000000000..3242bfcc91
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/images/05 team member org id/projects-in-app.png differ
diff --git a/src/data/markdown/docs/03 cloud/06 Cloud FAQ/images/09 Calculating virtual users/calculating-the-number-of-virtual-users-to-test-1.png b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/images/09 Calculating virtual users/calculating-the-number-of-virtual-users-to-test-1.png
new file mode 100644
index 0000000000..16f3756e9d
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/images/09 Calculating virtual users/calculating-the-number-of-virtual-users-to-test-1.png differ
diff --git a/src/data/markdown/docs/03 cloud/06 Cloud FAQ/images/09 Calculating virtual users/calculating-the-number-of-virtual-users-to-test-2.png b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/images/09 Calculating virtual users/calculating-the-number-of-virtual-users-to-test-2.png
new file mode 100644
index 0000000000..a88abc8edc
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/images/09 Calculating virtual users/calculating-the-number-of-virtual-users-to-test-2.png differ
diff --git a/src/data/markdown/docs/03 cloud/06 Cloud FAQ/images/09 Calculating virtual users/calculating-the-number-of-virtual-users-to-test-3.png b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/images/09 Calculating virtual users/calculating-the-number-of-virtual-users-to-test-3.png
new file mode 100644
index 0000000000..d03a2b6673
Binary files /dev/null and b/src/data/markdown/docs/03 cloud/06 Cloud FAQ/images/09 Calculating virtual users/calculating-the-number-of-virtual-users-to-test-3.png differ
diff --git a/src/data/markdown/docs/03 cloud/07 Cloud REST API/07 Cloud REST API.md b/src/data/markdown/docs/03 cloud/07 Cloud REST API/07 Cloud REST API.md
new file mode 100644
index 0000000000..442b9485ef
--- /dev/null
+++ b/src/data/markdown/docs/03 cloud/07 Cloud REST API/07 Cloud REST API.md
@@ -0,0 +1,4 @@
+---
+title: 'Cloud REST API'
+redirect: 'http://developers.loadimpact.com/'
+---
diff --git a/src/data/markdown/docs/04 integrations/01 Converters/01 har-to-k6.md b/src/data/markdown/docs/04 integrations/01 Converters/01 har-to-k6.md
new file mode 100644
index 0000000000..65c8f47750
--- /dev/null
+++ b/src/data/markdown/docs/04 integrations/01 Converters/01 har-to-k6.md
@@ -0,0 +1,4 @@
+---
+title: 'HAR-to-k6'
+redirect: 'https://github.com/loadimpact/har-to-k6'
+---
diff --git a/src/data/markdown/docs/04 integrations/01 Converters/02 jmeter-to-k6.md b/src/data/markdown/docs/04 integrations/01 Converters/02 jmeter-to-k6.md
new file mode 100644
index 0000000000..0d3412bdda
--- /dev/null
+++ b/src/data/markdown/docs/04 integrations/01 Converters/02 jmeter-to-k6.md
@@ -0,0 +1,4 @@
+---
+title: 'JMeter-to-k6'
+redirect: 'https://github.com/loadimpact/jmeter-to-k6'
+---
diff --git a/src/data/markdown/docs/04 integrations/01 Converters/03 postman-to-k6.md b/src/data/markdown/docs/04 integrations/01 Converters/03 postman-to-k6.md
new file mode 100644
index 0000000000..2057c3b33e
--- /dev/null
+++ b/src/data/markdown/docs/04 integrations/01 Converters/03 postman-to-k6.md
@@ -0,0 +1,4 @@
+---
+title: 'Postman-to-k6'
+redirect: 'https://github.com/loadimpact/postman-to-k6'
+---
diff --git a/src/data/markdown/docs/04 integrations/02 CI tools/01 jenkins.md b/src/data/markdown/docs/04 integrations/02 CI tools/01 jenkins.md
new file mode 100644
index 0000000000..47e262ea67
--- /dev/null
+++ b/src/data/markdown/docs/04 integrations/02 CI tools/01 jenkins.md
@@ -0,0 +1,4 @@
+---
+title: 'Jenkins'
+redirect: 'https://k6.io/blog/integrating-load-testing-with-jenkins'
+---
diff --git a/src/data/markdown/docs/04 integrations/02 CI tools/02 circleci.md b/src/data/markdown/docs/04 integrations/02 CI tools/02 circleci.md
new file mode 100644
index 0000000000..7860963f99
--- /dev/null
+++ b/src/data/markdown/docs/04 integrations/02 CI tools/02 circleci.md
@@ -0,0 +1,4 @@
+---
+title: 'Circleci'
+redirect: 'https://k6.io/blog/integrating-load-testing-with-circleci'
+---
diff --git a/src/data/markdown/docs/04 integrations/02 CI tools/03 gitlab.md b/src/data/markdown/docs/04 integrations/02 CI tools/03 gitlab.md
new file mode 100644
index 0000000000..93a7152738
--- /dev/null
+++ b/src/data/markdown/docs/04 integrations/02 CI tools/03 gitlab.md
@@ -0,0 +1,4 @@
+---
+title: 'Gitlab'
+redirect: 'https://k6.io/blog/integrating-load-testing-with-gitlab'
+---
diff --git a/src/data/markdown/docs/04 integrations/02 CI tools/04 azure.md b/src/data/markdown/docs/04 integrations/02 CI tools/04 azure.md
new file mode 100644
index 0000000000..b3aeb000ee
--- /dev/null
+++ b/src/data/markdown/docs/04 integrations/02 CI tools/04 azure.md
@@ -0,0 +1,4 @@
+---
+title: 'Azure Pipelines'
+redirect: 'https://k6.io/blog/integrating-load-testing-with-azure-pipelines'
+---
diff --git a/src/data/markdown/docs/04 integrations/02 CI tools/05 teamcity.md b/src/data/markdown/docs/04 integrations/02 CI tools/05 teamcity.md
new file mode 100644
index 0000000000..3ab4270c60
--- /dev/null
+++ b/src/data/markdown/docs/04 integrations/02 CI tools/05 teamcity.md
@@ -0,0 +1,4 @@
+---
+title: 'TeamCity'
+redirect: 'https://k6.io/blog/load-testing-using-teamcity-and-k6'
+---
diff --git a/src/data/markdown/docs/04 integrations/02 CI tools/06 github.md b/src/data/markdown/docs/04 integrations/02 CI tools/06 github.md
new file mode 100644
index 0000000000..a98c947e7a
--- /dev/null
+++ b/src/data/markdown/docs/04 integrations/02 CI tools/06 github.md
@@ -0,0 +1,4 @@
+---
+title: 'GitHub Actions'
+redirect: 'https://k6.io/blog/load-testing-using-github-actions'
+---
diff --git a/src/data/markdown/docs/04 integrations/03 Community Integrations/01 easy-graphql.md b/src/data/markdown/docs/04 integrations/03 Community Integrations/01 easy-graphql.md
new file mode 100644
index 0000000000..6b4030d73a
--- /dev/null
+++ b/src/data/markdown/docs/04 integrations/03 Community Integrations/01 easy-graphql.md
@@ -0,0 +1,4 @@
+---
+title: 'easygraphql-load-tester'
+redirect: 'https://github.com/EasyGraphQL/easygraphql-load-tester'
+---
diff --git a/src/data/markdown/docs/04 integrations/03 Community Integrations/02 azure-integration.md b/src/data/markdown/docs/04 integrations/03 Community Integrations/02 azure-integration.md
new file mode 100644
index 0000000000..1985e12887
--- /dev/null
+++ b/src/data/markdown/docs/04 integrations/03 Community Integrations/02 azure-integration.md
@@ -0,0 +1,4 @@
+---
+title: 'k6ToAzure'
+redirect: 'https://github.com/benc-uk/smilr/blob/master/azure/load-test-reports/k6ToAzure.js'
+---
diff --git a/src/data/markdown/docs/04 integrations/04 Result Store/01 json.md b/src/data/markdown/docs/04 integrations/04 Result Store/01 json.md
new file mode 100644
index 0000000000..11d4184446
--- /dev/null
+++ b/src/data/markdown/docs/04 integrations/04 Result Store/01 json.md
@@ -0,0 +1,4 @@
+---
+title: 'JSON'
+redirect: 'https://k6.io/docs/getting-started/results-output/json'
+---
diff --git a/src/data/markdown/docs/04 integrations/04 Result Store/02 influxdb-grafana.md b/src/data/markdown/docs/04 integrations/04 Result Store/02 influxdb-grafana.md
new file mode 100644
index 0000000000..68657cad97
--- /dev/null
+++ b/src/data/markdown/docs/04 integrations/04 Result Store/02 influxdb-grafana.md
@@ -0,0 +1,4 @@
+---
+title: 'InfluxDB/Grafana'
+redirect: 'https://k6.io/docs/getting-started/results-output/influxdb'
+---
diff --git a/src/data/markdown/docs/04 integrations/04 Result Store/03 kafka.md b/src/data/markdown/docs/04 integrations/04 Result Store/03 kafka.md
new file mode 100644
index 0000000000..7411be05f4
--- /dev/null
+++ b/src/data/markdown/docs/04 integrations/04 Result Store/03 kafka.md
@@ -0,0 +1,4 @@
+---
+title: 'Apache Kafka'
+redirect: 'https://k6.io/docs/getting-started/results-output/apache-kafka'
+---
diff --git a/src/data/markdown/docs/04 integrations/04 Result Store/04 datadog.md b/src/data/markdown/docs/04 integrations/04 Result Store/04 datadog.md
new file mode 100644
index 0000000000..1f285f360d
--- /dev/null
+++ b/src/data/markdown/docs/04 integrations/04 Result Store/04 datadog.md
@@ -0,0 +1,4 @@
+---
+title: 'DataDog'
+redirect: 'https://k6.io/docs/getting-started/results-output/datadog'
+---
diff --git a/src/data/markdown/docs/04 integrations/04 Result Store/05 cloud-service.md b/src/data/markdown/docs/04 integrations/04 Result Store/05 cloud-service.md
new file mode 100644
index 0000000000..bc462e7c1c
--- /dev/null
+++ b/src/data/markdown/docs/04 integrations/04 Result Store/05 cloud-service.md
@@ -0,0 +1,4 @@
+---
+title: 'k6 Cloud'
+redirect: 'https://k6.io/docs/getting-started/results-output/cloud'
+---
diff --git a/src/data/markdown/docs/05 Examples/01 Examples/01 single-request.md b/src/data/markdown/docs/05 Examples/01 Examples/01 single-request.md
new file mode 100644
index 0000000000..2711cf5b54
--- /dev/null
+++ b/src/data/markdown/docs/05 Examples/01 Examples/01 single-request.md
@@ -0,0 +1,46 @@
+---
+title: 'Single request'
+excerpt: 'Example of one HTTP GET request'
+draft: 'false'
+---
+
+
+
+```js
+import http from 'k6/http';
+import { sleep, check } from 'k6';
+import { Counter } from 'k6/metrics';
+
+// A simple counter for http requests
+
+export const requests = new Counter('http_reqs');
+
+// you can specify stages of your test (ramp up/down patterns) through the options object
+// target is the number of VUs you are aiming for
+
+export const options = {
+ stages: [
+ { target: 20, duration: '1m' },
+ { target: 15, duration: '1m' },
+ { target: 0, duration: '1m' },
+ ],
+ thresholds: {
+ requests: ['count < 100'],
+ },
+};
+
+export default function() {
+ // our HTTP request, note that we are saving the response to res, which can be accessed later
+
+ const res = http.get('http://test.k6.io');
+
+ sleep(1);
+
+ const checkRes = check(res, {
+ 'status is 200': r => r.status === 200,
+ 'response body': r => r.body.indexOf('Feel free to browse'),
+ });
+}
+```
+
+
diff --git a/src/data/markdown/docs/05 Examples/01 Examples/02 http-authentication.md b/src/data/markdown/docs/05 Examples/01 Examples/02 http-authentication.md
new file mode 100644
index 0000000000..f38cced1f3
--- /dev/null
+++ b/src/data/markdown/docs/05 Examples/01 Examples/02 http-authentication.md
@@ -0,0 +1,205 @@
+---
+title: 'HTTP Authentication'
+excerpt: 'Scripting examples on how to use different authenitcation or authorization methods in your load test.'
+---
+
+Scripting examples on how to use different authentication or authorization methods in your load test.
+
+## Basic authentication
+
+
+
+```js
+import encoding from 'k6/encoding';
+import http from 'k6/http';
+import { check } from 'k6';
+
+const username = 'user';
+const password = 'passwd';
+
+export default function() {
+ const credentials = `${username}:${password}`;
+
+ // Passing username and password as part of the URL will
+ // allow us to authenticate using HTTP Basic Auth.
+ const url = `http://${credentials}@httpbin.org/basic-auth/${username}/${password}`;
+
+ let res = http.get(url);
+
+ // Verify response
+ check(res, {
+ 'status is 200': r => r.status === 200,
+ 'is authenticated': r => r.json().authenticated === true,
+ 'is correct user': r => r.json().user === username,
+ });
+
+ // Alternatively you can create the header yourself to authenticate
+ // using HTTP Basic Auth
+ const encodedCredentials = encoding.b64encode(credentials);
+ const options = {
+ headers: {
+ Authorization: `Basic ${encodedCredentials}`,
+ },
+ };
+
+ res = http.get(
+ `http://httpbin.org/basic-auth/${username}/${password}`,
+ options,
+ );
+
+ // Verify response (checking the echoed data from the httpbin.org
+ // basic auth test API endpoint)
+ check(res, {
+ 'status is 200': r => r.status === 200,
+ 'is authenticated': r => r.json().authenticated === true,
+ 'is correct user': r => r.json().user === username,
+ });
+}
+```
+
+
+
+## Digest authentication
+
+
+
+```js
+import http from 'k6/http';
+import { check } from 'k6';
+
+const username = 'user';
+const password = 'passwd';
+
+export default function() {
+ // Passing username and password as part of URL plus the auth option will
+ // authenticate using HTTP Digest authentication.
+ const credentials = `${username}:${password}`;
+ const res = http.get(
+ `http://${credentials}@httpbin.org/digest-auth/auth/${username}/${password}`,
+ { auth: 'digest' },
+ );
+
+ // Verify response (checking the echoed data from the httpbin.org digest auth
+ // test API endpoint)
+ check(res, {
+ 'status is 200': r => r.status === 200,
+ 'is authenticated': r => r.json().authenticated === true,
+ 'is correct user': r => r.json().user === username,
+ });
+}
+```
+
+
+
+## NTLM authentication
+
+
+
+```js
+import http from 'k6/http';
+
+const username = 'user';
+const password = 'passwd';
+
+export default function() {
+ // Passing username and password as part of URL and then specifying
+ // "ntlm" as auth type will do the trick!
+ const credentials = `${username}:${password}`;
+ let res = http.get(`http://${credentials}@example.com/`, { auth: 'ntlm' });
+}
+```
+
+
+
+## AWS Signature v4 authentication
+
+Requests to the AWS APIs requires a special type of auth, called AWS Signature Version 4. k6
+does not support this authentication mechanism out of the box, so we'll have to resort to using
+a Node.js library called [awsv4.js](https://github.com/mhart/aws4) and
+[Browserify](http://browserify.org/) (to make it work in k6).
+
+There are a few steps required to make this work:
+
+1. Make sure you have the necessary prerequisites installed: [Node.js](https://nodejs.org/en/download/)
+ and [Browserify](http://browserify.org/)
+2. Install the `awsv4.js` library:
+
+
+
+Here's an example script to list all the regions available in EC2. Note that the AWS access key
+and secret key needs to be provided through [environment variables](/using-k6/environment-variables).
+
+> ### ⚠️ CPU- and Memory-heavy
+>
+> As the browserified version of this Node.js library includes several Node.js APIs
+> implemented in pure JS (including crypto APIs) it will be quite heavy on CPU and memory hungry
+> when run with more than just a few VUs.
+
+
+
+```js
+
+import http from 'k6/http';
+import { sleep } from 'k6';
+
+// Import browserified AWSv4 signature library
+import aws4 from './aws4.js';
+
+// Get AWS credentials from environment variables
+const AWS_CREDS = {
+ accessKeyId: __ENV.AWS_ACCESSKEY,
+ secretAccessKey: __ENV.AWS_SECRETKEY,
+};
+
+export default function() {
+ // Sign the AWS API request
+ const signed = aws4.sign(
+ {
+ service: 'ec2',
+ path: '/?Action=DescribeRegions&Version=2014-06-15',
+ },
+ AWS_CREDS,
+ );
+
+ // Make the actual request to the AWS API including the
+ // "Authorization" header with the signature
+ let res = http.get(
+ `https://${signed.hostname}${signed.path}`,
+ { headers: signed.headers },
+ );
+
+ // Print the response
+ console.log(res.body);
+
+ sleep(1);
+}
+```
+
+
diff --git a/src/data/markdown/docs/05 Examples/01 Examples/03 correlation-and-dynamic-data.md b/src/data/markdown/docs/05 Examples/01 Examples/03 correlation-and-dynamic-data.md
new file mode 100644
index 0000000000..db5b0a0616
--- /dev/null
+++ b/src/data/markdown/docs/05 Examples/01 Examples/03 correlation-and-dynamic-data.md
@@ -0,0 +1,110 @@
+---
+title: 'Correlation and Dynamic Data'
+excerpt: |
+ Scripting examples on how to correlate dynamic data in your test script. Correlation is
+ often required when using the Chrome Extension or HAR converter to generate your test script.
+ This is due to the fact that those tools will capture session IDs, CSRF tokens, VIEWSTATE,
+ wpnonce, and other dynamic values from your specific session.
+---
+
+Scripting examples on how to correlate dynamic data in your test script. Correlation is often
+required when using the Chrome Extension or HAR converter to generate your test script. This
+is because those tools will capture session IDs, CSRF tokens, VIEWSTATE, wpnonce, and other
+dynamic values from your specific session. These tokens typically expire very quickly. This
+is one of the most common things that users will script for when testing user journeys across
+websites or web apps.
+
+### Correlation
+
+In a load testing scenario, correlation means extracting one or more values from the response
+of one request and then reusing them in subsequent requests. Often, this could be getting
+a token or some sort of ID necessary to fulfill a sequence of steps in a user journey.
+
+The [browser recording](/using-k6/session-recording-har-support) will for example capture things like CSRF tokens,
+VIEWSTATES, nonce, etc. from your session. This type of data is likely to no longer be valid when
+you run your test, meaning you'll need to handle the extraction of this data from the HTML/form
+to include it in subsequent requests. This issue is fairly common with any site that has forms
+and can be handled with a little bit of scripting.
+
+### Extracting values/tokens from JSON response
+
+
+
+```js
+import http from 'k6/http';
+import { check } from 'k6';
+
+export default function() {
+ // Make a request that returns some JSON data
+ let res = http.get('https://httpbin.org/json');
+
+ // Extract data from that JSON data by first parsing it
+ // using a call to "json()" and then accessing properties by
+ // navigating the JSON data as a JS object with dot notation.
+ let slide1 = res.json().slideshow.slides[0];
+ check(slide1, {
+ 'slide 1 has correct title': s => s.title === 'Wake up to WonderWidgets!',
+ 'slide 1 has correct type': s => s.type === 'all',
+ });
+
+ // Now we could use the "slide1" variable in subsequent requests...
+}
+```
+
+
+
+**Relevant k6 APIs**:
+
+- [Response.json()](/javascript-api/k6-http/response-k6-http)
+- [JSON.parse()](https://developer.mozilla.org/en-US/Web/JavaScript/Reference/Global_Objects/JSON/parse)
+ (An alternative API that can be used for parsing JSON data)
+
+### Extracting values/tokens from form fields
+
+There are primarily two different ways you can choose from when deciding how to handle form
+submissions. Either you use the higher-level [Response.submitForm([params])](/javascript-api/k6-http/response/response-submitform-params) API
+or you extract necessary hidden fields etc. and build a request yourself and then send it using the
+appropriate `http.*` family of APIs, like [http.post(url, [body], [params])](/javascript-api/k6-http/post-url-body-params).
+
+#### Extracting .NET ViewStates, CSRF tokens and other hidden input fields
+
+
+
+```js
+import http from "k6/http";
+import {sleep} from "k6";
+
+export default function() {
+
+ // Request the page containing a form and save the response. This gives you access
+ //to the response object, `res`.
+ const res = http.get("https://test.k6.io/my_messages.php", {"responseType": "text"});
+
+ // Query the HTML for an input field named "redir". We want the value or "redir"
+ const elem = res.html().find('input[name=redir]');
+
+ // Get the value of the attribute "value" and save it to a variable
+ const val = elem.attr('value');
+
+ // Now you can concatenate this extracted value in subsequent requests that require it.
+ ...
+ // console.log() works when executing k6 scripts locally and is handy for debugging purposes
+ console.log("The value of the hidden field redir is: " + val);
+
+ sleep(1);
+}
+```
+
+
+
+> ### ⚠️ Did you know?
+>
+> Take note if `discardResponseBodies` is set to true in the options
+> section of your script. If it is, you can either make it `false` or save the response per
+> request with `{"responseType": "text"}` as shown in the example.
+
+**Relevant k6 APIs**:
+
+- [Selection.find(selector)](/javascript-api/k6-html/selection/selection-find-selector) (the [jQuery Selector API](http://api.jquery.com/category/selectors/)
+ docs are also a good resource on what possible selector queryies can be made)
+- [Selection.attr(name)](/javascript-api/k6-html/selection/selection-attr-name)
diff --git a/src/data/markdown/docs/05 Examples/01 Examples/04 data-parameterization.md b/src/data/markdown/docs/05 Examples/01 Examples/04 data-parameterization.md
new file mode 100644
index 0000000000..7fba5d1c0b
--- /dev/null
+++ b/src/data/markdown/docs/05 Examples/01 Examples/04 data-parameterization.md
@@ -0,0 +1,149 @@
+---
+title: 'Data Parameterization'
+excerpt: |
+ Scripting examples on how to parameterize data in a test script. Parameterization is typically
+ necessary when Virtual Users(VUs) will make a POST, PUT, or PATCH request in a test.
+
+ Parameterization helps to prevent server-side caching from impacting your load test.
+ This will, in turn, make your test more realistic.
+---
+
+Scripting examples on how to parameterize data in a test script. Parameterization is typically
+necessary when Virtual Users(VUs) will make a POST, PUT, or PATCH request in a test.
+
+Parameterization helps to prevent server-side caching from impacting your load test.
+This will, in turn, make your test more realistic.
+
+
+## From a JSON file
+
+
+
+```js
+
+const data = JSON.parse(open('./data.json'));
+
+export default function() {
+ let user = data.users[0];
+ console.log(data.users[0].username);
+}
+```
+
+
+
+## From a CSV file
+
+As k6 doesn't support parsing CSV files natively, we'll have to resort to using a
+library called [Papa Parse](https://www.papaparse.com/).
+
+You can download the library and and import it locally like this:
+
+
+
+Or you can grab it directly from [jslib.k6.io](https://jslib.k6.io/) like this.
+
+
+
+```JavaScript
+import papaparse from "https://jslib.k6.io/papaparse/5.1.1/index.js"
+
+// Load CSV file and parse it using Papa Parse
+const csvData = papaparse.parse(open('./data.csv'), { header: true });
+
+export default function() {
+ // ...
+}
+```
+
+
+
+Here's an example using Papa Parse to parse a CSV file of username/password pairs and using that
+data to login to the test.k6.io test site:
+
+
+
+```js
+/* Where contents of data.csv is:
+
+ username,password
+ admin,123
+ test_user,1234
+*/
+import http from 'k6/http';
+import { check, sleep } from 'k6';
+import papaparse from "https://jslib.k6.io/papaparse/5.1.1/index.js"
+
+// Load CSV file and parse it using Papa Parse
+const csvData = papaparse.parse(open('./data.csv'), { header: true }).data;
+
+export default function() {
+ // Now you can use the CSV data in your test logic below.
+ // Below are some examples of how you can access the CSV data.
+
+ // Loop through all username/password pairs
+ csvData.forEach(userPwdPair => {
+ console.log(JSON.stringify(userPwdPair));
+ });
+
+ // Pick a random username/password pair
+ let randomUser =
+ csvData[Math.floor(Math.random() * csvData.length)];
+ console.log('Random user: ', JSON.stringify(randomUser));
+
+ const params = {
+ login: randomUser.username,
+ password: randomUser.password,
+ };
+
+ let res = http.post('https://test.k6.io/login.php', params);
+ check(res, {
+ 'login succeeded': r =>
+ r.status === 200 && r.body.indexOf('successfully authorized') !== -1,
+ });
+
+ sleep(1);
+}
+```
+
+
+
+
+
+
+
+> ### ⚠️ Strive to keep the data files small
+> Each VU in k6 will have its separate copy of the data file.
+> If your script uses 300 VUs, there will be 300 copies of the data file in memory.
+> Cloud service allots 8GB of memory for every 300VUs.
+> When executing cloud tests, make sure your data files aren't exceeding this limit or your test run may get aborted.
+
+
+
+## Generating data
+
+See [this example project on GitHub](https://github.com/k6io/example-data-generation) showing how to use faker.js to generate realistic data at runtime.
\ No newline at end of file
diff --git a/src/data/markdown/docs/05 Examples/01 Examples/05 html-forms.md b/src/data/markdown/docs/05 Examples/01 Examples/05 html-forms.md
new file mode 100644
index 0000000000..41d0a20352
--- /dev/null
+++ b/src/data/markdown/docs/05 Examples/01 Examples/05 html-forms.md
@@ -0,0 +1,41 @@
+---
+title: "HTML Forms"
+excerpt: "Scripting example on how to handle HTML forms in a load test."
+---
+
+Scripting example on how to handle HTML forms in a load test.
+
+### Filling in and submitting forms
+One of the most tedious tasks when testing websites and apps are to get all the form filling to
+work. You have to get all the so-called "correlations" ([see above](/examples/correlation-and-dynamic-data)) correct
+which can take time, even with the help of a scenario recorder as the starting point for getting
+the basic user journey down into a re-playable test.
+
+
+
+```js
+import http from "k6/http";
+import {sleep} from "k6";
+
+export default function() {
+ // Request page containing a form
+ let res = http.get("https://httpbin.org/forms/post");
+
+ // Now, submit form setting/overriding some fields of the form
+ res = res.submitForm({
+ formSelector: 'form[action="/post"]',
+ fields: { custname: "test", extradata: "test2" },
+ submitSelector: "mySubmit",
+ });
+
+ sleep(3);
+}
+```
+
+
+
+**Relevant k6 APIs**:
+- [Response.submitForm([params])](/javascript-api/k6-http/response/response-submitform-params)
+- [Selection.find(selector)](/javascript-api/k6-html/selection/selection-find-selector)
+ (the [jQuery Selector API](http://api.jquery.com/category/selectors/) docs are also a good
+ resource on what possible selector queries can be made)
diff --git a/src/data/markdown/docs/05 Examples/01 Examples/06 cookies-example.md b/src/data/markdown/docs/05 Examples/01 Examples/06 cookies-example.md
new file mode 100644
index 0000000000..648adf30d6
--- /dev/null
+++ b/src/data/markdown/docs/05 Examples/01 Examples/06 cookies-example.md
@@ -0,0 +1,113 @@
+---
+title: "Cookies Example"
+excerpt: "Scripting examples on how you can interact with cookies during your load test if required."
+---
+
+Scripting examples on how you can interact with cookies during your load test if required.
+
+## Cookies
+As HTTP is a stateless protocol, cookies are used by server-side applications to persist data
+on client machines. This is used more or less everywhere on the web, commonly for user session
+tracking purposes. In k6 cookies are managed automatically by default, however, there are use
+cases where access to read and manipulate cookies are required.
+
+## From the response headers
+
+
+
+```js
+import http from "k6/http";
+import { check, group } from "k6";
+
+export default function() {
+ // Since this request redirects the `res.cookies` property won't contain the cookies
+ let res = http.get("http://httpbin.org/cookies/set?name1=value1&name2=value2");
+ check(res, {
+ "status is 200": (r) => r.status === 200
+ });
+
+ // Make sure cookies have been added to VU cookie jar
+ let vuJar = http.cookieJar();
+ let cookiesForURL = vuJar.cookiesForURL(res.url);
+ check(null, {
+ "vu jar has cookie 'name1'": () => cookiesForURL.name1.length > 0,
+ "vu jar has cookie 'name2'": () => cookiesForURL.name2.length > 0
+ });
+}
+```
+
+
+
+## Log all the cookies in a response
+> ### ⚠️ Note that this only works when using k6 locally
+>
+> The `console.log()` family of APIs are currently only usable when running k6 locally.
+> When running k6 tests with LoadImpact Cloud Execution the logs will be discarded.
+
+
+
+```js
+
+// Example showing two methods how to log all cookies (with attributes) from a HTTP response.
+
+import http from "k6/http";
+
+function logCookie(cookie) {
+ // Here we log the name and value of the cookie along with additional attributes.
+ // For full list of attributes see: https://k6.io/docs/using-k6/cookies#properties-of-a-response-cookie-object
+ console.log(`${cookie.name}: ${cookie.value}\n\tdomain: ${cookie.domain}\n\tpath: ${cookie.path}\n\texpires: ${cookie.expires}\n\thttpOnly: ${cookie.http_only}`);
+}
+
+export default function() {
+ let res = http.get("https://www.google.com/");
+
+ // Method 1: Use for-loop and check for non-inherited properties
+ for (var name in res.cookies) {
+ if (res.cookies.hasOwnProperty(name) !== undefined) {
+ logCookie(res.cookies[name][0]);
+ }
+ }
+
+ // Method 2: Use ES6 Map to loop over Object entries
+ new Map(Object.entries(res.cookies)).forEach((v, k) => logCookie(v[0]) );
+}
+```
+
+
+
+## Setting a cookie in the VU cookie jar
+To set a cookie that should be sent with every request matching a particular domain, path, etc.
+you'd do something like this:
+
+
+
+```js
+import http from "k6/http";
+import { check } from "k6";
+
+export default function() {
+ // Get VU cookie jar and add a cookie to it providing the parameters
+ // that a request must match (domain, path, HTTPS or not etc.)
+ // to have the cookie attached to it when sent to the server.
+ let jar = http.cookieJar();
+ jar.set("https://httpbin.org/cookies", "my_cookie", "hello world",
+ { domain: "httpbin.org", path: "/cookies", secure: true, max_age: 600 });
+
+ // As the following request is matching the above cookie in terms of domain,
+ // path, HTTPS (secure) and will happen within the specified "age" limit, the
+ // cookie will be attached to this request.
+ let res = http.get("https://httpbin.org/cookies");
+ check(res, {
+ "has status 200": (r) => r.status === 200,
+ "has cookie 'my_cookie'": (r) => r.json().cookies.my_cookie !== null,
+ "cookie has correct value": (r) => r.json().cookies.my_cookie == "hello world"
+ });
+}
+```
+
+
+
+**Relevant k6 APIs**:
+- [http.CookieJar](/javascript-api/k6-http/cookiejar-k6-http)
+ - [set(name, value, [options])](/javascript-api/k6-http/cookiejar/cookiejar-set-name-value-options)
+- [http.cookieJar()](/javascript-api/k6-http/cookiejar)
diff --git a/src/data/markdown/docs/05 Examples/01 Examples/07 data-uploads.md b/src/data/markdown/docs/05 Examples/01 Examples/07 data-uploads.md
new file mode 100644
index 0000000000..9d22f4cb32
--- /dev/null
+++ b/src/data/markdown/docs/05 Examples/01 Examples/07 data-uploads.md
@@ -0,0 +1,61 @@
+---
+title: "Data Uploads"
+excerpt: "Scripting examples on how to execute a load test that will upload a file to the System Under Test(SUT)."
+---
+
+Scripting examples on how to execute a load test that will upload a file to the System Under Test(SUT).
+
+## Binary file upload
+
+
+
+```js
+import http from "k6/http";
+import { sleep } from "k6";
+
+const binFile = open("/path/to/file.bin", "b");
+
+export default function() {
+ var data = {
+ file: http.file(binFile, "test.bin")
+ };
+ var res = http.post("https://example.com/upload", data);
+ sleep(3);
+}
+```
+
+
+
+### Relevant k6 APIs
+- [open(filePath, [mode])](/javascript-api/init-context/open-filepath-mode)
+- [http.file(data, [filename], [contentType])](/javascript-api/k6-http/file-data-filename-contenttype)
+
+## Creating a multipart request
+With multipart requests, you combine pieces of data with possibly different content types into one
+request body. A common scenario is, for example, a form with regular text input fields and a file
+field used for uploading a file:
+
+
+
+```js
+import http from "k6/http";
+import { sleep } from "k6";
+
+let file = open("/path/to/file.txt");
+
+export default function() {
+ var data = {
+ field: "this is a standard form field",
+ file: http.file(file, "test.txt")
+ };
+ var res = http.post("https://example.com/upload", data);
+ sleep(3);
+}
+```
+
+
+
+### Relevant k6 APIs
+- [open(filePath, [mode])](/javascript-api/init-context/open-filepath-mode)
+- [http.file(data, [filename], [contentType])](/javascript-api/k6-http/file-data-filename-contenttype)
+
diff --git a/src/data/markdown/docs/05 Examples/01 Examples/08 advanced-api-flow.md b/src/data/markdown/docs/05 Examples/01 Examples/08 advanced-api-flow.md
new file mode 100644
index 0000000000..847268b821
--- /dev/null
+++ b/src/data/markdown/docs/05 Examples/01 Examples/08 advanced-api-flow.md
@@ -0,0 +1,136 @@
+---
+title: "Advanced API flow"
+excerpt: "This example covers the usage of different k6 APIs for API load testing."
+---
+
+
+
+```js
+ import http from 'k6/http';
+ import {check, group, sleep, fail} from 'k6';
+
+ export let options = {
+ stages: [
+ { target: 70, duration: '30s' },
+ ],
+ thresholds: {
+ 'http_req_duration': ['p(95)<500', 'p(99)<1500'],
+ 'http_req_duration{name:PublicCrocs}': ['avg<400'],
+ 'http_req_duration{name:Create}': ['avg<600', 'max<1000'],
+ },
+ };
+
+ function randomString(length) {
+ const charset = 'abcdefghijklmnopqrstuvwxyz';
+ let res = '';
+ while (length--) res += charset[Math.random() * charset.length | 0];
+ return res;
+ }
+
+ const USERNAME = `${randomString(10)}@example.com`; // Set your own email or `${randomString(10)}@example.com`;
+ const PASSWORD = 'superCroc2019';
+ const BASE_URL = 'https://test-api.k6.io';
+
+ export function setup() {
+ // register a new user and authenticate via a Bearer token.
+ let res = http.post(`${BASE_URL}/user/register/`, {
+ first_name: 'Crocodile',
+ last_name: 'Owner',
+ username: USERNAME,
+ password: PASSWORD,
+ });
+
+ check(res, { 'created user': (r) => r.status === 201 });
+
+ let loginRes = http.post(`${BASE_URL}/auth/token/login/`, {
+ username: USERNAME,
+ password: PASSWORD
+ });
+
+ let authToken = loginRes.json('access');
+ check(authToken, { 'logged in successfully': () => authToken !== '', });
+
+ return authToken;
+ }
+
+
+ export default (authToken) => {
+ const requestConfigWithTag = tag => ({
+ headers: {
+ Authorization: `Bearer ${authToken}`
+ },
+ tags: Object.assign({}, {
+ name: 'PrivateCrocs'
+ }, tag)
+ });
+
+ group('Public endpoints', () => {
+ // call some public endpoints in a batch
+ let responses = http.batch([
+ ['GET', `${BASE_URL}/public/crocodiles/1/`, null, {tags: {name: 'PublicCrocs'}}],
+ ['GET', `${BASE_URL}/public/crocodiles/2/`, null, {tags: {name: 'PublicCrocs'}}],
+ ['GET', `${BASE_URL}/public/crocodiles/3/`, null, {tags: {name: 'PublicCrocs'}}],
+ ['GET', `${BASE_URL}/public/crocodiles/4/`, null, {tags: {name: 'PublicCrocs'}}],
+ ]);
+
+ const ages = Object.values(responses).map(res => res.json('age'));
+
+ // Functional test: check that all the public crocodiles are older than 5
+ check(ages, {
+ 'Crocs are older than 5 years of age': Math.min(...ages) > 5
+ });
+ });
+
+ group('Create and modify crocs', () => {
+ let URL = `${BASE_URL}/my/crocodiles/`;
+
+ group('Create crocs', () => {
+ const payload = {
+ name: `Name ${randomString(10)}`,
+ sex: 'M',
+ date_of_birth: '2001-01-01',
+ };
+
+ const res = http.post(URL, payload, requestConfigWithTag({ name: 'Create' }));
+
+ if (check(res, { 'Croc created correctly': (r) => r.status === 201 })) {
+ URL = `${URL}${res.json('id')}/`;
+ } else {
+ console.log(`Unable to create a Croc ${res.status} ${res.body}`);
+ return
+ }
+ });
+
+ group('Update croc', () => {
+ const payload = { name: 'New name' };
+ const res = http.patch(URL, payload, requestConfigWithTag({ name: 'Update' }));
+ const isSuccessfulUpdate = check(res, {
+ 'Update worked': () => res.status === 200,
+ 'Updated name is correct': () => res.json('name') === 'New name',
+ });
+
+ if (!isSuccessfulUpdate) {
+ console.log(`Unable to update the croc ${res.status} ${res.body}`);
+ return
+ }
+ });
+
+ const delRes = http.del(URL, null, requestConfigWithTag({ name: 'Delete' }));
+
+ const isSuccessfulDelete = check(null, {
+ 'Croc was deleted correctly': () => delRes.status === 204,
+ });
+
+ if (!isSuccessfulDelete) {
+ console.log(`Croc was not deleted properly`);
+ return
+ }
+ });
+
+ sleep(1);
+ }
+
+
+```
+
+
diff --git a/src/data/markdown/docs/05 Examples/01 Examples/09 generating-uuids.md b/src/data/markdown/docs/05 Examples/01 Examples/09 generating-uuids.md
new file mode 100644
index 0000000000..71efc03275
--- /dev/null
+++ b/src/data/markdown/docs/05 Examples/01 Examples/09 generating-uuids.md
@@ -0,0 +1,65 @@
+---
+title: "Generating UUIDs"
+excerpt: "Scripting example on how to generate UUIDs in your load test."
+---
+
+Scripting example on how to generate UUIDs in your load test.
+
+## Generate v1 and v4 UUIDs
+Universally unique identifiers are handy in many scenarios, as k6 doesn't have built-in support
+for UUIDs, we'll have to resort to using a Node.js library called [uuid](https://www.npmjs.com/package/uuid)
+and [Browserify](http://browserify.org/) (to make it work in k6).
+
+There are a few steps required to make this work:
+
+1. Make sure you have the necessary prerequisites installed:
+ [Node.js](https://nodejs.org/en/download/) and [Browserify](http://browserify.org/)
+
+2. Install the `uuid` library:
+
+
+
+Here's an example generating a v1 and v4 UUID:
+
+
+
+```js
+import uuid from "./uuid.js";
+
+export default function() {
+ // Generate a UUID v1
+ let uuid1 = uuid.v1();
+ console.log(uuid1);
+
+ // Generate a UUID v4
+ let uuid4 = uuid.v4();
+ console.log(uuid4);
+}
+```
+
+
diff --git a/src/data/markdown/docs/05 Examples/01 Examples/10 http2.md b/src/data/markdown/docs/05 Examples/01 Examples/10 http2.md
new file mode 100644
index 0000000000..76d3ec1078
--- /dev/null
+++ b/src/data/markdown/docs/05 Examples/01 Examples/10 http2.md
@@ -0,0 +1,25 @@
+---
+title: "HTTP2"
+excerpt: "Information on how to load test HTTP/2."
+---
+
+If the target system indicates that a connection can be upgraded from HTTP/1.1 to HTTP/2, k6 will do so automatically.
+
+## Making HTTP/2 requests
+
+
+
+```js
+import http from "k6/http";
+import { check } from "k6";
+
+export default function() {
+ let res = http.get("https://test-api.k6.io/");
+ check(res, {
+ "status is 200": (r) => r.status === 200,
+ "protocol is HTTP/2": (r) => r.proto === "HTTP/2.0",
+ });
+}
+```
+
+
diff --git a/src/data/markdown/docs/05 Examples/01 Examples/11 websockets.md b/src/data/markdown/docs/05 Examples/01 Examples/11 websockets.md
new file mode 100644
index 0000000000..7b634616f5
--- /dev/null
+++ b/src/data/markdown/docs/05 Examples/01 Examples/11 websockets.md
@@ -0,0 +1,51 @@
+---
+title: "Websockets"
+excerpt: "Scripting example on how to test websocket APIs."
+---
+
+
+## Testing a WebSocket API
+
+
diff --git a/src/data/markdown/docs/05 Examples/01 Examples/12 soap.md b/src/data/markdown/docs/05 Examples/01 Examples/12 soap.md
new file mode 100644
index 0000000000..f3de087f73
--- /dev/null
+++ b/src/data/markdown/docs/05 Examples/01 Examples/12 soap.md
@@ -0,0 +1,43 @@
+---
+title: "SOAP"
+excerpt: "Load Testing SOAP API."
+---
+
+Although k6 doesn't have any built-in APIs for working with SOAP or XML data in general, you
+can still easily load test a SOAP-based API by crafting SOAP messages and using the HTTP request APIs.
+
+## Making SOAP requests
+
+
+
+```js
+import http from "k6/http";
+import { check, sleep } from "k6";
+
+const soapReqBody = `
+
+
+
+ UnitedStates
+
+
+`;
+
+export default function() {
+ // When making a SOAP POST request we must not forget to set the content type to text/xml
+ let res = http.post(
+ "http://www.holidaywebservice.com/HolidayService_v2/HolidayService2.asmx?wsdl",
+ soapReqBody,
+ {headers: { 'Content-Type': 'text/xml' }});
+
+ // Make sure the response is correct
+ check(res, {
+ 'status is 200': (r) => r.status === 200,
+ 'black friday is present': (r) => r.body.indexOf('BLACK-FRIDAY') !== -1
+ });
+
+ sleep(1);
+}
+```
+
+
diff --git a/src/data/markdown/docs/05 Examples/01 Examples/13 tls.md b/src/data/markdown/docs/05 Examples/01 Examples/13 tls.md
new file mode 100644
index 0000000000..42b3e7aba7
--- /dev/null
+++ b/src/data/markdown/docs/05 Examples/01 Examples/13 tls.md
@@ -0,0 +1,34 @@
+---
+title: "Transport Layer Security (TLS)"
+excerpt: |
+ TLS is the mechanism through which encrypted connections can be established between clients and
+ servers on the web and through which data can flow with integrity intact.
+---
+
+
diff --git a/src/data/markdown/docs/05 Examples/01 Examples/14 data generation.md b/src/data/markdown/docs/05 Examples/01 Examples/14 data generation.md
new file mode 100644
index 0000000000..eb1cfa3029
--- /dev/null
+++ b/src/data/markdown/docs/05 Examples/01 Examples/14 data generation.md
@@ -0,0 +1,6 @@
+---
+title: 'Generating realistic data'
+redirect: 'https://github.com/k6io/example-data-generation/'
+excerpt: |
+ Reference project demonstrating how to generate data with realistic traits at runtime using faker.js
+---
diff --git a/src/data/markdown/docs/05 Examples/01 Examples/15 Bundling and transpilation.md b/src/data/markdown/docs/05 Examples/01 Examples/15 Bundling and transpilation.md
new file mode 100644
index 0000000000..bca4b9b1d3
--- /dev/null
+++ b/src/data/markdown/docs/05 Examples/01 Examples/15 Bundling and transpilation.md
@@ -0,0 +1,7 @@
+---
+title: 'Bundling and transpilation'
+redirect: 'https://github.com/k6io/k6-es6/'
+excerpt: |
+ Reference project demonstrating how to use webpack and babel to bundle
+ node modules or transpile code to ES5.1+ for usage in k6 tests.
+---
\ No newline at end of file
diff --git a/src/data/markdown/docs/05 Examples/02 Tutorials/01 datadog-alerts.md b/src/data/markdown/docs/05 Examples/02 Tutorials/01 datadog-alerts.md
new file mode 100644
index 0000000000..92aeccabe4
--- /dev/null
+++ b/src/data/markdown/docs/05 Examples/02 Tutorials/01 datadog-alerts.md
@@ -0,0 +1,4 @@
+---
+title: 'Datadog alerts and Thresholds'
+redirect: 'https://k6.io/blog/datadog-alerts-fail-load-test'
+---
diff --git a/src/data/markdown/docs/05 Examples/02 Tutorials/02 postman.md b/src/data/markdown/docs/05 Examples/02 Tutorials/02 postman.md
new file mode 100644
index 0000000000..097eb26745
--- /dev/null
+++ b/src/data/markdown/docs/05 Examples/02 Tutorials/02 postman.md
@@ -0,0 +1,4 @@
+---
+title: 'Load testing with Postman'
+redirect: 'https://k6.io/blog/load-testing-with-postman-collections'
+---
diff --git a/src/data/markdown/docs/05 Examples/02 Tutorials/03 openapi.md b/src/data/markdown/docs/05 Examples/02 Tutorials/03 openapi.md
new file mode 100644
index 0000000000..3158c20315
--- /dev/null
+++ b/src/data/markdown/docs/05 Examples/02 Tutorials/03 openapi.md
@@ -0,0 +1,4 @@
+---
+title: 'Load testing with Swagger/OpenAPI'
+redirect: 'https://k6.io/blog/load-testing-your-api-with-swagger-openapi-and-k6'
+---
diff --git a/src/data/markdown/docs/05 Examples/02 Tutorials/04 cron.md b/src/data/markdown/docs/05 Examples/02 Tutorials/04 cron.md
new file mode 100644
index 0000000000..a3b4f132da
--- /dev/null
+++ b/src/data/markdown/docs/05 Examples/02 Tutorials/04 cron.md
@@ -0,0 +1,4 @@
+---
+title: 'Performance monitoring with cron'
+redirect: 'https://k6.io/blog/performance-monitoring-with-cron-and-k6'
+---
diff --git a/src/data/markdown/docs/05 Examples/02 Tutorials/05 kafka.md b/src/data/markdown/docs/05 Examples/02 Tutorials/05 kafka.md
new file mode 100644
index 0000000000..c4c1c8212d
--- /dev/null
+++ b/src/data/markdown/docs/05 Examples/02 Tutorials/05 kafka.md
@@ -0,0 +1,4 @@
+---
+title: 'k6 output to Apache Kafka'
+redirect: 'https://k6.io/blog/integrating-k6-with-apache-kafka'
+---
diff --git a/src/data/markdown/docs/05 Examples/02 Tutorials/06 graphql.md b/src/data/markdown/docs/05 Examples/02 Tutorials/06 graphql.md
new file mode 100644
index 0000000000..4a4ef54afc
--- /dev/null
+++ b/src/data/markdown/docs/05 Examples/02 Tutorials/06 graphql.md
@@ -0,0 +1,4 @@
+---
+title: 'Load testing GraphQL'
+redirect: 'https://k6.io/blog/load-testing-graphql-with-k6'
+---
diff --git a/src/data/markdown/docs/05 Examples/02 Tutorials/07 restful-apis.md b/src/data/markdown/docs/05 Examples/02 Tutorials/07 restful-apis.md
new file mode 100644
index 0000000000..d74a8c2cff
--- /dev/null
+++ b/src/data/markdown/docs/05 Examples/02 Tutorials/07 restful-apis.md
@@ -0,0 +1,4 @@
+---
+title: 'Load testing RESTful APIs'
+redirect: 'https://k6.io/blog/load-testing-restful-apis-with-k6'
+---
diff --git a/src/data/markdown/docs/05 Examples/02 Tutorials/08 control-live-test.md b/src/data/markdown/docs/05 Examples/02 Tutorials/08 control-live-test.md
new file mode 100644
index 0000000000..30d97ea500
--- /dev/null
+++ b/src/data/markdown/docs/05 Examples/02 Tutorials/08 control-live-test.md
@@ -0,0 +1,4 @@
+---
+title: 'Control a live k6 test'
+redirect: 'https://k6.io/blog/how-to-control-a-live-k6-test'
+---
diff --git a/src/data/markdown/posts/2020-01-15--load-impact-v3-end-of-life/cover-v3-end-of-life.png b/src/data/markdown/posts/2020-01-15--load-impact-v3-end-of-life/cover-v3-end-of-life.png
new file mode 100755
index 0000000000..c376fb4961
Binary files /dev/null and b/src/data/markdown/posts/2020-01-15--load-impact-v3-end-of-life/cover-v3-end-of-life.png differ
diff --git a/src/data/markdown/posts/2020-01-15--load-impact-v3-end-of-life/index.md b/src/data/markdown/posts/2020-01-15--load-impact-v3-end-of-life/index.md
new file mode 100644
index 0000000000..57e72525a0
--- /dev/null
+++ b/src/data/markdown/posts/2020-01-15--load-impact-v3-end-of-life/index.md
@@ -0,0 +1,48 @@
+---
+title: Deprecation Timeline for LoadImpact v3.0
+summary: LoadImpact v3.0 is currently being deprecated. We plan to formally shut down v3.0 on Dec 31 2020.
+category: 'Releases'
+covertext: 'V3 End Of Life'
+author: Mark Meier, Head of Customer Success
+cover: cover-v3-end-of-life.png
+socialImage: cover-v3-end-of-life.png
+featured: true
+---
+
+In 1940, the American Football Championship Game was played between the Chicago Bears and Washington Redskins. A few weeks earlier the teams faced off and Washington won with a score of 7-3. Moving into the championship game, Chicago knew they had to make a strategic move and adapt the game to regain the upper hand. For the first time in the history of American football, a new strategy was introduced, the “T-formation”. Using this strategy, Chicago handed Washington the most lopsided margins of victory in sports history (73-0) and a Scorigami. Their adaptation resulted in the team, players and fans enjoying success from their strategic planning.
+
+So what does this have to do with our deprecation timeline for v3.0? I’ll be honest - it’s more of a fun story than anything. But I think there are similarities. LoadImpact v3.0 (Lua), has been a tried and tested load and performance testing solution. It’s executed millions of tests and have helped thousands of users understand how their systems react to various levels of load. But as time ticks on, you learn that things can be improved. In our case, it made sense to come up with an entirely new way to think about testing rather than making small adaptations.
+
+The new version of LoadImpact is the result of years of feedback we’ve gathered and experienced we gained. We think it will enable strategies for you to become more efficient and come to valuable conclusions, faster. Maybe even handing your opponent a 73-0 loss.
+
+I’ve had many conversations with users regarding this transition, I’ve put together some of the most common questions and answers. If you have a question that is not listed here, please reach out using the contact info at the bottom of this post.
+
+## Why are you releasing a new version and new load generator?
+
+Based on feedback we have received from users over the years and from our own observations, we wanted to create a more modern and open source tool for testing. We set out to address the following:
+
+- CLI tool with developer-friendly APIs.
+- Load-Test-As-Code with scripting in JavaScript.
+- Easy automation and powerful performance Thresholds (Pass/Fail criteria).
+- Integrates with the LoadImpact cloud to accelerate and scale your performance testing.
+
+## What is happening to the version with Lua Scripting?
+
+As we call it, v3.0, is currently being deprecated. We plan to formally shut down v3.0 on Dec 31 2020. After this date it will not be possible to access the service, so we strongly urge you to back up and export any information you need to save.
+
+## Do I need to buy a new plan? Do I have access to v4.0?
+
+For most users, we already added a plan that gives v4.0 access to your account. Due to pricing differences, it is at some different limits than your v3.0 plan. If you would like, you can switch to one of our current v4.0 plans on our pricing page. If you feel your needs don’t fit into what we’ve enabled or what we have available, please contact us and we can discuss other potential options.
+
+You can view full details of your available plans on your Account page.
+
+## Where do I go if I need help getting used to v4.0?
+
+Myself and the rest of the customer success team are here to support you. Additionally, we have our knowledge base, extensive documentation, community forum and slack channel where you can get more information.
+
+- https://support.loadimpact.com/4.0/
+- https://docs.k6.io/docs
+- https://community.k6.io/
+- https://k6.io/slack/
+
+Finally, you are always welcome to contact us directly at support@loadimpact.com. We would be happy to set up a Q&A session or walkthrough to answer your questions after you have some time to explore v4.0 on your own.
diff --git a/src/hooks/index.js b/src/hooks/index.js
new file mode 100644
index 0000000000..8c6e44e368
--- /dev/null
+++ b/src/hooks/index.js
@@ -0,0 +1,3 @@
+import useLandmark from './useLandmark';
+
+export { useLandmark };
diff --git a/src/hooks/useLandmark.js b/src/hooks/useLandmark.js
new file mode 100644
index 0000000000..b26c37800c
--- /dev/null
+++ b/src/hooks/useLandmark.js
@@ -0,0 +1,48 @@
+import React, { useState, useEffect } from 'react';
+import ReactDOM from 'react-dom';
+import { Heading } from 'components/shared/heading';
+import { slugify } from 'utils';
+import docPageContent from 'components/templates/doc-page/doc-page-content/doc-page-content.module.scss';
+import AnchorIcon from 'components/templates/doc-page/doc-page-content/svg/anchor.inline.svg';
+
+// auxillary component that will replace default ones
+const markHeadingComponent = ({ content }) => (
+
+
+
+
+ {content}
+
+);
+
+const useLandmark = ({ selector, component = markHeadingComponent }) => {
+ const [links, setLinks] = useState([]);
+ useEffect(() => {
+ const Component = component;
+ // get all h2 headings of a parent
+ const allHeadingMarks = document
+ .querySelector(`.${selector}`)
+ .querySelectorAll('h2');
+ allHeadingMarks.forEach(element => {
+ const compContent = element.innerHTML;
+ // Render with container replacement.
+ const temp = document.createElement('div');
+ ReactDOM.render(, temp, () =>
+ element.parentElement.replaceChild(temp.children[0], element),
+ );
+ });
+ setLinks(
+ Array.from(allHeadingMarks).map(({ innerHTML }) => ({
+ title: innerHTML,
+ anchor: `#${slugify(innerHTML).replace(/\//g, '-')}`,
+ })),
+ );
+ }, []);
+ return { links };
+};
+export default useLandmark;
diff --git a/src/images/NetInfo-API-Blog-post.png b/src/images/NetInfo-API-Blog-post.png
new file mode 100644
index 0000000000..78df4165fa
Binary files /dev/null and b/src/images/NetInfo-API-Blog-post.png differ
diff --git a/src/images/about/about-story-image.png b/src/images/about/about-story-image.png
new file mode 100644
index 0000000000..edb8b9a6ff
Binary files /dev/null and b/src/images/about/about-story-image.png differ
diff --git a/src/images/about/about-team-image.png b/src/images/about/about-team-image.png
new file mode 100644
index 0000000000..f8a58ad841
Binary files /dev/null and b/src/images/about/about-team-image.png differ
diff --git a/src/images/about/about-team/bernard-alexander.png b/src/images/about/about-team/bernard-alexander.png
new file mode 100644
index 0000000000..0759617597
Binary files /dev/null and b/src/images/about/about-team/bernard-alexander.png differ
diff --git a/src/images/about/about-team/courtney-alexander.png b/src/images/about/about-team/courtney-alexander.png
new file mode 100644
index 0000000000..0759617597
Binary files /dev/null and b/src/images/about/about-team/courtney-alexander.png differ
diff --git a/src/images/about/about-team/ronald-edwards.png b/src/images/about/about-team/ronald-edwards.png
new file mode 100644
index 0000000000..0759617597
Binary files /dev/null and b/src/images/about/about-team/ronald-edwards.png differ
diff --git a/src/images/about/about-team/ted-pena.png b/src/images/about/about-team/ted-pena.png
new file mode 100644
index 0000000000..0759617597
Binary files /dev/null and b/src/images/about/about-team/ted-pena.png differ
diff --git a/src/images/cloud-illustrated-note/data-flow@2x.png b/src/images/cloud-illustrated-note/data-flow@2x.png
new file mode 100644
index 0000000000..699e772ed0
Binary files /dev/null and b/src/images/cloud-illustrated-note/data-flow@2x.png differ
diff --git a/src/images/cloud-illustrated-note/hacking-croco@2x.png b/src/images/cloud-illustrated-note/hacking-croco@2x.png
new file mode 100644
index 0000000000..63263b6f81
Binary files /dev/null and b/src/images/cloud-illustrated-note/hacking-croco@2x.png differ
diff --git a/src/images/cloud-promo@2x.png b/src/images/cloud-promo@2x.png
new file mode 100755
index 0000000000..9891fd77e4
Binary files /dev/null and b/src/images/cloud-promo@2x.png differ
diff --git a/src/images/cloud/cloud-features/first-block/01image-1@2x.jpg b/src/images/cloud/cloud-features/first-block/01image-1@2x.jpg
new file mode 100644
index 0000000000..4e132e1552
Binary files /dev/null and b/src/images/cloud/cloud-features/first-block/01image-1@2x.jpg differ
diff --git a/src/images/cloud/cloud-features/first-block/01image-2@2x.jpg b/src/images/cloud/cloud-features/first-block/01image-2@2x.jpg
new file mode 100644
index 0000000000..ab0a70f739
Binary files /dev/null and b/src/images/cloud/cloud-features/first-block/01image-2@2x.jpg differ
diff --git a/src/images/cloud/cloud-features/second-block/02image-1@2x.png b/src/images/cloud/cloud-features/second-block/02image-1@2x.png
new file mode 100644
index 0000000000..5fa2da0b1a
Binary files /dev/null and b/src/images/cloud/cloud-features/second-block/02image-1@2x.png differ
diff --git a/src/images/cloud/cloud-features/second-block/02image-2@2x.png b/src/images/cloud/cloud-features/second-block/02image-2@2x.png
new file mode 100644
index 0000000000..5a1bfd9a06
Binary files /dev/null and b/src/images/cloud/cloud-features/second-block/02image-2@2x.png differ
diff --git a/src/images/cloud/cloud-features/second-block/02image-3@2x.jpg b/src/images/cloud/cloud-features/second-block/02image-3@2x.jpg
new file mode 100644
index 0000000000..8dbe062718
Binary files /dev/null and b/src/images/cloud/cloud-features/second-block/02image-3@2x.jpg differ
diff --git a/src/images/cloud/cloud-features/third-block/03image-1@2x.jpg b/src/images/cloud/cloud-features/third-block/03image-1@2x.jpg
new file mode 100644
index 0000000000..75a8c649ab
Binary files /dev/null and b/src/images/cloud/cloud-features/third-block/03image-1@2x.jpg differ
diff --git a/src/images/cloud/cloud-features/third-block/03image-2@2x.jpg b/src/images/cloud/cloud-features/third-block/03image-2@2x.jpg
new file mode 100644
index 0000000000..909fc2911f
Binary files /dev/null and b/src/images/cloud/cloud-features/third-block/03image-2@2x.jpg differ
diff --git a/src/images/cloud/cloud-hero/cloud-promo.png b/src/images/cloud/cloud-hero/cloud-promo.png
new file mode 100755
index 0000000000..9a3045c9d9
Binary files /dev/null and b/src/images/cloud/cloud-hero/cloud-promo.png differ
diff --git a/src/images/cloud/cloud-hero/cloud-promo@3x.png b/src/images/cloud/cloud-hero/cloud-promo@3x.png
new file mode 100755
index 0000000000..7400e5511a
Binary files /dev/null and b/src/images/cloud/cloud-hero/cloud-promo@3x.png differ
diff --git a/src/images/cloud/cloud-hero/cloud-stub.png b/src/images/cloud/cloud-hero/cloud-stub.png
new file mode 100644
index 0000000000..49ae6de2c0
Binary files /dev/null and b/src/images/cloud/cloud-hero/cloud-stub.png differ
diff --git a/src/images/data-flow@2x.png b/src/images/data-flow@2x.png
new file mode 100644
index 0000000000..699e772ed0
Binary files /dev/null and b/src/images/data-flow@2x.png differ
diff --git a/src/images/doc-integrations/azure.png b/src/images/doc-integrations/azure.png
new file mode 100644
index 0000000000..b310f2650d
Binary files /dev/null and b/src/images/doc-integrations/azure.png differ
diff --git a/src/images/doc-integrations/graphql.png b/src/images/doc-integrations/graphql.png
new file mode 100644
index 0000000000..bad4a50d7a
Binary files /dev/null and b/src/images/doc-integrations/graphql.png differ
diff --git a/src/images/doc-integrations/har.jpg b/src/images/doc-integrations/har.jpg
new file mode 100644
index 0000000000..4c21cdacba
Binary files /dev/null and b/src/images/doc-integrations/har.jpg differ
diff --git a/src/images/doc-integrations/jmeter.png b/src/images/doc-integrations/jmeter.png
new file mode 100644
index 0000000000..261efeb643
Binary files /dev/null and b/src/images/doc-integrations/jmeter.png differ
diff --git a/src/images/doc-integrations/openapi.png b/src/images/doc-integrations/openapi.png
new file mode 100644
index 0000000000..a5fb84f67b
Binary files /dev/null and b/src/images/doc-integrations/openapi.png differ
diff --git a/src/images/doc-integrations/postman.png b/src/images/doc-integrations/postman.png
new file mode 100644
index 0000000000..cfd823454d
Binary files /dev/null and b/src/images/doc-integrations/postman.png differ
diff --git a/src/images/doc-welcome-quick-start/doc-welcome-quick-start-image-1.png b/src/images/doc-welcome-quick-start/doc-welcome-quick-start-image-1.png
new file mode 100644
index 0000000000..44e0e4a321
Binary files /dev/null and b/src/images/doc-welcome-quick-start/doc-welcome-quick-start-image-1.png differ
diff --git a/src/images/doc-welcome-quick-start/doc-welcome-quick-start-image-2.png b/src/images/doc-welcome-quick-start/doc-welcome-quick-start-image-2.png
new file mode 100644
index 0000000000..eeb50af6d8
Binary files /dev/null and b/src/images/doc-welcome-quick-start/doc-welcome-quick-start-image-2.png differ
diff --git a/src/images/doc-welcome-quick-start/doc-welcome-quick-start-image-3.png b/src/images/doc-welcome-quick-start/doc-welcome-quick-start-image-3.png
new file mode 100644
index 0000000000..371061e673
Binary files /dev/null and b/src/images/doc-welcome-quick-start/doc-welcome-quick-start-image-3.png differ
diff --git a/src/images/favicon.png b/src/images/favicon.png
new file mode 100644
index 0000000000..4b01474386
Binary files /dev/null and b/src/images/favicon.png differ
diff --git a/src/images/home-built-for/developers-closed.png b/src/images/home-built-for/developers-closed.png
new file mode 100644
index 0000000000..d25094d914
Binary files /dev/null and b/src/images/home-built-for/developers-closed.png differ
diff --git a/src/images/home-built-for/developers.png b/src/images/home-built-for/developers.png
new file mode 100644
index 0000000000..12b23afd72
Binary files /dev/null and b/src/images/home-built-for/developers.png differ
diff --git a/src/images/home-built-for/devops-closed.png b/src/images/home-built-for/devops-closed.png
new file mode 100644
index 0000000000..7df5f07b00
Binary files /dev/null and b/src/images/home-built-for/devops-closed.png differ
diff --git a/src/images/home-built-for/devops.png b/src/images/home-built-for/devops.png
new file mode 100644
index 0000000000..6acdfb9571
Binary files /dev/null and b/src/images/home-built-for/devops.png differ
diff --git a/src/images/home-built-for/managers-closed.png b/src/images/home-built-for/managers-closed.png
new file mode 100644
index 0000000000..f57a87238e
Binary files /dev/null and b/src/images/home-built-for/managers-closed.png differ
diff --git a/src/images/home-built-for/managers.png b/src/images/home-built-for/managers.png
new file mode 100644
index 0000000000..2de597c284
Binary files /dev/null and b/src/images/home-built-for/managers.png differ
diff --git a/src/images/how-it-works/how-it-works.png b/src/images/how-it-works/how-it-works.png
new file mode 100644
index 0000000000..505a73e9f5
Binary files /dev/null and b/src/images/how-it-works/how-it-works.png differ
diff --git a/src/images/how-it-works/stub.png b/src/images/how-it-works/stub.png
new file mode 100644
index 0000000000..bb474cce63
Binary files /dev/null and b/src/images/how-it-works/stub.png differ
diff --git a/src/images/icon.png b/src/images/icon.png
new file mode 100644
index 0000000000..0419299be0
Binary files /dev/null and b/src/images/icon.png differ
diff --git a/src/images/landscape-icon.png b/src/images/landscape-icon.png
new file mode 100644
index 0000000000..99232924a8
Binary files /dev/null and b/src/images/landscape-icon.png differ
diff --git a/src/images/native-automation-instruction/native-automation-fourth-step-image.png b/src/images/native-automation-instruction/native-automation-fourth-step-image.png
new file mode 100644
index 0000000000..52d097a618
Binary files /dev/null and b/src/images/native-automation-instruction/native-automation-fourth-step-image.png differ
diff --git a/src/images/native-automation-instruction/native-automation-instruction-image.png b/src/images/native-automation-instruction/native-automation-instruction-image.png
new file mode 100644
index 0000000000..8a708448e6
Binary files /dev/null and b/src/images/native-automation-instruction/native-automation-instruction-image.png differ
diff --git a/src/images/open-source-cases/open-source-use-cases-image.png b/src/images/open-source-cases/open-source-use-cases-image.png
new file mode 100644
index 0000000000..3ce5e59874
Binary files /dev/null and b/src/images/open-source-cases/open-source-use-cases-image.png differ
diff --git a/src/images/sample-image@2x.png b/src/images/sample-image@2x.png
new file mode 100644
index 0000000000..be69cdd0a9
Binary files /dev/null and b/src/images/sample-image@2x.png differ
diff --git a/src/images/vertical-image-query-test.jpg b/src/images/vertical-image-query-test.jpg
new file mode 100644
index 0000000000..ef9acfc894
Binary files /dev/null and b/src/images/vertical-image-query-test.jpg differ
diff --git a/src/layouts/default-layout/default-layout.module.scss b/src/layouts/default-layout/default-layout.module.scss
new file mode 100644
index 0000000000..f871958fe3
--- /dev/null
+++ b/src/layouts/default-layout/default-layout.module.scss
@@ -0,0 +1,18 @@
+.button {
+ margin-right: 5px;
+
+ &:last-child {
+ margin-right: 0;
+ }
+}
+
+.buttons-wrapper {
+ @include md-down {
+ display: none;
+ }
+}
+:global .react-cookie-banner {
+ background-color: $color-primary;
+ color: $color-tertiary;
+ padding: 10px 20px;
+}
diff --git a/src/layouts/default-layout/default-layout.view.js b/src/layouts/default-layout/default-layout.view.js
new file mode 100644
index 0000000000..b5c00d9b69
--- /dev/null
+++ b/src/layouts/default-layout/default-layout.view.js
@@ -0,0 +1,116 @@
+import React from 'react';
+import {
+ Cookies,
+ CookiesProvider,
+ CookieBannerUniversal,
+} from 'react-cookie-banner';
+import HelperWidget from 'components/shared/helper-widget';
+
+import {
+ Header,
+ HeaderNav,
+ HeaderLogo,
+ Burger,
+} from 'components/blocks/header';
+import { Footer } from 'components/blocks/footer';
+import { MobileNav } from 'components/blocks/mobile-nav';
+import { SEO } from 'components/shared/seo';
+import { Button } from 'components/shared/button';
+
+import styles from './default-layout.module.scss';
+import CookieConsent from 'components/shared/cookie-consent';
+import { app, main, blog, docs } from 'utils/urls';
+
+const cookies = new Cookies({ 'user-has-accepted-cookies': true });
+
+export const DefaultLayout = ({ pageMetadata, children }) => {
+ const [isMobileNavVisible, setIsMobileNavVisible] = React.useState(false);
+
+ React.useEffect(() => {
+ if (isMobileNavVisible) {
+ document.querySelector('html').style.overflow = 'hidden';
+ } else {
+ document.querySelector('html').style.overflow = '';
+ }
+ }, [isMobileNavVisible]);
+
+ const links = [
+ { label: 'Cloud', to: `${main}/cloud` },
+ { label: 'Open Source', to: `${main}/open-source` },
+ { label: 'Documentation', to: `${docs}` },
+ { label: 'Pricing', to: `${main}/pricing` },
+ {
+ label: 'About',
+ submenu: [
+ { label: 'Our Story', to: `${main}/about` },
+ { label: 'Our Beliefs', to: `${main}/our-beliefs` },
+ { label: 'Blog', to: `${blog}` },
+ { label: 'Contact Us', to: `${main}/contact` },
+ { label: 'Jobs', to: `${main}/jobs` },
+ ],
+ },
+ ];
+
+ return (
+ <>
+
+
+
+
+ );
+}
diff --git a/src/templates/docs/cloud.js b/src/templates/docs/cloud.js
new file mode 100644
index 0000000000..981a9a4ec5
--- /dev/null
+++ b/src/templates/docs/cloud.js
@@ -0,0 +1,222 @@
+import React, { useState, useEffect } from 'react';
+import { Link } from 'gatsby';
+import { Cloud, PageInfo } from 'components/pages/doc-welcome';
+import { DocLayout } from 'layouts/doc-layout';
+import { Trait } from 'components/shared/trait';
+import htmlStyles from 'components/blocks/html-content/html-content.module.scss';
+import { StickyContainer, Sticky } from 'react-sticky';
+import { whenElementAvailable, isInIFrame } from 'utils';
+import { default as docPageContent } from 'components/templates/doc-page/doc-page-content/doc-page-content.module.scss';
+import { default as docPageNav } from 'components/pages/doc-page/doc-page-nav/doc-page-nav.module.scss';
+import SeoMetadata from 'utils/seo-metadata';
+import { app } from 'utils/urls';
+import { useLandmark } from 'hooks';
+
+export default function({ pageContext: { sidebarTree, navLinks } }) {
+ const pageMetadata = SeoMetadata.cloud;
+
+ const [showFooter, setShowFooter] = useState(true);
+
+ const { links } = useLandmark({
+ selector: docPageContent.inner,
+ });
+ useEffect(() => setShowFooter(!isInIFrame()), []);
+
+ useEffect(() => {
+ // check if given url contains hash (therefore an anchor)
+ const scrollMark = location.hash;
+ if (scrollMark) {
+ // wait when html content adds all id to h2 then scroll to it
+ whenElementAvailable(scrollMark)(el =>
+ // no smooth scroll needed
+ window.scrollTo({
+ top: el.getBoundingClientRect().top + window.scrollY - 25,
+ }),
+ );
+ }
+ }, []);
+
+ const handleAnchorClick = (e, anchor) => {
+ e.preventDefault();
+ document.querySelector(anchor).scrollIntoView({
+ behavior: 'smooth',
+ block: 'start',
+ });
+ // changing hash without default jumps to anchor
+ if (history.pushState) {
+ history.pushState(false, false, anchor);
+ } else {
+ // old browser support
+ window.location.hash = anchor;
+ }
+ };
+
+ return (
+
+
+
+
+
+
+
+
What is the k6 Cloud?
+
+ The k6 Cloud is a commercial SaaS product that we’ve designed
+ to be the perfect companion to k6 OSS. It brings ease-of-use
+ and convenience to your performance and load testing.
+
+
+ This knowledge base will help you learn how to use the
+ features and functionality of the k6 Cloud:
+
+
+
Running cloud tests.
+
Analyzing results.
+
Managing projects, teams and users.
+
Integrations.
+
FAQ.
+
+
How can it help me?
+
+ The k6 Cloud is a premium service to empower your team to
+ manage your load testing efforts:
+
+
+
Scaling your load tests.
+
Storing and visualizing your test results.
+
Detecting performance issues.
+
Correlating results between different tests.
+
Organizing testing in a central location.
+
+
+ We want you to spend time building and maintaining
+ well-performing applications. Don’t saddle your team with the
+ additional maintenance burden of your load testing
+ infrastructure.
+
+ Please get in touch with us on{' '}
+
+ Slack
+ {' '}
+ if you have a tool or add-on that works well with k6, and we
+ will list it here!
+
+
+
+
+ {({ style }) => (
+
+
+
+ )}
+
+
+
+
+ );
+}
diff --git a/src/templates/docs/javascript-api.js b/src/templates/docs/javascript-api.js
new file mode 100644
index 0000000000..cf1cf6df4c
--- /dev/null
+++ b/src/templates/docs/javascript-api.js
@@ -0,0 +1,268 @@
+import React, { useState, useEffect } from 'react';
+import classNames from 'classnames';
+import { graphql, Link } from 'gatsby';
+import { DocLayout } from 'layouts/doc-layout';
+import { PageInfo } from 'components/pages/doc-welcome/page-info';
+import { Sticky, StickyContainer } from 'react-sticky';
+import {
+ slugify,
+ stripDirectoryPath,
+ unorderify,
+ compose,
+ noSlugDuplication,
+ whenElementAvailable,
+} from 'utils';
+import htmlStyles from 'components/blocks/html-content/html-content.module.scss';
+import { default as docPageContent } from 'components/templates/doc-page/doc-page-content/doc-page-content.module.scss';
+import { default as docPageNav } from 'components/pages/doc-page/doc-page-nav/doc-page-nav.module.scss';
+import SeoMetadata from 'utils/seo-metadata';
+import { HtmlContent } from 'components/blocks/html-content';
+import { styles as codeStyles } from 'components/shared/code';
+import CustomContentContainer from 'components/shared/custom-content-container';
+import { CodeGroup } from 'components/templates/doc-page/code-group';
+import { DocBlockquote } from 'components/pages/doc-page/doc-blockquote';
+import jsApiStyles from 'components/pages/doc-javascript-api/doc-javascript-api.module.scss';
+import AnchorIcon from 'components/templates/doc-page/doc-page-content/svg/anchor.inline.svg';
+import docPage from 'templates/doc-page';
+
+// Return an array of { module:
, classes: [
...], functions: [
...] } objects.
+// Top-level documents (modules) as defined by the sidebarTree will be
+// rendered as header+content, and child documents as table rows.
+function buildIndex(nodes, sidebarTree) {
+ const index = [];
+
+ const components = {
+ '.code-group': CodeGroup,
+ h2: ({ mdBlockContent }) => (
+