Fill gaps from assistant conversations: CI setup, multistep 4xx, on-prem

detect/synthetic-monitoring/multistep-checks/troubleshooting.mdx

@@ -8,6 +8,24 @@ canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/multistep
 
 Multistep checks are a powerful tool for monitoring complex API workflows. However, they can sometimes be tricky to troubleshoot. Here are some common issues and solutions:
 
+## Expected Non-2xx Responses
+**Issue: A step expects a non-2xx response (like a 401, 403, or 404), the API returns it, but the check still fails**
+
+Playwright's `request` fixture does not throw an error on non-2xx status codes. A 403 response is a completed request. If the check fails, an assertion in your test is failing.
+
+The most common cause is `expect(response).toBeOK()`. This assertion only passes for status codes in the 200-299 range, so it fails on an expected 403.
+
+**Solution**: Assert the exact status code you expect instead of using `toBeOK()`:
+
+```typescript
+await test.step('GET /admin without permissions', async () => {
+  const response = await request.get(`${baseUrl}/admin`, { headers })
+  expect(response.status()).toBe(403)
+})
+```
+
+Check the failing assertion in the check result's error log to confirm which expectation caused the failure.
+
 ## Authentication and Authorization
 **Issue: Authentication failures or token expiration**
 

integrations/ci-cd/gitlab/overview.mdx

@@ -5,6 +5,15 @@ sidebarTitle: GitLab
 canonical: 'https://www.checklyhq.com/docs/integrations/ci-cd/gitlab/overview/'
 ---
 
+## Prerequisites
+
+Before adding the pipeline, set the required credentials as GitLab CI/CD variables. In your GitLab project, go to **Settings > CI/CD > Variables** and add:
+
+- `CHECKLY_API_KEY`: a Checkly API key, created on the [API keys tab](https://app.checklyhq.com/settings/user/api-keys) in your Checkly user settings. Mark this variable as **Masked** so it does not appear in job logs.
+- `CHECKLY_ACCOUNT_ID`: your Checkly account ID, found on the [Account settings tab](https://app.checklyhq.com/settings/account/general).
+
+The `variables` block in the pipeline example below references these CI/CD variables and exports them to the `checkly test` and `checkly deploy` commands.
+
 ## A Basic GitLab Pipeline Example
 
 Create a new `.gitlab-ci.yml` file in your repo, or add the steps and stages from the example below to your existing file.

platform/private-locations/overview.mdx

@@ -13,7 +13,7 @@ canonical: 'https://www.checklyhq.com/docs/platform/private-locations/overview/'
 **Owner** or **Admin** permissions are required to create, edit, and delete Private Locations.
 </Note>
 
-A Private Location is a monitoring location that you manage by simply deploying a lightweight Checkly Agent.
+A Private Location is a monitoring location that you manage by simply deploying a lightweight Checkly Agent. The Agent runs as a container on your own infrastructure, whether that is on-premises, in a private cloud, or inside a Kubernetes cluster. Private Locations are Checkly's option for running checks against self-hosted or internal systems that the public internet cannot reach.
 
 Running a check from a Private Location allows you to: