Merge branch 'main' into update-adding-team-members

checkly · May 15, 2024 · 8124a54 · 8124a54
2 parents 3f9f301 + 6acee2a
commit 8124a54
Show file tree

Hide file tree

Showing 85 changed files with 1,679 additions and 101 deletions.
diff --git a/site/config.toml b/site/config.toml
@@ -87,7 +87,7 @@ disqusShortname = "checkly"
 
 [[menu.resources]]
     name = "Dashboards"
-    url = "/docs/dashboards"
+    url = "/docs/dashboards/"
     weight = 80
 
 [[menu.resources]]
@@ -140,15 +140,21 @@ disqusShortname = "checkly"
 	url = "/docs/pulumi-provider/"
 	weight = 40
 
+[[menu.integrations]]
+	name = "OpenTelemetry (beta)"
+	url = "/docs/open-telemetry/"
+	weight = 50
+	beta = true
+
 
 [[menu.reference]]
     name = "CLI Commands"
-    url = "/docs/cli/command-line-reference"
+    url = "/docs/cli/command-line-reference/"
     weight = 170
 
 [[menu.reference]]
     name = "CLI Constructs"
-    url = "/docs/cli/constructs-reference"
+    url = "/docs/cli/constructs-reference/"
     weight = 180
 
 [[menu.reference]]

diff --git a/site/content/_shared/cli-basics-for-cicd.md b/site/content/_shared/cli-basics-for-cicd.md
@@ -16,4 +16,4 @@ by using environment variables.
 
 {{< markdownpartial "/_shared/cli-env-vars.md" >}}
 
-Check the [CLI command line reference](/docs/cli/command-line-reference) for more options.
+Check the [CLI command line reference](/docs/cli/command-line-reference/) for more options.
diff --git a/site/content/_shared/otel-api-and-endpoint.md b/site/content/_shared/otel-api-and-endpoint.md
@@ -0,0 +1,36 @@
+---
+sitemapExclude: true
+---
+
+First, make sure to switch on the **Basic HTTP Instrumentation**. This will add the necessary headers to your HTTP requests.
+
+![Checkly basic OTEL http instrumentation](/docs/images/integrations/otel/otel_basic_instrumentation.png)
+
+Then, flip on the "Ingest Traces" section, grab your OTel API key in the **Ingest traces** section of the [Open Telemetry Integration page in the Checkly app](https://app.checklyhq.com/settings/account/open-telemetry) and
+take a note of the endpoint for the region you want to use.
+
+![Checkly OTEL API keys](/docs/images/integrations/otel/otel_ingest_traces.png)
+
+Now, export your API key in your shell by setting the `OTEL_EXPORTER_OTLP_HEADERS` environment variable.
+
+```bash
+export OTEL_EXPORTER_OTLP_HEADERS="authorization=Bearer <your-api-key>"
+```
+
+Next, export the endpoint for the region you want to use and give your service a name.
+```bash
+export OTEL_EXPORTER_OTLP_ENDPOINT="https://otel.eu-west-1.checklyhq.com"
+export OTEL_SERVICE_NAME="your-service-name"
+```
+
+{{< info >}}
+During the beta we only have one region available: `eu-west-1`. We will expand to US regions soon.
+{{< /info >}}
+
+We are using the standard OpenTelemetry environment variables here to configure the OTLP exporter.
+
+| Variable                      | Description                                                                               |
+|-------------------------------|-------------------------------------------------------------------------------------------|
+| `OTEL_EXPORTER_OTLP_HEADERS`  | The `Authorization` HTTP header containing your Checkly OTel API key as a `Bearer` token. |
+| `OTEL_EXPORTER_OTLP_ENDPOINT` | The Checkly OTel API endpoint for the region you want to use.                             |
+| `OTEL_SERVICE_NAME`           | The name of your service to identify it among the spans in the web UI.                    |
diff --git a/site/content/docs/CICD/vercel-deployment-protection.md b/site/content/docs/CICD/vercel-deployment-protection.md
@@ -196,7 +196,7 @@ request.headers['x-vercel-protection-bypass'] = process.env.VERCEL_BYPASS_TOKEN
 ## Password Protection
 Vercel's [Password Protection](https://vercel.com/docs/concepts/deployments/deployment-protection#password-protection) is a paid
 addon that allows you to set a dedicated password for your deployments and specifically bypass protection for E2E tests / automation.
-You can accomplish this using the resources referenced in the docs for [browser checks](/docs/browser-checks/login-scenarios#username--password-login) 
+You can accomplish this using the resources referenced in the docs for [browser checks](/docs/browser-checks/login-scenarios/#username--password-login) 
 or [API requests](https://www.checklyhq.com/docs/api-checks/setup-script-examples/#dismiss-password-protection-prompt-on-vercel-deployment).
 
 

diff --git a/site/content/docs/_index.md b/site/content/docs/_index.md
@@ -45,7 +45,7 @@ monitoring in minutes.
 	  title="Create a Browser check"
 	  img="/docs/images/icons/browser-checks.svg"
 	  description="Use TS / JS with @playwright/test and Headless browsers to navigate, screenshot and assert your key webapp flows."
-	  link="/docs/browser-checks"
+	  link="/docs/browser-checks/"
 >}}
 {{< doc-card
 	  class="two-column-card"
@@ -92,6 +92,6 @@ monitoring in minutes.
 <div class="cards-list">
 {{< doc-card class="three-column-card" title="Dashboards" description="Whip up a status page on your own domain or create an internal dashboard." link="/docs/dashboards" >}}
 {{< doc-card class="three-column-card" title="Private Locations" description="Run your Checks wherever you want: inside your firewall, VPC or K8S cluster. " link="/docs/private-locations" >}}
-{{< doc-card class="three-column-card" title="Groups" description="Organize your checks and D.R.Y. up your code and configuration." link="/docs/groups" >}}
+{{< doc-card class="three-column-card" title="Groups" description="Organize your checks and D.R.Y. up your code and configuration." link="/docs/groups/" >}}
 </div>
 
diff --git a/site/content/docs/accounts-and-users/adding-team-members.md b/site/content/docs/accounts-and-users/adding-team-members.md
@@ -9,7 +9,7 @@ aliases:
 ---
 
 You can invite team members to join your Checkly account to view and manage all checks and related settings.
-Team members can have different [roles](/docs/accounts-and-users).
+Team members can have different [roles](/docs/accounts-and-users/).
 
 ## Inviting team members
 

diff --git a/site/content/docs/accounts-and-users/single-sign-on.md b/site/content/docs/accounts-and-users/single-sign-on.md
@@ -10,8 +10,8 @@ menu:
 
 Single Sign-On (SSO) enables businesses to secure employee access across a variety of third-party services. Currently, Checkly supports the following SSO protocols:
 
-1. [SAML](/docs/accounts-and-users/saml)
-2. [Microsoft Azure AD](/docs/accounts-and-users/microsoft-azure-ad)
+1. [SAML](/docs/accounts-and-users/saml/)
+2. [Microsoft Azure AD](/docs/accounts-and-users/microsoft-azure-ad/)
 
 If you are interested in using Checkly with a different SSO protocol, please [reach out to Support](mailto:support@checklyhq.com).
 

diff --git a/site/content/docs/alerting-and-retries/_index.md b/site/content/docs/alerting-and-retries/_index.md
@@ -10,9 +10,9 @@ aliases:
   - /docs/alerting/
 ---
 
-Checkly will alert you when your checks [change state](/docs/alerting-and-retries/alert-states), e.g. when a passing check starts failing. To make the most out of Checkly alerts, you will want to configure them so they fit your workflow.
+Checkly will alert you when your checks [change state](/docs/alerting-and-retries/alert-states/), e.g. when a passing check starts failing. To make the most out of Checkly alerts, you will want to configure them so they fit your workflow.
 
 You can break Checkly alerting down to three main areas:
-1. [Alert settings](/docs/alerting-and-retries/alert-settings), controlling **when** and **how often** you want to be alerted when a check fails/degrades/recovers.
-2. [Alert channels](/docs/alerting-and-retries/alert-channels), determining **how** alert notifications will be sent to you.
-3. [Retries](/docs/alerting-and-retries/retries), which will help you avoid false positives by re-running failed checks.
+1. [Alert settings](/docs/alerting-and-retries/alert-settings/), controlling **when** and **how often** you want to be alerted when a check fails/degrades/recovers.
+2. [Alert channels](/docs/alerting-and-retries/alert-channels/), determining **how** alert notifications will be sent to you.
+3. [Retries](/docs/alerting-and-retries/retries/), which will help you avoid false positives by re-running failed checks.
diff --git a/site/content/docs/alerting-and-retries/alert-channels.md b/site/content/docs/alerting-and-retries/alert-channels.md
@@ -42,7 +42,7 @@ You can also select which types of alerts should be send to your channel:
 - **Recovery**: When a check recovers from either failing or being degraded.
 - [**SSL certificate expirations**](/docs/alerting/ssl-expiration/)
 
-Configuring alert channels is mostly self explanatory except for our [advanced webhook builder](/docs/alerting/webhooks).
+Configuring alert channels is mostly self explanatory except for our [advanced webhook builder](/docs/alerting/webhooks/).
 
 After adding the channels, you either **edit** or **delete** them, or change which checks are subscribed to that specific channel.
 

diff --git a/site/content/docs/api-checks/_index.md b/site/content/docs/api-checks/_index.md
@@ -16,7 +16,7 @@ API checks consist of few parts:
 **1. Name and tags**
 
 Start as you mean to go on. Pick a sensible name, something that other members of your team are going to understand. A meaningful name will not only help you and others identify your checks within Checkly, but it will help provide better a better alerting experience if your checks fall into an alert state.
-Tags can relate your checks together, they also determine which checks are shown on your public [dashboards](/docs/dashboards).
+Tags can relate your checks together, they also determine which checks are shown on your public [dashboards](/docs/dashboards/).
 ![http request](/docs/images/api-checks/overview-name-tag.png)
 
 **2. The HTTP request**
@@ -34,7 +34,7 @@ You can import a cURL command, Swagger.json or OpenAPI specification here too.
 Setup scripts allow you to do last minute processing of test data and request options. The scripts execute before any requests are made.
 Teardown scripts are run after the HTTP request has finished, but before any assertions are validated. With a maximum execution time of 10 seconds, these scripts are really useful for things like signing HMAC requests, requesting tokens, setting up or cleaning up test data and scrubbing sensitive response data for regulatory reasons.
 
-[Read more about setup and teardown scripts](setup-teardown-scripts)
+[Read more about setup and teardown scripts](setup-teardown-scripts/)
 ![setup and teardown scripts](/docs/images/api-checks/overview-scripts.png)
 
 **4. Response time limits**
@@ -56,7 +56,7 @@ You can assert on different sources. These could be:
 
 **6. Locations**
 
-You can configure your checks to run from our ever-growing amount of global [public](/docs/monitoring/global-locations) locations or use a Checkly Agent to host your own [private](/docs/private-locations/private-locations-getting-started)
+You can configure your checks to run from our ever-growing amount of global [public](/docs/monitoring/global-locations/) locations or use a Checkly Agent to host your own [private](/docs/private-locations/private-locations-getting-started/)
 If you don't select more than one data center location, we will pick a random location when retrying checks if you have "double check" enabled.
 ![locations](/docs/images/api-checks/overview-locations.png)
 
@@ -68,7 +68,7 @@ The quickest schedule you can run is every 10 seconds and the slowest is every 2
 
 **8. Alerting**
 
-Our alerting is pretty flexible. You can configure any of our [alert channels](/docs/alerting/alert-channels/#managing-alert-channels) for whichever checks you like. If we don't have your preferred alert method, why not try out our [Webhooks](/docs/alerting/webhooks)?
-> [SMS](/docs/alerting/sms-delivery/) and [Phone call](/docs/alerting/phone-calls) alerts are only available on our [Team and Enterprise plans](https://www.checklyhq.com/pricing#features) 
+Our alerting is pretty flexible. You can configure any of our [alert channels](/docs/alerting/alert-channels/#managing-alert-channels) for whichever checks you like. If we don't have your preferred alert method, why not try out our [Webhooks](/docs/alerting/webhooks/)?
+> [SMS](/docs/alerting/sms-delivery/) and [Phone call](/docs/alerting/phone-calls/) alerts are only available on our [Team and Enterprise plans](https://www.checklyhq.com/pricing#features) 
 
 ![alerting](/docs/images/api-checks/overview-alerting.png)
diff --git a/site/content/docs/api-checks/limits.md b/site/content/docs/api-checks/limits.md
@@ -21,7 +21,7 @@ You can set two thresholds:
 The benefit of using the degraded state is that it does not affect your check's success ratio like a failed state does. 
 
 You can enable alerts to be send when an API checks is degraded. This way you are notified of possible problems before things
-get out of hand. See [alerting](/docs/alerting) for more details.
+get out of hand. See [alerting](/docs/alerting/) for more details.
 
 
 > All API checks are hard capped at a timeout of **30 seconds**, this means the **"Fail at"** threshold has a maximum value of 30 seconds.

diff --git a/site/content/docs/api-checks/setup-teardown-scripts.md b/site/content/docs/api-checks/setup-teardown-scripts.md
@@ -26,7 +26,7 @@ Check the video below for a quick overview of using setup and teardown scripts t
 
 Setup scripts allow you to process test data and configure API check requests. A setup script executes before any requests 
 are made. You have access to a set of [built-in variables](#built-in-variables) to tweak the HTTP request (URL, headers etc.)
-and a set of [3rd party libraries available in each runtime](/docs/runtimes/specs). Popular use cases are signing HMAC requests, 
+and a set of [3rd party libraries available in each runtime](/docs/runtimes/specs/). Popular use cases are signing HMAC requests, 
 requesting tokens and setting up test data.
 
 Some simple examples are below:
@@ -215,7 +215,7 @@ next to the "generic" runtime variables like `process.env.CHECK_NAME` you find i
 All setup and teardown scripts run in a sandboxed environment on our cloud backend. You do not have full access to the 
 Node.js standard library or to arbitrary npm packages.
 
-Check out [our runtimes documentation](/docs/runtimes/specs) for a full specification of which modules are included.
+Check out [our runtimes documentation](/docs/runtimes/specs/) for a full specification of which modules are included.
 
 ## Technical limitations
 
@@ -245,7 +245,7 @@ Once created, just select any snippets from the drop down menu in setup and tear
 
 It's also possible to import snippets from your setup or teardown scripts. This can be valuable if setup and teardown 
 scripts are similar across checks, but still require some customization.
-Find more information in the [snippet documentation](/docs/snippets).
+Find more information in the [snippet documentation](/docs/snippets/).
 
 ### Using environment variables via Handlebars
 

diff --git a/site/content/docs/browser-checks/_index.md b/site/content/docs/browser-checks/_index.md
@@ -229,7 +229,7 @@ If your application [has very specific requirements](https://playwright.dev/docs
 Checkly enables you to use `Google Chrome` with Playwright in runtimes `2023.02` and later. 
 In order to use Google Chrome you need to explicitly opt-in by passing the `channel: 'chrome'` config.
 
-Google Chrome is not available on [Private Locations](/docs/private-locations) running on ARM64 and Apple silicon.
+Google Chrome is not available on [Private Locations](/docs/private-locations/) running on ARM64 and Apple silicon.
 
 {{< tabs "Google Chrome with Playwright test" >}}
 {{< tab "TypeScript" >}}
@@ -265,7 +265,7 @@ test('Open the page and take a screenshot', async ({ page }) => {
 - Use [Playwright Codegen](https://playwright.dev/docs/codegen) to record scripts without coding.
 - Learn more about [taking screenshots](/docs/browser-checks/screenshots/).
 - Learn more about [visual regression & snapshot testing](/docs/browser-checks/visual-regression-snapshot-testing/).
-- Run checks behind an [HTTP proxy](/docs/private-locations/proxy).
+- Run checks behind an [HTTP proxy](/docs/private-locations/proxy/).
 - Learn more about [resource limitations](/docs/runtimes/specs/#resource-limitations) for browser checks.
 
 ## More Playwright resources

diff --git a/site/content/docs/browser-checks/login-scenarios.md b/site/content/docs/browser-checks/login-scenarios.md
@@ -14,7 +14,7 @@ a great candidate for a browser check as these site transactions tend to be very
 
 
 {{<info>}}
-Using Vercel deployment protection? Read [this section](/docs/cicd/vercel-deployment-protection#vercel-authentication) on how to make this work with Checkly.
+Using Vercel deployment protection? Read [this section](/docs/cicd/vercel-deployment-protection/#vercel-authentication) on how to make this work with Checkly.
 {{</info>}}
 
 To get started, check out the video below 👇

diff --git a/site/content/docs/browser-checks/variables.md b/site/content/docs/browser-checks/variables.md
@@ -24,7 +24,7 @@ Check variables are added on the **Variables** tab for each browser check.
 
 ![add local variables](/docs/images/browser-checks/add-local-variable.png)
 
-Group variables are added on the **Variables** tab in a [group](/docs/groups). The variables stored here are accessible
+Group variables are added on the **Variables** tab in a [group](/docs/groups/). The variables stored here are accessible
 only in the group context.
 
 ![add group variables](/docs/images/browser-checks/add-group-variable.png)

diff --git a/site/content/docs/cli/constructs-reference.md b/site/content/docs/cli/constructs-reference.md
@@ -280,7 +280,7 @@ raw JavaScript / TypeScript as a string.
 Similar to Browser checks, Multistep checks uses [`@playwright/test`](https://playwright.dev/) to define the script which the check runs, but Multistep checks always need to be defined in a construct before assigning a `spec.js|ts` file.
 
 {{< info >}}
-Multistep checks are only supported on runtime 2023.09 or later. See [Runtimes](/docs/runtimes) for more details.
+Multistep checks are only supported on runtime 2023.09 or later. See [Runtimes](/docs/runtimes/) for more details.
 {{< /info >}}
 
 ```ts
@@ -538,7 +538,7 @@ const pagerdutyChannel = new PagerdutyAlertChannel('pagerduty-channel-1', {
 - `account`: The name of your Pagerduty account.
 - `serviceName`: The name of your service defined in Pagerduty under which the alerts should be nested.
 - `serviceKey`: The API key created by installing the Checkly integration in Pagerduty. We advise you to [install the
-  Pagerduty alert channel first from our UI](https://app.checklyhq.com/alerts/settings/channels/new/pagerduty) to grab
+  Pagerduty alert channel first from our UI](https://app.checklyhq.com/alerts/settings/channels/new/pagerduty/) to grab
   the `serviceKey`.
 
 [Learn more about Pagerduty alert channels](/docs/integrations/pagerduty/)
@@ -570,7 +570,7 @@ new MaintenanceWindow('maintenance-window-1', {
 - `repeatEndsAt`: The end date and time when the maintenance window should stop repeating  as an ISO 8601 timestamp
 `"YYYY-MM-DDTHH:mm:ss.sssZ"` as returned by `new Date()`
 
-[Learn more about maintenance windows in our docs](https://www.checklyhq.com/docs/maintenance-windows)
+[Learn more about maintenance windows in our docs](https://www.checklyhq.com/docs/maintenance-windows/)
 
 ## `Dashboard`
 
@@ -630,7 +630,7 @@ This is required if `customUrl` is not specified.
 - `showP95`: Show or hide the P95 stats on the dashboard. Default: `true`.
 - `showP99`: Show or hide the P99 stats on the dashboard. Default: `true`.
 
-[Learn more about dashbaords in our docs](https://www.checklyhq.com/docs/dashboards)
+[Learn more about dashbaords in our docs](https://www.checklyhq.com/docs/dashboards/)
 
 ## `PrivateLocation`
 
@@ -685,7 +685,7 @@ project or created via the Web UI, you can pass in the `slugName` string.
 - `icon`: An icon to distinguish the location in our UI. You can pick any [Octicons](https://primer.style/design/foundations/icons) name.
 - `proxyUrl`: Define a proxy for outgoing API check HTTP calls from your private location.
 
-[Learn more about private locations in our docs](https://www.checklyhq.com/docs/private-locations)
+[Learn more about private locations in our docs](https://www.checklyhq.com/docs/private-locations/)
 
 ## `RetryStrategy`
 
@@ -731,7 +731,7 @@ For all of the methods above, the `options` argument can be used to customize th
 
 `AlertEscalationPolicy` objects can be used to configure alert settings for the check runs.
 Alert escalation policies can be added to [Check](#check) and [CheckGroup](#checkgroup) constructs.
-[Learn more about alert settings](/docs/alerting-and-retries/alert-settings).
+[Learn more about alert settings](/docs/alerting-and-retries/alert-settings/).
 
 To build `AlertEscalationPolicy` objects you should use the `AlertEscalationBuilder`, which provides helper methods for configuring alert settings.
 As an example, you can configure an alert policy to notify you when a check run has failed twice consecutively, and with 2 reminders each 5 minutes apart.