diff --git a/ai/rocky-ai.mdx b/ai/rocky-ai.mdx
index a6b44f62..77484126 100644
--- a/ai/rocky-ai.mdx
+++ b/ai/rocky-ai.mdx
@@ -29,7 +29,7 @@ When your invocation quota is reached, no overages are charged. Invocations refr
## Data Privacy and Security
- All AI features are designed to operate on the data you provide or the data generated by your checks. This data is already stored in Checkly, and we do not send any additional data to third-party AI providers.
-- Any provided [environment secrets](https://www.checklyhq.com/docs/api-checks/variables/) are scrubbed before being sent to the AI provider.
+- Any provided [environment secrets](/platform/variables) are scrubbed before being sent to the AI provider.
- We do not train any custom models on your data.
- Any data used by the AI features is processed in real-time and not stored for future training.
diff --git a/comparisons/frameworks/playwright-vs-cypress.mdx b/comparisons/frameworks/playwright-vs-cypress.mdx
index 7dce3a09..616e2db8 100644
--- a/comparisons/frameworks/playwright-vs-cypress.mdx
+++ b/comparisons/frameworks/playwright-vs-cypress.mdx
@@ -87,7 +87,7 @@ The architectural differences between Playwright and Cypress reflect distinct de
### **Impact of Architectural Differences**
1. **Browser and Platform Support**
- - Playwright supports all modern browsers (Chromium, Firefox, WebKit) and can run on multiple operating systems with little configuration (sidenote: Checkly currently supports using Chromium or Chrome with Playwright Test and Playwright library, with Chromium being the default browser for all checks. [Read more about using Chrome](https://www.checklyhq.com/docs/browser-checks/#using-other-browsers)).
+ - Playwright supports all modern browsers (Chromium, Firefox, WebKit) and can run on multiple operating systems with little configuration (sidenote: Checkly currently supports using Chromium or Chrome with Playwright Test and Playwright library, with Chromium being the default browser for all checks. [Read more about using Chrome](/detect/synthetic-monitoring/browser-checks/overview#using-other-browsers)).
- Cypress, with its Electron-based architecture, requires adaptation for each browser and does not support Safari or tabs.
2. **Testing Flexibility**
@@ -174,7 +174,7 @@ Further, Cypress asynchrony may not act as expected if we're used to asynchrony
### Playwright Pros
- Supports more browsers, including Firefox and Safari/WebKit
-- Suitable for complex web apps with [API](https://www.checklyhq.com/learn/playwright/testing-apis/), UI, and [visual testing](https://www.checklyhq.com/docs/browser-checks/visual-regression-snapshot-testing/) combined
+- Suitable for complex web apps with [API](https://www.checklyhq.com/learn/playwright/testing-apis/), UI, and [visual testing](/detect/synthetic-monitoring/browser-checks/visual-regressions) combined
- Superior parallelism and scalability for larger test suites
- Works on multiple platforms
diff --git a/constructs/multistep-check.mdx b/constructs/multistep-check.mdx
index cb49fe30..bb581360 100644
--- a/constructs/multistep-check.mdx
+++ b/constructs/multistep-check.mdx
@@ -15,7 +15,7 @@ Before creating Multistep Checks, ensure you have:
- An initialized Checkly CLI project
- Public endpoints you want to monitor
-- Runtime `2023.09` or later (Multistep Checks require [newer runtimes](platform/runtimes/runtime-specification))
+- Runtime `2023.09` or later (Multistep Checks require [newer runtimes](/platform/runtimes/runtime-specification))
For additional setup information, see [CLI overview](/cli/overview).
diff --git a/detect/overview.mdx b/detect/overview.mdx
index 4d358fee..99881b3c 100644
--- a/detect/overview.mdx
+++ b/detect/overview.mdx
@@ -34,7 +34,7 @@ Run automated Playwright tests to validate functionality and user workflows befo
Start with the monitoring approach that best fits your immediate needs:
- Create them inside the Checkly UI
-- Create them in your repository as [constructs](/constructs)
+- Create them in your repository as [constructs](/constructs/overview)
diff --git a/detect/synthetic-monitoring/api-checks/openapi-spec.mdx b/detect/synthetic-monitoring/api-checks/openapi-spec.mdx
index 20bbaee5..e0e0304f 100644
--- a/detect/synthetic-monitoring/api-checks/openapi-spec.mdx
+++ b/detect/synthetic-monitoring/api-checks/openapi-spec.mdx
@@ -63,7 +63,7 @@ You can assert on different sources. These could be:
- A specific response header
- A specific response time
-[Read more about assertions](assertions)
+[Read more about assertions](/detect/assertions)
### Scheduling & locations
diff --git a/detect/synthetic-monitoring/api-checks/quickstart.mdx b/detect/synthetic-monitoring/api-checks/quickstart.mdx
index faece8f8..b7a0026e 100644
--- a/detect/synthetic-monitoring/api-checks/quickstart.mdx
+++ b/detect/synthetic-monitoring/api-checks/quickstart.mdx
@@ -48,7 +48,7 @@ You can assert on different sources. These could be:
- A specific response header
- A specific response time
-[Read more about assertions](assertions)
+[Read more about assertions](/detect/assertions)
### Scheduling & locations
diff --git a/detect/synthetic-monitoring/api-checks/response-limits.mdx b/detect/synthetic-monitoring/api-checks/response-limits.mdx
index a178a79d..4c8ce64c 100644
--- a/detect/synthetic-monitoring/api-checks/response-limits.mdx
+++ b/detect/synthetic-monitoring/api-checks/response-limits.mdx
@@ -17,7 +17,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](/communicate/alerts/) for more details.
+get out of hand. See [alerting](/communicate/alerts/overview) 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/detect/synthetic-monitoring/api-checks/setup-and-teardown.mdx b/detect/synthetic-monitoring/api-checks/setup-and-teardown.mdx
index e99f421b..a35d2263 100644
--- a/detect/synthetic-monitoring/api-checks/setup-and-teardown.mdx
+++ b/detect/synthetic-monitoring/api-checks/setup-and-teardown.mdx
@@ -11,7 +11,7 @@ Setup and teardown scripts execute arbitrary JavaScript/TypeScript code before a
Both script types have access to environment variables, runtime objects like `request` and `response`, and popular npm packages
like `moment`, `axios`, and `lodash`.
-To get the most power out of API checks with setup and teardown scripts, we advise using [the Checkly CLI](/cli).
+To get the most power out of API checks with setup and teardown scripts, we advise using [the Checkly CLI](/cli/overview).
You can also use them [via the web UI](#using-setup-and-teardown-scripts-via-the-ui).
> Setup and teardown scripts have a **maximum execution time of 10 seconds** each.
diff --git a/detect/synthetic-monitoring/browser-checks/overview.mdx b/detect/synthetic-monitoring/browser-checks/overview.mdx
index 7f17bb73..652b26e4 100644
--- a/detect/synthetic-monitoring/browser-checks/overview.mdx
+++ b/detect/synthetic-monitoring/browser-checks/overview.mdx
@@ -104,7 +104,7 @@ test('User login workflow', async ({ page }) => {
-To learn more about Playwright, see the our [Playwright documentation](/learn/playwright).
+To learn more about Playwright, see the our [Playwright documentation](/learn/playwright/overview).
## Browser Check Results
diff --git a/detect/synthetic-monitoring/browser-checks/playwright-support.mdx b/detect/synthetic-monitoring/browser-checks/playwright-support.mdx
index 1315703d..456cffa5 100644
--- a/detect/synthetic-monitoring/browser-checks/playwright-support.mdx
+++ b/detect/synthetic-monitoring/browser-checks/playwright-support.mdx
@@ -149,7 +149,7 @@ the check is passing or failing. For scheduled check runs videos are only preser
## PageObject Model (POM)
-If you are structuring your test codebase following the [PageObject pattern](https://martinfowler.com/bliki/PageObject.html), you can use the [Checkly CLI](/cli) out of the box. Just make sure that:
+If you are structuring your test codebase following the [PageObject pattern](https://martinfowler.com/bliki/PageObject.html), you can use the [Checkly CLI](/cli/overview) out of the box. Just make sure that:
- the folder you initialize your CLI in when building your project sits above your test spec files and their dependencies
- your `testMatch` is pointing to the path(s) where your test specs live
diff --git a/detect/synthetic-monitoring/multistep-checks/quickstart.mdx b/detect/synthetic-monitoring/multistep-checks/quickstart.mdx
index 7bc48ed6..c0a03703 100644
--- a/detect/synthetic-monitoring/multistep-checks/quickstart.mdx
+++ b/detect/synthetic-monitoring/multistep-checks/quickstart.mdx
@@ -30,7 +30,7 @@ Together, these fields improve alert clarity and play an important role in incid
### Playwright script
-A valid Multistep check is based on a valid [Playwright API test script](https://playwright.dev/docs/api-testing). You can create these scripts either in the in-app editor, or write them in your IDE and deploy them using the [Checkly CLI](/cli/). For production, we recommend using the CLI so you can leverage best practices such as version control and code reviews before updating your checks.
+A valid Multistep check is based on a valid [Playwright API test script](https://playwright.dev/docs/api-testing). You can create these scripts either in the in-app editor, or write them in your IDE and deploy them using the [Checkly CLI](/cli/overview). For production, we recommend using the CLI so you can leverage best practices such as version control and code reviews before updating your checks.
> Valid Playwright Test API scripts are the foundation of a valid Multistep check. If the script passes, your check passes.
> If the script fails, your check fails.
@@ -75,7 +75,7 @@ You can edit and debug Playwright scripts straight from the web editor. Use the
In the sidebar, you can view:
- File dependencies
-- Your Playwright config file (if your check was created with the [Checkly CLI](/cli/))
+- Your Playwright config file (if your check was created with the [Checkly CLI](/cli/overview))
- The test report
- OpenTelemetry traces for this run (if you've enabled [Checkly Traces](/resolve/traces/overview))
- [Runtimes](/platform/runtimes/overview), including the packages in your current runtime
diff --git a/detect/synthetic-monitoring/playwright-checks/custom-dependencies.mdx b/detect/synthetic-monitoring/playwright-checks/custom-dependencies.mdx
index ee998b05..cd131a4a 100644
--- a/detect/synthetic-monitoring/playwright-checks/custom-dependencies.mdx
+++ b/detect/synthetic-monitoring/playwright-checks/custom-dependencies.mdx
@@ -4,7 +4,7 @@ description: 'Use private packages, custom registries, and additional dependenci
sidebarTitle: 'Custom Dependencies'
---
-Use the [Checkly CLI](/cli/) to turn your Playwright tests into globally distributed monitors. Checkly uses your existing `package.json` dependencies and Playwright configuration.
+Use the [Checkly CLI](/cli/overview) to turn your Playwright tests into globally distributed monitors. Checkly uses your existing `package.json` dependencies and Playwright configuration.
Playwright Check Suites do not use Checkly runtimes. Browser Checks and Multistep Checks use `runtimeId` to select a managed runtime with fixed Checkly-provided dependencies. Playwright Check Suites install your project dependencies and use `engine` to select the JavaScript engine version.
diff --git a/detect/uptime-monitoring/heartbeat-monitors/quickstart.mdx b/detect/uptime-monitoring/heartbeat-monitors/quickstart.mdx
index 66f4448c..f3298b1b 100644
--- a/detect/uptime-monitoring/heartbeat-monitors/quickstart.mdx
+++ b/detect/uptime-monitoring/heartbeat-monitors/quickstart.mdx
@@ -105,7 +105,7 @@ This means if your job is supposed to run every 6 hours but runs late at hour 7,
## Step 3: Alert Configuration
-Connect your heartbeat monitor to [alert channels](/communicate/alerts/) to be notified when pings are missing.
+Connect your heartbeat monitor to [alert channels](/communicate/alerts/overview) to be notified when pings are missing.
### Choosing Alert Channels
diff --git a/detect/uptime-monitoring/tcp-monitors/use-cases.mdx b/detect/uptime-monitoring/tcp-monitors/use-cases.mdx
index d4c439f4..bedf602e 100644
--- a/detect/uptime-monitoring/tcp-monitors/use-cases.mdx
+++ b/detect/uptime-monitoring/tcp-monitors/use-cases.mdx
@@ -376,7 +376,7 @@ Get started with step-by-step setup instructions
Explore HTTP-based monitoring for web services
-
+
Set up effective alerting for your TCP monitors
diff --git a/guides/claude-code-monitoring.mdx b/guides/claude-code-monitoring.mdx
index 622484b5..e5e2205c 100644
--- a/guides/claude-code-monitoring.mdx
+++ b/guides/claude-code-monitoring.mdx
@@ -49,7 +49,7 @@ Everything we write into the CLI interface is part of a 'prompt,' and by default
Claude Code will scan the whole project, write a summary, and then store that summary in a local `CLAUDE.md` file. Claude Code will read that file and add it to our prompt every time it's run within this project from now on.
-Let's add a bit more to this context, we want test files that make sense as a [Checkly construct](https://www.checklyhq.com/docs/cli/constructs-reference/). Let's add [Checkly's AI rules file](https://www.checklyhq.com/docs/ai//use-checkly-with-ai-ide/#claude-code) to our `CLAUDE.md` context file:
+Let's add a bit more to this context, we want test files that make sense as a [Checkly construct](/constructs/overview). Let's add [Checkly's AI rules file](/ai/overview) to our `CLAUDE.md` context file:
```bash
mkdir -p .claude &&
@@ -388,7 +388,7 @@ Throughout this tutorial, we added a few lines to the CLAUDE.md context file. In
To learn more about Checkly's capabilities, explore these resources:
- [Generating end-to-end tests with AI and Playwright MCP](https://www.checklyhq.com/blog/generate-end-to-end-tests-with-ai-and-playwright/) - Stefan's blog post makes a great starter for generalized Playwright development with an AI toolkit.
-- [Checkly CLI Documentation](https://www.checklyhq.com/docs/cli/) – Learn how to manage checks as code right from your command line.
+- [Checkly CLI Documentation](/cli/overview) – Learn how to manage checks as code right from your command line.
- [Playwright Testing Guide](https://www.checklyhq.com/learn/playwright/) – Best practices for writing reliable browser checks.
- [What is monitoring as code?](https://www.checklyhq.com/guides/monitoring-as-code/) — A comprehensive guide to infrastructure-as-code principles for monitoring.
- [Checkly Community Slack](https://checklyhq.com/slack) – Join discussions and get support from the Checkly team and other users.
diff --git a/guides/create-multiple-monitors.mdx b/guides/create-multiple-monitors.mdx
index 1dad9633..05fffeee 100644
--- a/guides/create-multiple-monitors.mdx
+++ b/guides/create-multiple-monitors.mdx
@@ -15,8 +15,8 @@ Checkly's model of [Monitoring as Code](https://www.checklyhq.com/guides/getting
### Creating a Single URL Monitor With CLI Constructs
-Checkly's Monitoring as Code workflow starts with creating a [project](https://www.checklyhq.com/docs/cli/project-structure/) where all your checks will be stored. You can use Checkly constructs to describe new Checkly monitors within your Checkly dashboard.
-If you haven't worked with Checkly at all, or have only created new monitors from our web UI, [install the Checkly CLI and create a new project for our checks with our getting started guide here](https://www.checklyhq.com/docs/cli/). A basic URL monitor with minimal configuration looks like this:
+Checkly's Monitoring as Code workflow starts with creating a [project](/constructs/overview) where all your checks will be stored. You can use Checkly constructs to describe new Checkly monitors within your Checkly dashboard.
+If you haven't worked with Checkly at all, or have only created new monitors from our web UI, [install the Checkly CLI and create a new project for our checks with our getting started guide here](/cli/overview). A basic URL monitor with minimal configuration looks like this:
```ts {title="first-url-monitor.check.ts"}
import { UrlAssertionBuilder, UrlMonitor } from 'checkly/constructs'
@@ -234,7 +234,7 @@ With these methods we could continue to extend the dynamic capabilities of this
### Manage Configuration for Multiple Monitors with Groups
-As you handle monitors for multiple sites and environments, inevitably you'll want to manage the configuration for a number of monitors all at once. Currently, by creating many monitors from a single file we're giving each one the same configuration, and any configuration not specified will take the default values in `checkly.config.ts` in the project's root directory. We can create specific groups to receive configuration by adding the monitor to a [group with Checkly constructs](https://www.checklyhq.com/docs/cli/constructs-reference/#checkgroupv2). Groups offer a convenient interface to configure your monitors, setting their retry strategy, alert thresholds, and where the group's alerts will be sent. Groups also [show up as folders in your Checkly web UI](https://www.checklyhq.com/docs/groups/); making it easier to see the status of every check in the group.
+As you handle monitors for multiple sites and environments, inevitably you'll want to manage the configuration for a number of monitors all at once. Currently, by creating many monitors from a single file we're giving each one the same configuration, and any configuration not specified will take the default values in `checkly.config.ts` in the project's root directory. We can create specific groups to receive configuration by adding the monitor to a [group with Checkly constructs](/constructs/overview#checkgroupv2). Groups offer a convenient interface to configure your monitors, setting their retry strategy, alert thresholds, and where the group's alerts will be sent. Groups also [show up as folders in your Checkly web UI](/platform/groups); making it easier to see the status of every check in the group.
@@ -287,7 +287,7 @@ This single monitor’s file is now quite a bit more compact and clean, with mor
## Conclusion: Scale Your Monitoring Effortlessly with Checkly
-Monitoring hundreds or even thousands of pages doesn’t have to be a tedious, manual process. With Checkly’s **Monitoring as Code** approach, you can dynamically create, update, and manage URL monitors at scale—whether from a local JSON file, a CSV, or even a sitemap. Remember that this approach works for more than just URL monitors, you can extend the automatic creation of monitors to [API checks](https://www.checklyhq.com/docs/api-checks/) and even [browser checks](https://www.checklyhq.com/docs/browser-checks/).
+Monitoring hundreds or even thousands of pages doesn’t have to be a tedious, manual process. With Checkly’s **Monitoring as Code** approach, you can dynamically create, update, and manage URL monitors at scale—whether from a local JSON file, a CSV, or even a sitemap. Remember that this approach works for more than just URL monitors, you can extend the automatic creation of monitors to [API checks](/detect/synthetic-monitoring/api-checks/overview) and even [browser checks](/detect/synthetic-monitoring/browser-checks/overview).
### Key Takeaways:
@@ -297,15 +297,15 @@ Monitoring hundreds or even thousands of pages doesn’t have to be a tedious, m
### Next Steps
-- **Explore Advanced Checks**: Beyond URL monitoring, Checkly supports [API checks](https://www.checklyhq.com/docs/api-checks/) with deeper validation and setup/teardown scripts, and [browser checks](https://www.checklyhq.com/docs/browser-checks/) for full user flow validation.
-- **Set Up Alerts**: Configure [alert channels](https://www.checklyhq.com/docs/alerting/) to notify your team of issues via Slack, email, or PagerDuty.
-- **Automate Deployments**: [Integrate Checkly into your CI/CD pipeline](https://www.checklyhq.com/docs/cicd/) to ensure monitoring updates with every code change.
+- **Explore Advanced Checks**: Beyond URL monitoring, Checkly supports [API checks](/detect/synthetic-monitoring/api-checks/overview) with deeper validation and setup/teardown scripts, and [browser checks](/detect/synthetic-monitoring/browser-checks/overview) for full user flow validation.
+- **Set Up Alerts**: Configure [alert channels](/communicate/alerts/overview) to notify your team of issues via Slack, email, or PagerDuty.
+- **Automate Deployments**: [Integrate Checkly into your CI/CD pipeline](/integrations/ci-cd/overview) to ensure monitoring updates with every code change.
Ready to scale your monitoring? [Sign up for Checkly](https://www.checklyhq.com/) today and deploy your first batch of monitors in minutes!
**Further Reading:**
-- [Checkly CLI Documentation](https://www.checklyhq.com/docs/cli/)
+- [Checkly CLI Documentation](/cli/overview)
- [Monitoring as Code Best Practices](https://www.checklyhq.com/guides/monitoring-as-code-best-practices/)
- [The Defense-in-Depth Approach To Application Monitoring](https://www.checklyhq.com/blog/the-defense-in-depth-approach-to-app-monitoring/)
diff --git a/guides/end-to-end-monitoring.mdx b/guides/end-to-end-monitoring.mdx
index c249c6e4..a9e8632f 100644
--- a/guides/end-to-end-monitoring.mdx
+++ b/guides/end-to-end-monitoring.mdx
@@ -166,7 +166,7 @@ As soon as a check runs red, we are alerted in real time and can **intervene bef
## CI/CD
-Tests can be kicked off of CI pipelines. You might want to use different hooks (for e.g. smoke vs regression testing) in different stages and against different targets. [Checkly supports all major CI servers](https://www.checklyhq.com/docs/cicd/).
+Tests can be kicked off of CI pipelines. You might want to use different hooks (for e.g. smoke vs regression testing) in different stages and against different targets. [Checkly supports all major CI servers](/integrations/ci-cd/overview).
## Develop-preview-test
@@ -270,7 +270,7 @@ test('Checkly Docs', async ({ page }) => {
await page.screenshot({ path: 'homepage.jpg' });
});
```
-This test uses the `page.goto` method to navigate to the specified URL (‘https://www.checklyhq.com/docs/browser-checks/’). The method returns a response object, which is stored in the response variable.
+This test uses the `page.goto` method to navigate to the specified URL (`https://www.checklyhq.com/docs/browser-checks/`). The method returns a response object, which is stored in the response variable.
Then we use the `expect` function to assert that the HTTP status code of the response is less than 400. This is a way to ensure that the page is loaded successfully without any HTTP errors.
`page.title()` retrieves the title of the page and compares it with the expected title ('Introduction to Checkly | Checkly') using the `expect` function. This ensures that the page title matches the expected value.
Finally, we take a screenshot of the page and save it as 'homepage.jpg'.
@@ -286,7 +286,7 @@ There are also links to the detailed summary of the test at the end of the resul
-As seen in the result, the test failed because if you browse the URL (https://www.checklyhq.com/docs/browser-checks/) the title of the site is “Getting started | Checkly” and not “Introduction to Checkly | Checkly” as expected in the test case.
+As seen in the result, the test failed because if you browse the URL (`https://www.checklyhq.com/docs/browser-checks/`) the title of the site is “Getting started | Checkly” and not “Introduction to Checkly | Checkly” as expected in the test case.
If we update the test case to expect “Getting started | Checkly” we will have a passed test. Here is the result of the test after updating the correct title:
diff --git a/guides/getting-started-with-monitoring-as-code.mdx b/guides/getting-started-with-monitoring-as-code.mdx
index 6c83d35a..9523709d 100644
--- a/guides/getting-started-with-monitoring-as-code.mdx
+++ b/guides/getting-started-with-monitoring-as-code.mdx
@@ -110,7 +110,7 @@ There are also links to the detailed summary of the test at the end of the resul
-As seen in the result, the test failed because if you browse the URL (https://www.checklyhq.com/docs/browser-checks/) the title of the site is “Getting started | Checkly” and not “Introduction to Checkly | Checkly” as expected in the test case.
+As seen in the result, the test failed because if you browse the URL (`https://www.checklyhq.com/docs/browser-checks/`) the title of the site is “Getting started | Checkly” and not “Introduction to Checkly | Checkly” as expected in the test case.
If we update the test case to expect “Getting started | Checkly” we will have a passed test. Here is the result of the test after updating the correct title:
@@ -152,13 +152,13 @@ As you just saw, with Checkly’s CLI, you can run your checks directly from you
Here’s how to integrate your checks and the Checkly CLI if you’re already using one of the popular CI/CD platforms:
-- [**GitHub Actions**](https://www.checklyhq.com/docs/cicd/github-actions/): Run the Checkly CLI from GitHub Actions, export summary reports, and integrate with monorepos for streamlined monitoring across multiple projects.
-- [**GitLab CI**](https://www.checklyhq.com/docs/cicd/gitlabci/): Use GitLab CI pipelines to run the Checkly CLI, setting up separate jobs for E2E testing and deployment.
-- [**Jenkins**](https://www.checklyhq.com/docs/cicd/jenkins/): Integrate the Checkly CLI into a Jenkins pipeline using a Jenkinsfile to automate your monitoring checks and deployments.
+- [**GitHub Actions**](/integrations/ci-cd/github/actions): Run the Checkly CLI from GitHub Actions, export summary reports, and integrate with monorepos for streamlined monitoring across multiple projects.
+- [**GitLab CI**](/integrations/ci-cd/gitlab/overview): Use GitLab CI pipelines to run the Checkly CLI, setting up separate jobs for E2E testing and deployment.
+- [**Jenkins**](/integrations/ci-cd/jenkins/overview): Integrate the Checkly CLI into a Jenkins pipeline using a Jenkinsfile to automate your monitoring checks and deployments.
### CI/CD Integration Using Vendor Webhooks
-For platforms like [Vercel](https://www.checklyhq.com/docs/cicd/vercel/) or [GitHub deployments](https://www.checklyhq.com/docs/cicd/github/), you can trigger your Checkly checks using vendor-specific webhooks. This method provides a streamlined way to initiate monitoring as part of your deployment process without needing a fully-fledged CI/CD pipeline.
+For platforms like [Vercel](/integrations/ci-cd/vercel/overview) or [GitHub deployments](/integrations/ci-cd/github/deployments), you can trigger your Checkly checks using vendor-specific webhooks. This method provides a streamlined way to initiate monitoring as part of your deployment process without needing a fully-fledged CI/CD pipeline.
By integrating Checkly’s monitoring checks into your CI/CD pipeline, you ensure that your application is thoroughly validated before and after deployment, reducing the risk of issues in production and maintaining a high level of reliability.
diff --git a/guides/keyword-monitoring.mdx b/guides/keyword-monitoring.mdx
index ed01371f..19d5a043 100644
--- a/guides/keyword-monitoring.mdx
+++ b/guides/keyword-monitoring.mdx
@@ -77,7 +77,7 @@ The final settings on frequency and locations will look like this:
Next I’ll make a few settings about how we want to retry our checks.
- A fleeting failure isn’t a big issue to me. If a single page load didn’t have the best seller for some reason, that’s fine as long as it’s there when you check again a minute later, so I’ll set the retry time to ‘linear,’ retrying 2 more times with a minute between them
-- Finally I’ll use the global notification settings, and get notified via email, slack, SMS and a via a webhook to [Rootly](https://www.checklyhq.com/docs/integrations/rootly/)
+- Finally I’ll use the global notification settings, and get notified via email, slack, SMS and a via a webhook to [Rootly](/integrations/incident-management/rootly)
diff --git a/guides/monitoring-ecommerce-apps-using-playwright.mdx b/guides/monitoring-ecommerce-apps-using-playwright.mdx
index b4365271..c42b3b71 100644
--- a/guides/monitoring-ecommerce-apps-using-playwright.mdx
+++ b/guides/monitoring-ecommerce-apps-using-playwright.mdx
@@ -45,7 +45,7 @@ Users who have already used Checkly will be familiar with creating Checks, Check
1. [The Checkly CLI.](https://www.checklyhq.com/cli/overview)
2. [Terraform (through our Terraform provider)](/integrations/iac/terraform/overview)
-3. [Pulumi (through our Pulumi provider)](https://www.checklyhq.com/docs/integrations/pulumi/)
+3. [Pulumi (through our Pulumi provider)](/integrations/iac/pulumi/overview)
## Monitoring an e-commerce website - as code
diff --git a/guides/monitoring-the-stripe-api.mdx b/guides/monitoring-the-stripe-api.mdx
index c4191ccc..594bb97e 100644
--- a/guides/monitoring-the-stripe-api.mdx
+++ b/guides/monitoring-the-stripe-api.mdx
@@ -309,7 +309,7 @@ API monitoring checks must be organised as to minimise the time needed to identi
## Scheduled global API checks
-Checkly specialises in API monitoring and allows users to run API checks on a schedule from [global locations](https://www.checklyhq.com/docs/monitoring/global-locations/). We can combine these checks with [custom alerting](https://www.checklyhq.com/docs/alerting/) to be able to quickly respond and remediate potential API issues.
+Checkly specialises in API monitoring and allows users to run API checks on a schedule from [global locations](/concepts/locations). We can combine these checks with [custom alerting](/communicate/alerts/overview) to be able to quickly respond and remediate potential API issues.
@@ -359,7 +359,7 @@ Teardown scripts run after the request has executed, bur right before the assert
As we increase our monitoring coverage across our APIs, we can also increase the efficacy of our setup by:
-1. Importing existing [Swagger/OpenAPI specs](https://www.checklyhq.com/docs/api-checks/request-settings/#import-a-swagger--openapi-specification) or even [cURL commands](https://www.checklyhq.com/docs/api-checks/request-settings/#import-a-curl-request) using built-in functionality.
+1. Importing existing [Swagger/OpenAPI specs](/detect/synthetic-monitoring/api-checks/configuration#import-a-swagger--openapi-specification) or even [cURL commands](/detect/synthetic-monitoring/api-checks/configuration#import-a-curl-request) using built-in functionality.
2. [Defining our API checks as code](/guides/getting-started-with-monitoring-as-code) to scale our setup while lowering maintenance needs.
3. Combining our API checks with [E2E monitoring](/guides/end-to-end-monitoring/) for any website or web app service whose API we might be monitoring.
diff --git a/guides/moving-from-puppeteer-to-playwright.mdx b/guides/moving-from-puppeteer-to-playwright.mdx
index cf686a53..ea96dbde 100644
--- a/guides/moving-from-puppeteer-to-playwright.mdx
+++ b/guides/moving-from-puppeteer-to-playwright.mdx
@@ -291,7 +291,7 @@ You can use the [Playwright Test Generator](https://playwright.dev/docs/codegen)
## Switching to Playwright for richer browser check results
-Checkly users switching to Playwright can take advantage of its new Rich Browser Check Results, which come with [tracing and Web Vitals](https://www.checklyhq.com/docs/browser-checks/tracing-web-vitals/) and make it easier to isolate the root cause of a failed check and remediate faster.
+Checkly users switching to Playwright can take advantage of its new Rich Browser Check Results, which come with [tracing and Web Vitals](/detect/synthetic-monitoring/browser-checks/performance-metrics) and make it easier to isolate the root cause of a failed check and remediate faster.
@@ -301,9 +301,9 @@ This reveals additional information about the check execution, including:
3. For each page visited, a network & timing timeline, Web Vitals, console and network tabs.
4. In case of a failing check, a screenshot on failure.
-> Aside from running a Playwright script, performance and error tracing also require the use of [Runtime](https://www.checklyhq.com/docs/runtimes/) `2021.06` or newer.
+> Aside from running a Playwright script, performance and error tracing also require the use of [Runtime](/platform/runtimes/overview) `2021.06` or newer.
-> Note that cross-browser support is not available on Checkly - [our Browser checks run on Chromium](https://www.checklyhq.com/docs/browser-checks/) only.
+> Note that cross-browser support is not available on Checkly - [our Browser checks run on Chromium](/detect/synthetic-monitoring/browser-checks/overview) only.
## Read More
diff --git a/guides/playwright-testing-to-monitoring.mdx b/guides/playwright-testing-to-monitoring.mdx
index 0b4028c3..77a21fd7 100644
--- a/guides/playwright-testing-to-monitoring.mdx
+++ b/guides/playwright-testing-to-monitoring.mdx
@@ -76,7 +76,7 @@ Run a Playwright test every hour or every minute from locations all across the g
1. **Global Test Execution**: Run your Playwright scripts from multiple geographic locations to ensure your application performs well for users worldwide.
2. **Monitoring Cadence**: Run tests every minute or every hour, and set a monitoring cadence that defends your SLA.
3. **Alerting and Notifications**: Set up alerts via email, Slack, PagerDuty, or other channels to notify your team of failures.
-4. **Connect Backend Traces**: With Checkly Traces, harness the power of OpenTelemetry to [see backend traces connected to each testing session.](https://www.checklyhq.com/docs/traces-open-telemetry/)
+4. **Connect Backend Traces**: With Checkly Traces, harness the power of OpenTelemetry to [see backend traces connected to each testing session.](/resolve/traces/overview)
5. **Code Workflow Integration**: Manage your monitoring scripts as code, enabling version control, collaboration, and CI/CD integration.
diff --git a/guides/sdlc-monitoring.mdx b/guides/sdlc-monitoring.mdx
index 9f804b16..79941fc7 100644
--- a/guides/sdlc-monitoring.mdx
+++ b/guides/sdlc-monitoring.mdx
@@ -225,7 +225,7 @@ Once you’ve set up your private location, pick your private location when crea
### Checkly Traces for OpenTelemetry insights
-At any layer of running tests against your services, it’s helpful to connect the information from synthetic testing with backend trace data. With [Checkly Traces](https://www.checklyhq.com/docs/traces-open-telemetry/), it’s possible to export backend data captured with [OpenTelemetry](https://www.checklyhq.com/learn/opentelemetry/getting-started-with-observability/) and gather trace data from your backend services as they’re handling the requests sent during a Checkly Test.
+At any layer of running tests against your services, it’s helpful to connect the information from synthetic testing with backend trace data. With [Checkly Traces](/resolve/traces/overview), it’s possible to export backend data captured with [OpenTelemetry](https://www.checklyhq.com/learn/opentelemetry/getting-started-with-observability/) and gather trace data from your backend services as they’re handling the requests sent during a Checkly Test.
Implementation is straightforward and results in a highly efficient observability setup that doesn’t use bandwidth for
unnecessary monitoring data. In most cases the setup will look like this:
@@ -238,7 +238,7 @@ unnecessary monitoring data. In most cases the setup will look like this:
*With Checkly Traces you can see the database calls and other timespans as your backend services handle requests kicked off by a Checkly test.*
-Checkly Traces is easy to implement even if you aren’t currently using OpenTelemetry, [check out our documentation](https://www.checklyhq.com/docs/traces-open-telemetry/) on how to get started.
+Checkly Traces is easy to implement even if you aren’t currently using OpenTelemetry, [check out our documentation](/resolve/traces/overview) on how to get started.
## 3. Production - Finding failures in real time with Playwright & Checkly
@@ -248,13 +248,13 @@ Once you’ve moved to production, it’s time to run your tests on a cadence, c
1. [Determine the right check frequency](https://www.checklyhq.com/blog/check-frequency/) based on SLA
2. Configure your tests either in the web UI or by editing your [test repository’s config](/constructs/project) file
-3. [Group or tag tests](https://www.checklyhq.com/docs/groups/#organizing-checks-with-groups---checkly-docs) by criticality to have consistent cadence for high value services - this also makes it easier to see checks together in the web UI
+3. [Group or tag tests](/platform/groups) by criticality to have consistent cadence for high value services - this also makes it easier to see checks together in the web UI
With alerts running on a cadence, you can ensure that you’re hearing about failures before your users report them. The final step is setting up the alerting your team receives when a monitor detects problems.
### Alerting on failures
-Finally, now that we’re monitoring production with Checkly, we’ll need to send alerts to an on-call team and/or key stakeholders when something is detected as not working. [Checkly supports multiple alert channels](https://www.checklyhq.com/docs/alerting-and-retries/#alerting-and-retries-with-checkly---checkly-docs), with configuration available either for a single check, at the group level, or all checks. Some best practices:
+Finally, now that we’re monitoring production with Checkly, we’ll need to send alerts to an on-call team and/or key stakeholders when something is detected as not working. [Checkly supports multiple alert channels](/communicate/alerts/overview), with configuration available either for a single check, at the group level, or all checks. Some best practices:
- Configure retry logic for minimal alert fatigue - Checkly offers fine-grained retries on checks, and it’s important to double-check that failures aren’t transitory. Balance alert fatigue with time efficiency, as multiple retries can significantly impact time to detection.
- Don’t rely on a single alert channel, always have at least one backup like a slack message or email to make sure that a delivery failure doesn't aggravate an outage.
diff --git a/guides/startup-guide-detect-communicate-resolve.mdx b/guides/startup-guide-detect-communicate-resolve.mdx
index 5b125450..5d6eb930 100644
--- a/guides/startup-guide-detect-communicate-resolve.mdx
+++ b/guides/startup-guide-detect-communicate-resolve.mdx
@@ -84,7 +84,7 @@ With a project set up, we can start writing our first monitors. Monitors come in
### Adding Uptime Monitoring for Every Endpoint
-All monitors are created as `.check.ts` files implementing the [Checkly CLI construct](https://www.checklyhq.com/docs/cli/using-constructs/). Here’s an example URL Monitor:
+All monitors are created as `.check.ts` files implementing the [Checkly CLI construct](/constructs/overview). Here’s an example URL Monitor:
```ts
import { UrlAssertionBuilder, UrlMonitor } from 'checkly/constructs' // Import required constructs from Checkly CLI
@@ -108,7 +108,7 @@ new UrlMonitor('url-monitor-example', { // Create new URL monitor with unique lo
To create a new URL monitor, add a new file like `url-monitor.check.ts` in the `__checks__/` directory. Import `UrlMonitor` and `UrlAssertionBuilder` from `checkly/constructs`, then instantiate a new monitor with a unique logical ID, name, and request configuration. The monitor will send GET requests to your specified URL and validate HTTP status codes with `UrlAssertionBuilder.statusCode().equals(200)` to ensure the endpoint returns successful responses.
-URL monitors have limited assertion features, they’re primarily there to guarantee uptime with a broad reach. Uptime monitoring also includes low level checks like [TCP monitors](https://www.checklyhq.com/docs/tcp-monitors/), and [Heartbeat monitors](https://www.checklyhq.com/docs/heartbeat-monitors/) which listen for pings from your automated tasks. For deeper synthetics monitoring of your endpoints, to test and monitor correctness of responses in depth, reach for synthetics checks like API checks. Thankfully, the constructs signature is very similar:
+URL monitors have limited assertion features, they’re primarily there to guarantee uptime with a broad reach. Uptime monitoring also includes low level checks like [TCP monitors](/detect/uptime-monitoring/tcp-monitors/overview), and [Heartbeat monitors](/detect/uptime-monitoring/heartbeat-monitors/overview) which listen for pings from your automated tasks. For deeper synthetics monitoring of your endpoints, to test and monitor correctness of responses in depth, reach for synthetics checks like API checks. Thankfully, the constructs signature is very similar:
```ts
import { ApiCheck, AssertionBuilder } from 'checkly/constructs'
@@ -156,10 +156,10 @@ new ApiCheck('books-api-advanced-check', {
})
```
-All of these assertions are available in the `AssertionBuilder` [section of the constructs API](https://www.checklyhq.com/docs/cli/constructs-reference/#assertionbuilder). You can go even further with API checks: from running scripts before each check to evaluating JSON responses. These advanced options are [covered in detail in our documentation site](https://www.checklyhq.com/docs/cli/constructs-reference/#apicheck). With Checkly CLI constructs you can create and configure every type of monitor, and feed it any variation of configuration. Some extensions of API checks include:
+All of these assertions are available in the `AssertionBuilder` [section of the constructs API](/constructs/overview#assertionbuilder). You can go even further with API checks: from running scripts before each check to evaluating JSON responses. These advanced options are [covered in detail in our documentation site](/constructs/overview#apicheck). With Checkly CLI constructs you can create and configure every type of monitor, and feed it any variation of configuration. Some extensions of API checks include:
-- Using [variables and secrets](https://www.checklyhq.com/docs/api-checks/variables/) to configure checks at runtime. Environment variables can be scoped to your whole account, or specific to a group of checks.
-- Execute arbitrary code (e.g. to fetch and assign session tokens), and clean up after yourself (e.g. to remove any new records created as part of the check), with [setup and teardown scripts for API checks](https://www.checklyhq.com/docs/api-checks/setup-teardown-scripts/).
+- Using [variables and secrets](/platform/variables) to configure checks at runtime. Environment variables can be scoped to your whole account, or specific to a group of checks.
+- Execute arbitrary code (e.g. to fetch and assign session tokens), and clean up after yourself (e.g. to remove any new records created as part of the check), with [setup and teardown scripts for API checks](/detect/synthetic-monitoring/api-checks/setup-and-teardown).
### Create and Manage Multiple Monitors at Once
@@ -199,7 +199,7 @@ urlsToMonitor.forEach((url, index) => {
*This example shows the power of constructs for creating monitors. However, real world implementations would probably query a list of URLs from an endpoint rather than having the array of URLs hard-coded.*
-> Notice that the check above isn’t configured with a `maxResponseTime` , `alertChannels` , and several other settings. Without these settings the project defaults in `checkly.config.ts` will be used. We could also assign checks to a group to manage a subset of checks with one configuration. [More detail on groups is covered in the Checkly documentation](https://www.checklyhq.com/docs/groups/). There’s more detail on alert thresholds and how alerts are communicated in part 2, below.
+> Notice that the check above isn’t configured with a `maxResponseTime` , `alertChannels` , and several other settings. Without these settings the project defaults in `checkly.config.ts` will be used. We could also assign checks to a group to manage a subset of checks with one configuration. [More detail on groups is covered in the Checkly documentation](/platform/groups). There’s more detail on alert thresholds and how alerts are communicated in part 2, below.
We can test this file (and the others added above) with the `npx checkly test` command, which will scan the `/__checks__` directory and run all of our checks through the Checkly monitoring network.
@@ -255,7 +255,7 @@ A Chromium browser and a new "Playwright inspector" window should appear. As you
*`codegen` captures your inputs and lets you add assertions, the process is [fully documented on our documentation site](https://www.checklyhq.com/learn/playwright/codegen/).*
-Once you’re happy with the scripted test, copy the code into a `.spec.ts` file, and create a construct for your check as a `.check.ts` file, based on the CLI [constructs; this time for browser checks](https://www.checklyhq.com/docs/cli/constructs-reference/#browsercheck). Here’s an example of a check for the demo site [Danube Web Shop](https://danube-web.shop/):
+Once you’re happy with the scripted test, copy the code into a `.spec.ts` file, and create a construct for your check as a `.check.ts` file, based on the CLI [constructs; this time for browser checks](/constructs/overview#browsercheck). Here’s an example of a check for the demo site [Danube Web Shop](https://danube-web.shop/):
```ts {title="homepage-browse.check.ts"}
import { AlertEscalationBuilder, BrowserCheck, RetryStrategyBuilder } from 'checkly/constructs'
@@ -363,7 +363,7 @@ alertSettings: {
}
```
-These settings just like all the settings in this section can be managed at the individual check level, [as a group](https://www.checklyhq.com/docs/groups/), or across the whole project in the `checkly.config.ts` file.
+These settings just like all the settings in this section can be managed at the individual check level, [as a group](/platform/groups), or across the whole project in the `checkly.config.ts` file.
### Manage alert channels
@@ -419,9 +419,9 @@ new UrlMonitor('url-monitor-example', {
})
```
-Integrating alerting with incident management tools ensures seamless communication during outages. For example, connecting Checkly with [PagerDuty](https://www.checklyhq.com/docs/cli/constructs-reference/#pagerdutyalertchannel) can [automatically open incidents](https://www.checklyhq.com/docs/integrations/pagerduty/), while Slack alerts keep the team informed in real time. Of course you can also [send alerts out to a webhook](https://www.checklyhq.com/docs/cli/constructs-reference/#webhookalertchannel) to connect with your DIY alerting solution. By combining proactive alerting with smart retry logic, you create a robust monitoring system that keeps your DevOps or SRE team focused on resolving critical issues.
+Integrating alerting with incident management tools ensures seamless communication during outages. For example, connecting Checkly with [PagerDuty](/constructs/overview#pagerdutyalertchannel) can [automatically open incidents](/integrations/incident-management/pagerduty), while Slack alerts keep the team informed in real time. Of course you can also [send alerts out to a webhook](/constructs/overview#webhookalertchannel) to connect with your DIY alerting solution. By combining proactive alerting with smart retry logic, you create a robust monitoring system that keeps your DevOps or SRE team focused on resolving critical issues.
-For communicating directly with your users, teams should [explore status pages](https://www.checklyhq.com/docs/status-pages/) to automatically communicate downtime or degraded performance.
+For communicating directly with your users, teams should [explore status pages](/communicate/status-pages/overview) to automatically communicate downtime or degraded performance.
## Part 3. Resolve Issues Faster with Checkly Dashboards
@@ -442,7 +442,7 @@ For browser checks, Checkly provides [detailed traces and execution logs](https:
*When your browser check fails, Checkly stores a Playwright trace to offer in-depth, moment-by-moment reviews of what the browser saw as it tried to load the page.*
-If you're interested in adding back-end tracing information, explore Checkly Traces to send back-end OpenTelemetry trace data to Checkly for requests initiated by Checkly synthetic requests. [See the whole process on our documentation site](https://www.checklyhq.com/docs/traces-open-telemetry/).
+If you're interested in adding back-end tracing information, explore Checkly Traces to send back-end OpenTelemetry trace data to Checkly for requests initiated by Checkly synthetic requests. [See the whole process on our documentation site](/resolve/traces/overview).
*A failed browser check. With Checkly Traces we also get backend trace information from services like Redis and our Postgres database*
@@ -457,7 +457,7 @@ Checkly’s monitoring tools—from simple uptime checks to complex Playwright-b
**Communicate Clearly During Outages**
-With customizable alerting policies and multiple notification channels (Slack, PagerDuty, SMS, and more), your team stays informed the moment an issue arises. Well-tuned alerting reduces noise while ensuring critical failures get immediate attention. Teams can use [status pages](https://www.checklyhq.com/docs/status-pages/) to communicate directly with their users.
+With customizable alerting policies and multiple notification channels (Slack, PagerDuty, SMS, and more), your team stays informed the moment an issue arises. Well-tuned alerting reduces noise while ensuring critical failures get immediate attention. Teams can use [status pages](/communicate/status-pages/overview) to communicate directly with their users.
**Resolve Issues Faster with Deep Insights**
@@ -466,8 +466,8 @@ All checks offer high-level views of the status of your monitors, which can show
### Further Reading
- [Learn: Playwright](https://www.checklyhq.com/learn/playwright/) - Go deep on the best web automation framework.
-- [Use Checkly With an AI IDE](https://www.checklyhq.com/docs/ai/use-checkly-with-ai-ide/) - For writing your monitoring faster and more consistently.
-- [Environment Variables](https://www.checklyhq.com/docs/cli/using-environment-variables/) - To configure checks at runtime.
+- [Use Checkly With an AI IDE](/ai/overview) - For writing your monitoring faster and more consistently.
+- [Environment Variables](/cli/environment-variables) - To configure checks at runtime.
- [Use Setup Scripts for Better API Monitoring](https://www.checklyhq.com/guides/setup-scripts-for-apis/) - Advanced techniques for keeping monitoring code DRY.
- [Monitoring as Code with Terraform & Pulumi](https://www.checklyhq.com/docs/cli/cli-vs-terraform-pulumi/) - The Checkly CLI isn't the only way to do Monitoring as Code.
diff --git a/integrations/ci-cd/overview.mdx b/integrations/ci-cd/overview.mdx
index 549a0f8c..c2c6be19 100644
--- a/integrations/ci-cd/overview.mdx
+++ b/integrations/ci-cd/overview.mdx
@@ -18,7 +18,7 @@ With this approach, you can validate your application and infrastructure before
Simultaneously , you can life cycle (create/update/delete) your checks from your code base as part of your CI/CD workflow.
## CI/CD Integration with the Checkly CLI
-The preferred and most flexible way to integrate Checkly with your CI/CD is through the [Checkly CLI](/cli).
+The preferred and most flexible way to integrate Checkly with your CI/CD is through the [Checkly CLI](/cli/overview).
@@ -28,7 +28,7 @@ The preferred and most flexible way to integrate Checkly with your CI/CD is thro
- [GitHub deployments](/integrations/ci-cd/github/deployments)
## CI/CD Basics
-We've optimized the [Checkly CLI](/cli) to work in any CI/CD workflow. Here are the basics you need to know that
+We've optimized the [Checkly CLI](/cli/overview) to work in any CI/CD workflow. Here are the basics you need to know that
will come in handy when adapting the examples we give you to your own, specific setup.
1. For **authentication**, make sure to set the `CHECKLY_API_KEY` and `CHECKLY_ACCOUNT_ID` parameters as environment variables
diff --git a/integrations/iac/terraform/alerting.mdx b/integrations/iac/terraform/alerting.mdx
index 394aea23..33eca8b2 100644
--- a/integrations/iac/terraform/alerting.mdx
+++ b/integrations/iac/terraform/alerting.mdx
@@ -8,7 +8,7 @@ Alerting is organised around alert settings and alert channels.
## Alert settings
-[Alert settings](https://www.checklyhq.com/docs/alerting/) determine _when_ and how many times alerts should be sent out. You can set the alert settings at check level:
+[Alert settings](/communicate/alerts/overview) determine _when_ and how many times alerts should be sent out. You can set the alert settings at check level:
```terraform
resource "checkly_check" "get-books" {
@@ -88,7 +88,7 @@ resource "checkly_check_group" "key-shop-flows" {
## Alert channels
-[Alert channels](https://www.checklyhq.com/docs/alerting/alert-channels/) determine _how_ (as in "to which alert systems") alerts are sent out. They can be created as standalone resources:
+[Alert channels](/communicate/alerts/overview) determine _how_ (as in "to which alert systems") alerts are sent out. They can be created as standalone resources:
```terraform
resource "checkly_alert_channel" "email_ac" {
diff --git a/integrations/iac/terraform/overview.mdx b/integrations/iac/terraform/overview.mdx
index c938e3d9..fd4e6caa 100644
--- a/integrations/iac/terraform/overview.mdx
+++ b/integrations/iac/terraform/overview.mdx
@@ -9,7 +9,7 @@ The [Checkly Terraform provider](https://github.com/checkly/terraform-provider-c
If you prefer, you can also clone our [sample repository](https://github.com/checkly/checkly-terraform-getting-started) and play around with the resources on your own.
For in-depth information on Terraform, please see HashiCorp's [official documentation](https://developer.hashicorp.com/terraform/docs).
-> Looking for Monitoring as Code but don't want to use Terraform? Give our [CLI solution](/cli/) a try.
+> Looking for Monitoring as Code but don't want to use Terraform? Give our [CLI solution](/cli/overview) a try.
## Installation
diff --git a/learn/incidents/anatomy-of-a-status-page.mdx b/learn/incidents/anatomy-of-a-status-page.mdx
index 270d6d16..853c432b 100644
--- a/learn/incidents/anatomy-of-a-status-page.mdx
+++ b/learn/incidents/anatomy-of-a-status-page.mdx
@@ -56,7 +56,7 @@ The basic technical requirements (fast loading pages, manual edits permitted, et
**3. Clear infographics** - a status page should be able to take complex historical data and turn it into a clear history for the viewer. Some kind of graphing library should represent high level status data visually.
-**4. Incidents should be organized into services** - for Checkly’s Status Pages, all alerts are [classified ahead of time into services](https://www.checklyhq.com/docs/status-pages/#services). We don’t want to present our product as a monolith, nor should we print inscrutable internal labels. With this organization, we can present sections on a single status page, or multiple separate status pages with groupings of services.
+**4. Incidents should be organized into services** - for Checkly’s Status Pages, all alerts are [classified ahead of time into services](/communicate/status-pages/overview#services). We don’t want to present our product as a monolith, nor should we print inscrutable internal labels. With this organization, we can present sections on a single status page, or multiple separate status pages with groupings of services.
**5. Subscription service** - Users should subscribe to only the pages they care about.
@@ -64,4 +64,4 @@ The basic technical requirements (fast loading pages, manual edits permitted, et
In short, a good status page keeps users informed and builds trust. It must be clear, reliable, and easy to use. Users want quick updates, simple labels, and the ability to subscribe. On the tech side, it needs automated monitoring, independent hosting, and clear visuals. By meeting these needs, your status page will help users stay updated and reduce frustration.
-**Further reading:** [A guide to Checkly’s Status Pages](https://www.checklyhq.com/docs/status-pages/)
\ No newline at end of file
+**Further reading:** [A guide to Checkly’s Status Pages](/communicate/status-pages/overview)
\ No newline at end of file
diff --git a/learn/incidents/defining-mttr.mdx b/learn/incidents/defining-mttr.mdx
index f83be444..a1416af8 100644
--- a/learn/incidents/defining-mttr.mdx
+++ b/learn/incidents/defining-mttr.mdx
@@ -63,7 +63,7 @@ On the level of an individual conversation that can seem like a simple miscommun
### Disagreements in measuring MTTR
-The above example is a disagreement about what MTTR is measuring, with one person going by how long a service was unavailable based on backend logging, the other basing off the status page, but there are even more cases where it’s hard to agree on a value. What about geographically specific failures? If a service is unavailable in Germany only, does that [geographic-specific outage](https://www.checklyhq.com/docs/monitoring/global-locations/) count as downtime? What if one feature isn’t working for a week, but other users never notice the issue because they never use that feature? Both these questions ask ‘Does MTTR measure the whole system or just parts?’ and every organization will have its own answer to this question.
+The above example is a disagreement about what MTTR is measuring, with one person going by how long a service was unavailable based on backend logging, the other basing off the status page, but there are even more cases where it’s hard to agree on a value. What about geographically specific failures? If a service is unavailable in Germany only, does that [geographic-specific outage](/concepts/locations) count as downtime? What if one feature isn’t working for a week, but other users never notice the issue because they never use that feature? Both these questions ask ‘Does MTTR measure the whole system or just parts?’ and every organization will have its own answer to this question.
To refer back to Goodhart’s Law mentioned in the above section, a confounding issue is the use of a general statistic to measure performance and (often) punish failure. When good engineers are facing penalties for missing SLA or hurting MTTR, they can often become very stingy with what counts as downtime.
diff --git a/learn/incidents/detection-best-practices.mdx b/learn/incidents/detection-best-practices.mdx
index 663de2f7..0e071a87 100644
--- a/learn/incidents/detection-best-practices.mdx
+++ b/learn/incidents/detection-best-practices.mdx
@@ -35,7 +35,7 @@ Avoid "alert fatigue" by ensuring alerts are meaningful and actionable:
Your application may depend on APIs, CDNs, or cloud providers—any of which can fail.
-- **Check External Endpoints**: Regularly test third-party services. With [Checkly’s API monitors](https://www.checklyhq.com/docs/api-checks/), you can send frequent quick checks to external API’s you rely on, and get reliable notifications if something isn’t working, before users report a problem.
+- **Check External Endpoints**: Regularly test third-party services. With [Checkly’s API monitors](/detect/synthetic-monitoring/api-checks/overview), you can send frequent quick checks to external API’s you rely on, and get reliable notifications if something isn’t working, before users report a problem.
- **Implement Fallbacks**: Gracefully degrade functionality if a dependency fails. For core dependencies this might go as far as switching to a backup payment provider if your primary service fails.
@@ -54,7 +54,7 @@ Proactively simulate outages to ensure your monitoring works:
Downtime may only affect certain regions due to DNS, CDN, or cloud provider issues.
- **Distributed Monitoring**: Deploy checks across multiple geographic locations.
-- **Monitor DNS & CDN Health**: Use tools like Checkly to [detect regional outages](https://www.checklyhq.com/docs/monitoring/global-locations/).
+- **Monitor DNS & CDN Health**: Use tools like Checkly to [detect regional outages](/concepts/locations).
---
diff --git a/learn/incidents/incident-communication.mdx b/learn/incidents/incident-communication.mdx
index 530591ea..4ae92ee1 100644
--- a/learn/incidents/incident-communication.mdx
+++ b/learn/incidents/incident-communication.mdx
@@ -30,14 +30,14 @@ With the answers to these, you should be able to give general guidance to your t
During total outages, where some or all users are totally unable to use your service, no amount of delay in notifying affected users will feel acceptable to those users. Users expect that the second your service goes down, the login box on your page will be replaced with a ‘technical difficulties, please stand by’ message.
-While users always have high expectations, this one does feel reasonable: after all shouldn’t it be trivial to detect that a service is completely down, then list that on a [status page](https://www.checklyhq.com/docs/status-pages/) automatically? On the other hand, we don’t want to tell users not to log in when the service is working fine. So while it’s best to automate status messages, we require a robust tool to detect these outages.
+While users always have high expectations, this one does feel reasonable: after all shouldn’t it be trivial to detect that a service is completely down, then list that on a [status page](/communicate/status-pages/overview) automatically? On the other hand, we don’t want to tell users not to log in when the service is working fine. So while it’s best to automate status messages, we require a robust tool to detect these outages.
You should, wherever possible, have an automated system that shows the availability of your service. Such an automated communication tool should do the following:
- Regularly make requests of your key services
- Implement retry logic, checking again if any request fails
- Make requests from a broad geographic area, not relying on a single network route or availability zone
-- Output the results of these checks to a publicly available [status page](https://www.checklyhq.com/docs/status-pages/)
+- Output the results of these checks to a publicly available [status page](/communicate/status-pages/overview)
Of course, not every outage can result in automated communication. As an example: if a datastore starts returning gibberish records for all users, the service is likely to look healthy to most automated monitors (we’ll note that a sophisticated Playwright check could identify functional problems like this one, but still). As such, it is critical that even with a high quality detection and status communication system, your on-call team still needs the ability to communicate with users, preferably in the same channel as the status automation. This also adds a fallback if the automated system isn’t working during an outage.
diff --git a/learn/incidents/modern-root-cause-analysis.mdx b/learn/incidents/modern-root-cause-analysis.mdx
index 02deb06b..c116df9b 100644
--- a/learn/incidents/modern-root-cause-analysis.mdx
+++ b/learn/incidents/modern-root-cause-analysis.mdx
@@ -71,4 +71,4 @@ Instead of guessing, you get:
Tools like OpenTelemetry, Checkly, and Jaeger turn chaos into clarity. The result? Less downtime, happier users, and fewer late-night fire drills.
-*Want to improve your RCA? Start by connecting your [OpenTelemetry tracing to Checkly](https://www.checklyhq.com/docs/traces-open-telemetry/)—before the next outage hits.*
\ No newline at end of file
+*Want to improve your RCA? Start by connecting your [OpenTelemetry tracing to Checkly](/resolve/traces/overview)—before the next outage hits.*
\ No newline at end of file
diff --git a/learn/incidents/reduce-mttd.mdx b/learn/incidents/reduce-mttd.mdx
index d54c9c39..9cfc7f9c 100644
--- a/learn/incidents/reduce-mttd.mdx
+++ b/learn/incidents/reduce-mttd.mdx
@@ -46,7 +46,7 @@ Automated tools like [Checkly](https://www.checklyhq.com/) can make sure that ev
Many of the points listed in this article will revolve around making sure that an alert is emitted as soon as the service isn’t working for some users. But when analyzing slow incident response, there’s another way that our outage detection can fail: alert fatigue. While alert fatigue sounds like a quality of life issue, generating too many alerts can essentially disable your outage detection. If recent incident post-mortems have identified that 1) the recent outage did trigger an alert, but 2) that alert was one of dozens emitted every day, it’s likely that no one is reading those alerts at all. Over-alerting isn’t much better than generating no alerts at all. To control alert fatigue, here are some suggestions in brief:
- Take alert fatigue seriously — false positives (alerts when there was no problem) should trigger investigations and fixes just like false negatives (undetected outages).
-- Set retry policies — requests sometimes fail via the internet. Set a reasonable [retry policy](https://www.checklyhq.com/docs/alerting-and-retries/) on your checks so you’re not generating false alarms.
+- Set retry policies — requests sometimes fail via the internet. Set a reasonable [retry policy](/communicate/alerts/overview) on your checks so you’re not generating false alarms.
- Use smart tests — using the [auto-waiting](https://www.checklyhq.com/learn/playwright/waits-and-timeouts/) and intelligent user-centric assertions of Playwright will help ensure your tests aren’t too strict and therefore flaky (generating lots of false positives).
- Route alerts intelligently — use a tool like Rootly or Pagerduty to make sure only the right people are getting alerts.
@@ -70,7 +70,7 @@ In the early days of ‘synthetic user monitoring’ the synthetic user was a he
Beyond parsing pages and following links, a true automated browser is necessary to monitor if our services are online. Further we want to have complex [assertions](https://www.checklyhq.com/learn/playwright/assertions/) available to ask the same questions that our users do. For example, when our user visits our ecommerce site, and searches for products, they expect to get more than one result, and they expect each item will have an ‘add to cart’ button. Users care about these things more than they do exact response times or JavaScript errors, so it’s these complex user paths that should be tested when monitoring our service.
-A tool like [Playwright](https://www.checklyhq.com/docs/browser-checks/playwright-test/) is the best way to really act like a user when interacting with our service. Checkly uses Playwright to let engineers test every aspect of their service with the same expectations their users bring.
+A tool like [Playwright](/detect/synthetic-monitoring/browser-checks/playwright-support) is the best way to really act like a user when interacting with our service. Checkly uses Playwright to let engineers test every aspect of their service with the same expectations their users bring.
## Gather real evidence of failure
diff --git a/learn/incidents/slo-sla-sli.mdx b/learn/incidents/slo-sla-sli.mdx
index 3ef09df6..dc10347e 100644
--- a/learn/incidents/slo-sla-sli.mdx
+++ b/learn/incidents/slo-sla-sli.mdx
@@ -185,7 +185,7 @@ Checkly’s API checks can help you achieve your SLAs through:
### **Browser Checks**
-On the other hand, Checkly’s Playwright-based [browser checks](https://www.checklyhq.com/docs/browser-checks/) mimic user actions to make sure key processes work smoothly, and the heartbeat feature checks if systems are running properly. These capabilities enable the monitoring of response times, uptime, functionality, and internal systems performance. This comprehensive monitoring supports SLAs in keeping services healthy and running efficiently.
+On the other hand, Checkly’s Playwright-based [browser checks](/detect/synthetic-monitoring/browser-checks/overview) mimic user actions to make sure key processes work smoothly, and the heartbeat feature checks if systems are running properly. These capabilities enable the monitoring of response times, uptime, functionality, and internal systems performance. This comprehensive monitoring supports SLAs in keeping services healthy and running efficiently.
@@ -199,7 +199,7 @@ Checkly’s browser checks can help you achieve your SLAs through:
- **Customizable Check Intervals:** You can configure the frequency of your browser checks to match the criticality of different application components. For example, you might run checks on key user flows every few minutes to ensure high availability and performance, aligning with stringent SLA requirements.
- **Reporting and Insights:** Checkly provides comprehensive reports and dashboards that offer insights into the historical performance and reliability of your web application. These insights can be used to demonstrate compliance with SLAs during stakeholder reviews and to identify areas for improvement.
-*To find out more about Checkly’s browser checks & how to get started, check out [this article](https://www.checklyhq.com/docs/browser-checks/).*
+*To find out more about Checkly’s browser checks & how to get started, check out [this article](/detect/synthetic-monitoring/browser-checks/overview).*
### **Checkly Best Practices**
diff --git a/learn/incidents/what-is-incident-response.mdx b/learn/incidents/what-is-incident-response.mdx
index 9b5c9490..2f8fdbd5 100644
--- a/learn/incidents/what-is-incident-response.mdx
+++ b/learn/incidents/what-is-incident-response.mdx
@@ -49,7 +49,7 @@ Each of the stages of incident response has associated best practices:
2. **Classify the Incident and Determine its Scope**: Once the issue is identified, it is recorded in a system. The team then decides how serious it is and who should handle it. On small teams this will generally be a choice between a level 2 incident handled by the on-call engineer and Support/Sales to handle customer communication; and a level 1 incident handled by pretty much everybody.
3. **Communicate with Users**: Whether it’s through a manual update process, a social media update, or an automated status page, once the incident has been classified and the scope determined it’s time to talk to your users (some teams may choose to be more targeted if the failure only affects a small subset of users).
4. **Remediate the Failure**: In some cases it may be possible to remediate the problem before fully diagnosing the cause. For example, a user-reported bug that is easy to reproduce, that starts being reported one hour after a major code deployment, can likely be remediated with a rollback. This can be done before understanding exactly why the recent deployment caused this error.
-5. **Diagnose the Incident**: The team investigates to find the root cause of the problem. Depending on how well our remediation steps worked, root cause analysis may wait until after the incident, or be held off until working hours the next morning. However, if effective remediation isn't available (for example if a simple restart hasn't fixed things), you may be trying to diagnose root causes under time pressure. Key tools include [Checkly Traces](https://www.checklyhq.com/docs/traces-open-telemetry/) to connect [OpenTelemetry traces](https://www.checklyhq.com/learn/opentelemetry/traces/) with synthetics data.
+5. **Diagnose the Incident**: The team investigates to find the root cause of the problem. Depending on how well our remediation steps worked, root cause analysis may wait until after the incident, or be held off until working hours the next morning. However, if effective remediation isn't available (for example if a simple restart hasn't fixed things), you may be trying to diagnose root causes under time pressure. Key tools include [Checkly Traces](/resolve/traces/overview) to connect [OpenTelemetry traces](https://www.checklyhq.com/learn/opentelemetry/traces/) with synthetics data.
6. **Repair the Issue**: Once the root cause is known, the team fixes the issue. This could mean adding more resources, fixing a network problem, or applying a permanent solution.
7. **Close and Review the Incident**: After the problem is solved, the team closes the incident and reviews what happened. This helps them learn from the issue and improve for the future.
diff --git a/learn/monitoring/api-monitoring.mdx b/learn/monitoring/api-monitoring.mdx
index 4a4f1eec..e1e373c3 100644
--- a/learn/monitoring/api-monitoring.mdx
+++ b/learn/monitoring/api-monitoring.mdx
@@ -68,15 +68,15 @@ Another compelling reason for 24/7 monitoring is that there are multiple points
Now that we have established what API monitoring is and why businesses should adopt it as part of their development process, here are some tips to get started.
-The first step is to identify which APIs are currently being employed by your system, including both internal APIs as well as external third party APIs. Understanding the exact role they play in the development of your application is crucial to knowing which metrics need to be monitored and tested. Important metrics such as [API response time](https://www.checklyhq.com/docs/api-checks/limits/), availability, and data correctness are a few that you will be interested in keeping an eye on.
+The first step is to identify which APIs are currently being employed by your system, including both internal APIs as well as external third party APIs. Understanding the exact role they play in the development of your application is crucial to knowing which metrics need to be monitored and tested. Important metrics such as [API response time](/detect/synthetic-monitoring/api-checks/response-limits), availability, and data correctness are a few that you will be interested in keeping an eye on.
-Requests are sent to the API, whose responses are evaluated in terms of speed, availability, and correctness. In case the response received does not meet the standards laid out for it, the [API check](https://www.checklyhq.com/docs/api-checks/) registers an error. It is common for monitors to send a second request to that API in the event of a failure. If the API is unreachable or its response is once again inadequate, an alert is triggered, and pre-defined developers and API-providers are informed about the situation.
+Requests are sent to the API, whose responses are evaluated in terms of speed, availability, and correctness. In case the response received does not meet the standards laid out for it, the [API check](/detect/synthetic-monitoring/api-checks/overview) registers an error. It is common for monitors to send a second request to that API in the event of a failure. If the API is unreachable or its response is once again inadequate, an alert is triggered, and pre-defined developers and API-providers are informed about the situation.
-The next step is to choose an API monitoring tool that will best support your needs. A good monitoring tool will [run checks](https://www.checklyhq.com/docs/monitoring/) across all your APIs frequently and be able to check for various metrics across criteria such as performance and correctness. With [Checkly](https://app.checklyhq.com/signup?utm_medium=blog&utm_source=organic&utm_term=get-started-section) you can establish a high frequency of checks, which allows you to observe the status of the target system with greater granularity. For example, a critical API endpoint could be monitored every ten seconds to ensure that any issues are caught immediately rather than waiting on a slower monitoring frequency. Additionally, Checkly enables you to monitor APIs from over 20 locations to ensure that they operate smoothly globally.
+The next step is to choose an API monitoring tool that will best support your needs. A good monitoring tool will [run checks](/detect/synthetic-monitoring/overview) across all your APIs frequently and be able to check for various metrics across criteria such as performance and correctness. With [Checkly](https://app.checklyhq.com/signup?utm_medium=blog&utm_source=organic&utm_term=get-started-section) you can establish a high frequency of checks, which allows you to observe the status of the target system with greater granularity. For example, a critical API endpoint could be monitored every ten seconds to ensure that any issues are caught immediately rather than waiting on a slower monitoring frequency. Additionally, Checkly enables you to monitor APIs from over 20 locations to ensure that they operate smoothly globally.
Checkly’s [API monitoring tool](https://www.checklyhq.com/product/api-monitoring/) is an optimal solution for companies keen to develop and integrate an effective API monitoring flow into their existing development and maintenance processes.
-Checkly enables you to streamline the API monitoring process. You can start by creating or importing HTTP requests for the endpoints you want to monitor, then specify assertions against the response (and response time). There are ample opportunities to customize [setup and teardown](https://www.checklyhq.com/docs/api-checks/setup-teardown-scripts/) [using scripts](/guides/setup-scripts-for-apis) to fetch OAuth tokens or help clean test data. Checkly has data centers in twenty locations worldwide, from which it can run API checks up to every ten seconds. This is crucial to get a comprehensive and accurate picture of the health of your APIs. Finally, depending on your workflow, [Checkly also integrates with services such as Slack](/communicate/alerts/channels), email, and Pagerduty to notify and alert you of any incidents.
+Checkly enables you to streamline the API monitoring process. You can start by creating or importing HTTP requests for the endpoints you want to monitor, then specify assertions against the response (and response time). There are ample opportunities to customize [setup and teardown](/detect/synthetic-monitoring/api-checks/setup-and-teardown) [using scripts](/guides/setup-scripts-for-apis) to fetch OAuth tokens or help clean test data. Checkly has data centers in twenty locations worldwide, from which it can run API checks up to every ten seconds. This is crucial to get a comprehensive and accurate picture of the health of your APIs. Finally, depending on your workflow, [Checkly also integrates with services such as Slack](/communicate/alerts/channels), email, and Pagerduty to notify and alert you of any incidents.
## API Monitoring as Code
@@ -100,7 +100,7 @@ By default, you have access to a free Team trial which expires after 14 days, so
### Step 2: Create a New Check
-Once you've signed up and logged in, you can proceed to a [Browser Check](https://www.checklyhq.com/docs/browser-checks/), API Check or use the CLI script.
+Once you've signed up and logged in, you can proceed to a [Browser Check](/detect/synthetic-monitoring/browser-checks/overview), API Check or use the CLI script.
Let’s play around with the API Check. On your dashboard, click the "API Check" tab (you can toggle between tabs). You should see an interface like this:
@@ -241,7 +241,7 @@ We recommend choosing [short monitoring intervals for critical endpoints](https:
### Q: How can businesses ensure the correctness of API responses?
When API responses change, this change often only appears when relying applications break. This results in a broken user experience. API monitoring prevents this from happening. A well-defined API monitoring solution enables developers to monitor API uptime but also API correctness and accuracy.
-[API check assertions](https://www.checklyhq.com/docs/api-checks/assertions/) allow you to define what API responses you expect from your API endpoints. Check assertions range from testing essential HTTP response headers to well-formed and correct JSON responses.
+[API check assertions](/detect/synthetic-monitoring/api-checks/configuration) allow you to define what API responses you expect from your API endpoints. Check assertions range from testing essential HTTP response headers to well-formed and correct JSON responses.
You know your API best and should be as specific as possible to avoid user-facing production issues.
@@ -271,4 +271,4 @@ False alarms are a common problem in any active API monitoring solution because
A suitable retry solution is a balance between timely and valid alerts. How often do you want to retry until you get alerted? And how quickly do you want to retry an API call? And in what interval should your API be pinged again?
-The answers to these questions vary depending on the API and the urgency of downtime. A more extended retry period might be sufficient for some APIs, whereas, for others, a quick and single retry is the best approach. No matter your preference, your monitoring solution must provide [configurable retry strategies](https://www.checklyhq.com/docs/alerting-and-retries/#how-often-should-i-retry).
+The answers to these questions vary depending on the API and the urgency of downtime. A more extended retry period might be sufficient for some APIs, whereas, for others, a quick and single retry is the best approach. No matter your preference, your monitoring solution must provide [configurable retry strategies](/communicate/alerts/overview#how-often-should-i-retry).
diff --git a/learn/monitoring/frontend-monitoring.mdx b/learn/monitoring/frontend-monitoring.mdx
index 40fa992a..9a64fcfa 100644
--- a/learn/monitoring/frontend-monitoring.mdx
+++ b/learn/monitoring/frontend-monitoring.mdx
@@ -60,7 +60,7 @@ However this approach has several challenges:
**Synthetic Monitoring**
-[Synthetic monitoring](https://www.checklyhq.com/blog/what-is-synthetic-monitoring/) can be as simple as sending requests to a service and making sure the response has a `200 OK` status code, but the term is generally used to describe an automated browser that can simulate user behavior. [Checkly uses the open source Playwright framework](https://www.checklyhq.com/docs/browser-checks/playwright-test/) to simulate user behavior in great detail, and make complex assertions about the results.
+[Synthetic monitoring](https://www.checklyhq.com/blog/what-is-synthetic-monitoring/) can be as simple as sending requests to a service and making sure the response has a `200 OK` status code, but the term is generally used to describe an automated browser that can simulate user behavior. [Checkly uses the open source Playwright framework](/detect/synthetic-monitoring/browser-checks/playwright-support) to simulate user behavior in great detail, and make complex assertions about the results.
Synthetic monitoring solves many of the problems listed above with RUM:
@@ -102,7 +102,7 @@ Key metrics in detail:
- **Core Web Vitals**: [Largest Contentful Paint](https://web.dev/articles/lcp) (LCP), [Interaction to Next Pain](https://web.dev/articles/inp) (INP), Cumulative Layout Shift (CLS). These metrics are considered to be quite critical for search engine optimization.
- **JavaScript Error Rates**: Frequency of client-side code failures. You may need to implement filtering for common errors.
-- **API Response Times**: Speed and reliability of API calls. This may be called ‘[heartbeat monitoring](https://www.checklyhq.com/docs/heartbeat-monitors/#heartbeat-monitoring---checkly-docs)’ if you’re only measuring the reliability of straightforward `get` requests.
+- **API Response Times**: Speed and reliability of API calls. This may be called ‘[heartbeat monitoring](/detect/uptime-monitoring/heartbeat-monitors/overview)’ if you’re only measuring the reliability of straightforward `get` requests.
- **Network Request Failures**: Broken or delayed network requests
- **Errors and Crashes**: Stability of the application under different conditions
- **User Interactions and Engagement**: Clicks, scrolls, and session durations
@@ -111,7 +111,7 @@ Key metrics in detail:
## Common Use Cases of Frontend Monitoring
-- **Monitoring Page Load Times**: [Ensure optimal page rendering speed](https://www.checklyhq.com/docs/browser-checks/tracing-web-vitals/#total-blocking-time).
+- **Monitoring Page Load Times**: [Ensure optimal page rendering speed](/detect/synthetic-monitoring/browser-checks/performance-metrics#total-blocking-time).
- **Tracking Third-Party Services**: No amount of pre-deploy testing with stubs of third party services can find all the possible interaction problems with those services. Frontend monitoring can detect issues caused by external libraries or APIs.
- **User Interaction Monitoring**: Analyze behavior patterns and engagement levels.
- **Analyzing Client-Side Errors**: Identify and resolve JavaScript issues, especially those happening on single platforms or with particular browser versions.
@@ -126,7 +126,7 @@ Frontend monitoring empowers teams to detect potential problems before they esca
**Precise Performance Insights**
-[Performance monitoring](https://www.checklyhq.com/docs/browser-checks/tracing-web-vitals/) provides actionable data that highlights bottlenecks and inefficiencies in applications. Metrics such as Largest Contentful Paint or Interaction to Next Paint help developers understand where delays occur and prioritize optimization efforts. These insights shift the focus from merely reacting to known issues toward analyzing anomalies, such as unexpectedly fast or slow responses. This phase aligns with "known unknowns," where developers explore statistical questions to assess how normal or abnormal system behavior is.
+[Performance monitoring](/detect/synthetic-monitoring/browser-checks/performance-metrics) provides actionable data that highlights bottlenecks and inefficiencies in applications. Metrics such as Largest Contentful Paint or Interaction to Next Paint help developers understand where delays occur and prioritize optimization efforts. These insights shift the focus from merely reacting to known issues toward analyzing anomalies, such as unexpectedly fast or slow responses. This phase aligns with "known unknowns," where developers explore statistical questions to assess how normal or abnormal system behavior is.
**Real-Time User Experience Analysis**
@@ -158,13 +158,13 @@ Entry-level monitoring tools often focus on surface-level insights, such as erro
**Ensuring Full-Stack Visibility**
-Frontend monitoring alone cannot provide a complete view of an application’s health. Many issues arise at the intersection of the frontend and backend, requiring integrated observability across the entire stack. Without this integration, teams risk spending excessive time proving whether an issue is frontend- or backend-related. Implementing [context propagation](https://www.checklyhq.com/learn/opentelemetry/context-propagation/) and unified tracing, such as through OpenTelemetry, helps connect frontend events to backend processes, enabling a more holistic understanding of system behavior and streamlining troubleshooting efforts. For more detail on connecting backend [OpenTelemetry traces](https://www.checklyhq.com/learn/opentelemetry/traces/) with frontend performance see how [Checkly Traces connects data from across your stack](https://www.checklyhq.com/docs/traces-open-telemetry/how-it-works/).
+Frontend monitoring alone cannot provide a complete view of an application’s health. Many issues arise at the intersection of the frontend and backend, requiring integrated observability across the entire stack. Without this integration, teams risk spending excessive time proving whether an issue is frontend- or backend-related. Implementing [context propagation](https://www.checklyhq.com/learn/opentelemetry/context-propagation/) and unified tracing, such as through OpenTelemetry, helps connect frontend events to backend processes, enabling a more holistic understanding of system behavior and streamlining troubleshooting efforts. For more detail on connecting backend [OpenTelemetry traces](https://www.checklyhq.com/learn/opentelemetry/traces/) with frontend performance see how [Checkly Traces connects data from across your stack](/resolve/traces/how-it-works).
## Top frontend monitoring tools
| Tool | Features | Notes |
| --- | --- | --- |
-| **Checkly** | Uses Playwright [end-to-end tests for synthetic monitoring](https://www.checklyhq.com/docs/monitoring/). Robust alerts to detect issues early. Integrates with OpenTelemetry traces. | Excellent for proactive monitoring and integration with backend systems. |
+| **Checkly** | Uses Playwright [end-to-end tests for synthetic monitoring](/detect/synthetic-monitoring/overview). Robust alerts to detect issues early. Integrates with OpenTelemetry traces. | Excellent for proactive monitoring and integration with backend systems. |
| **Sematext** | Backend monitoring with [an open-source data collection agent](https://github.com/sematext/sematext-agent-java). | Suitable for teams needing a lightweight, open-source-friendly solution. |
| **Pingdom** | Specializes in uptime monitoring and performance tracking. | Focused on simple up-or-down monitoring. Limited in scope compared to other tools. |
| **Google PageSpeed Insights** | Provides performance recommendations based on real-world data. | Primarily an auditing tool, best for reactive monitoring. |
diff --git a/learn/monitoring/metrics-every-team-needs.mdx b/learn/monitoring/metrics-every-team-needs.mdx
index cb00756b..96a59462 100644
--- a/learn/monitoring/metrics-every-team-needs.mdx
+++ b/learn/monitoring/metrics-every-team-needs.mdx
@@ -153,4 +153,4 @@ Part of starting small is considering the most basic questions first: with Check
- Set up [dashboards for these four metrics](http://localhost:3000/learn/opentelemetry/what-is-the-otel-collector/).
- Define your [alert thresholds](https://www.checklyhq.com/docs/communicate/alerts/configuration).
- Define your [playbooks for incident response](http://localhost:3000/learn/incidents/playbooks/).
-- [Add Checkly](https://www.checklyhq.com/docs/browser-checks/) to find out about outages before your users do
\ No newline at end of file
+- [Add Checkly](/detect/synthetic-monitoring/browser-checks/overview) to find out about outages before your users do
\ No newline at end of file
diff --git a/learn/monitoring/monitoring-as-code.mdx b/learn/monitoring/monitoring-as-code.mdx
index e053813f..d5106446 100644
--- a/learn/monitoring/monitoring-as-code.mdx
+++ b/learn/monitoring/monitoring-as-code.mdx
@@ -242,7 +242,7 @@ Your monitoring aligns with your application logic, offering precise, actionable
### **Alert Management via Code**
-A strong alerting strategy ensures critical issues are addressed promptly while minimizing noise for your team. With Checkly, you can configure alerting integrations like [PagerDuty](https://www.checklyhq.com/docs/integrations/pagerduty/) or [OpsGenie](https://www.checklyhq.com/docs/integrations/opsgenie/) directly in your codebase. This approach allows you to:
+A strong alerting strategy ensures critical issues are addressed promptly while minimizing noise for your team. With Checkly, you can configure alerting integrations like [PagerDuty](/integrations/incident-management/pagerduty) or [OpsGenie](/integrations/incident-management/opsgenie) directly in your codebase. This approach allows you to:
- Define alert thresholds, escalation paths, and severity levels as part of your monitoring setup.
- Automatically deploy and update alerting configurations alongside your application changes.
@@ -250,7 +250,7 @@ A strong alerting strategy ensures critical issues are addressed promptly while
### **Status pages and dashboards**
-[Status pages](/communicate/status-pages/overview) and [internal dashboards](/communicate/dashboards/overview) offer a real-time view of your application's health, and MaC enables you to configure these visualizations programmatically. Tools like [Grafana](https://www.checklyhq.com/docs/analytics/#building-a-grafana-dashboard) integrate easily with MaC, allowing you to:
+[Status pages](/communicate/status-pages/overview) and [internal dashboards](/communicate/dashboards/overview) offer a real-time view of your application's health, and MaC enables you to configure these visualizations programmatically. Tools like [Grafana](/platform/reporting/analytics-api#building-a-grafana-dashboard) integrate easily with MaC, allowing you to:
- Automate the creation and updates of dashboards and status pages based on predefined templates.
- Highlight key metrics like latency, error rates, or resource utilization, making it easier to identify trends and anomalies.
diff --git a/learn/monitoring/transaction-monitoring.mdx b/learn/monitoring/transaction-monitoring.mdx
index 43e2b842..bc783dad 100644
--- a/learn/monitoring/transaction-monitoring.mdx
+++ b/learn/monitoring/transaction-monitoring.mdx
@@ -53,7 +53,7 @@ Effective synthetic transaction monitoring relies on several core components:
**Synthetic Transaction Engine**
-The synthetic transaction engine executes predefined scripts, mimicking user interactions. It must handle complex workflows involving multiple steps, conditional logic, and diverse input data. At Checkly, this is a system of ‘[Checkly runners](https://www.checklyhq.com/docs/monitoring/)’ that execute checks against your service at your selected cadence and geographic regions.
+The synthetic transaction engine executes predefined scripts, mimicking user interactions. It must handle complex workflows involving multiple steps, conditional logic, and diverse input data. At Checkly, this is a system of ‘[Checkly runners](/detect/synthetic-monitoring/overview)’ that execute checks against your service at your selected cadence and geographic regions.
**Scripting Language**
@@ -61,7 +61,7 @@ A flexible scripting language allows testers to define transactions. Languages l
**Test Execution Scheduler**
-The scheduler automates the execution of scripts at specified intervals. This ensures continuous monitoring and provides insights into performance trends over time. At Checkly this is controlled either [via the web UI](https://www.checklyhq.com/docs/testing/) or via our [Monitoring as Code](https://www.checklyhq.com/guides/monitoring-as-code/#) process.
+The scheduler automates the execution of scripts at specified intervals. This ensures continuous monitoring and provides insights into performance trends over time. At Checkly this is controlled either [via the web UI](/detect/testing/overview) or via our [Monitoring as Code](https://www.checklyhq.com/guides/monitoring-as-code/#) process.
**Test Results Analyzer**
@@ -73,7 +73,7 @@ An alerting system notifies teams when performance thresholds are breached. Aler
**Integration with Other Tools**
-Synthetic transaction monitoring tools often integrate with observability platforms, incident management systems, and CI/CD pipelines, enabling streamlined workflows and comprehensive insights. At Checkly, the results of synthetics checks can integrate with your OpenTelemetry data via [Checkly Traces](https://www.checklyhq.com/docs/traces-open-telemetry/how-it-works/#understand-checkly-traces-and-opentelemetry---checkly-docs).
+Synthetic transaction monitoring tools often integrate with observability platforms, incident management systems, and CI/CD pipelines, enabling streamlined workflows and comprehensive insights. At Checkly, the results of synthetics checks can integrate with your OpenTelemetry data via [Checkly Traces](/resolve/traces/how-it-works).
## Synthetic Transaction Monitoring Use Cases with Examples
@@ -87,7 +87,7 @@ A SaaS company tests its public APIs by simulating client requests. This ensures
A video streaming service tests its platform from multiple regions to ensure video playback performance meets user expectations globally.
5. **Visual Regression Monitoring**
- A System for monitoring every pixel of a frontend experience. Generally visual regression monitoring is both more brittle and less user-centric than some of the examples mentioned above. After all, your users aren’t logging in to your site expecting certain typefaces or exact color shades. These things do matter, however, so [with Playwright you can monitor for visual regressions](https://www.checklyhq.com/docs/browser-checks/visual-regression-snapshot-testing/#visual-regression--snapshot-testing---checkly-docs) as an advanced test type.
+ A System for monitoring every pixel of a frontend experience. Generally visual regression monitoring is both more brittle and less user-centric than some of the examples mentioned above. After all, your users aren’t logging in to your site expecting certain typefaces or exact color shades. These things do matter, however, so [with Playwright you can monitor for visual regressions](/detect/synthetic-monitoring/browser-checks/visual-regressions) as an advanced test type.
Synthetic transaction monitoring is an essential tool for organizations aiming to ensure optimal performance and reliability of their digital services. By proactively addressing issues and gaining insights into user workflows, businesses can deliver superior experiences to their customers.
@@ -130,14 +130,14 @@ Although synthetic monitoring provides simulated data, it cannot replace actual
**Core Problem Analysis**
-When [retries are set up correctly](https://www.checklyhq.com/docs/alerting-and-retries/), we should only get a synthetic transaction monitoring alert when there’s a real problem that users will notice. But detecting an issue through synthetic monitoring is only the first step. Pinpointing the root cause of problems requires additional diagnostic tools and processes. Synthetic monitoring should be run as a separate service from all of your internal services and tools, and as such will lack insight into how your back end is handling requests. Once you’ve detected a problem, backend logs, traces, and other information from something like an [OpenTelemetry monitoring system](https://www.checklyhq.com/learn/opentelemetry/getting-started-with-observability/), will be needed to find a root cause.
+When [retries are set up correctly](/communicate/alerts/overview), we should only get a synthetic transaction monitoring alert when there’s a real problem that users will notice. But detecting an issue through synthetic monitoring is only the first step. Pinpointing the root cause of problems requires additional diagnostic tools and processes. Synthetic monitoring should be run as a separate service from all of your internal services and tools, and as such will lack insight into how your back end is handling requests. Once you’ve detected a problem, backend logs, traces, and other information from something like an [OpenTelemetry monitoring system](https://www.checklyhq.com/learn/opentelemetry/getting-started-with-observability/), will be needed to find a root cause.
*Checkly Traces can connect synthetic site checks with the related traces observed by your [OpenTelemetry monitoring](https://www.checklyhq.com/learn/opentelemetry/).*
**Tool Integration Needs**
-Integrating synthetic monitoring tools with existing systems can pose challenges, especially if the ecosystem includes multiple platforms and technologies. Seamless integration is crucial for accurate monitoring and efficient workflows, but it often requires customization and ongoing maintenance. As ‘table stakes’ your synthetic transaction monitoring tool should make its results available on a shared dashboqard, and route alerts intelligently either natively or through integration with tools like [Rootly](https://www.checklyhq.com/docs/integrations/rootly/) and [Pagerduty](https://www.checklyhq.com/docs/integrations/pagerduty/#send-alerts-to-pagerduty-with-checkly---checkly-docs). Ideally your synthetic monitoring could automatically connect back end tracing that was started by a synthetics request. With [Checkly Traces](https://www.checklyhq.com/docs/traces-open-telemetry/how-it-works/#understand-checkly-traces-and-opentelemetry---checkly-docs), you can do just that: integrate back end traces with synthetic transaction monitoring, adding insight into the root cause of errors.
+Integrating synthetic monitoring tools with existing systems can pose challenges, especially if the ecosystem includes multiple platforms and technologies. Seamless integration is crucial for accurate monitoring and efficient workflows, but it often requires customization and ongoing maintenance. As ‘table stakes’ your synthetic transaction monitoring tool should make its results available on a shared dashboqard, and route alerts intelligently either natively or through integration with tools like [Rootly](/integrations/incident-management/rootly) and [Pagerduty](/integrations/incident-management/pagerduty). Ideally your synthetic monitoring could automatically connect back end tracing that was started by a synthetics request. With [Checkly Traces](/resolve/traces/how-it-works), you can do just that: integrate back end traces with synthetic transaction monitoring, adding insight into the root cause of errors.
By understanding these benefits and challenges, organizations can better implement synthetic transaction monitoring as part of a balanced observability strategy.
diff --git a/learn/monitoring/web-application-monitoring.mdx b/learn/monitoring/web-application-monitoring.mdx
index a570eabd..e07bf961 100644
--- a/learn/monitoring/web-application-monitoring.mdx
+++ b/learn/monitoring/web-application-monitoring.mdx
@@ -109,7 +109,7 @@ Often, poor performance doesn’t happen all at once. For every user who gets in
* Dynamic Content
-Monitoring tools may struggle with rapidly changing, personalized content. A robust testing framework like [Playwright](https://www.checklyhq.com/docs/browser-checks/playwright-test/) can be helpful for writing smarter assertions about how interfaces *should* look.
+Monitoring tools may struggle with rapidly changing, personalized content. A robust testing framework like [Playwright](/detect/synthetic-monitoring/browser-checks/playwright-support) can be helpful for writing smarter assertions about how interfaces *should* look.
* Cross-purposes
@@ -324,7 +324,7 @@ Open source monitoring is not just a viable alternative to proprietary solutions
## How Can Checkly Help with Web Application Monitoring
-[Checkly](https://www.checklyhq.com/) offers an integrated platform for synthetic monitoring and API testing, ensuring applications are functional and performant. For simulating user requests to perform synthetic monitoring, Checkly harnesses the power of the open source automation tool Playwright. With [Checkly and Playwright](https://www.checklyhq.com/docs/browser-checks/playwright-test/), there’s no user behavior that you can’t test, and no critical path you can’t monitor continually.
+[Checkly](https://www.checklyhq.com/) offers an integrated platform for synthetic monitoring and API testing, ensuring applications are functional and performant. For simulating user requests to perform synthetic monitoring, Checkly harnesses the power of the open source automation tool Playwright. With [Checkly and Playwright](/detect/synthetic-monitoring/browser-checks/playwright-support), there’s no user behavior that you can’t test, and no critical path you can’t monitor continually.
## Conclusion
diff --git a/learn/opentelemetry/how-to-instrument.mdx b/learn/opentelemetry/how-to-instrument.mdx
index 86917a34..2bddfdfc 100644
--- a/learn/opentelemetry/how-to-instrument.mdx
+++ b/learn/opentelemetry/how-to-instrument.mdx
@@ -45,4 +45,4 @@ Auto-instrumentation eliminates the need for manual code changes by **injecting
In many cases, these methods can complement each other. Start with auto-instrumentation to gain quick insights, then enhance with direct instrumentation to capture application-specific details.
-For more on how to add instrumentation to specifically integrate with Checkly Traces, [see our Traces documentation](https://www.checklyhq.com/docs/traces-open-telemetry/).
+For more on how to add instrumentation to specifically integrate with Checkly Traces, [see our Traces documentation](/resolve/traces/overview).
diff --git a/learn/opentelemetry/what-is-the-otel-collector.mdx b/learn/opentelemetry/what-is-the-otel-collector.mdx
index 0d462053..d7fa9a41 100644
--- a/learn/opentelemetry/what-is-the-otel-collector.mdx
+++ b/learn/opentelemetry/what-is-the-otel-collector.mdx
@@ -146,7 +146,7 @@ The OpenTelemetry Collector is useful for:
### Do I have to deploy an OpenTelemetry collector?
-You don't have to use a collector to gather OpenTelemetry data. In the simplest example where you're monitoring a single monolithic application, the difference without a collector would be at the time of reporting data: instead of traces, logs, and metrics going to a collector; data would travel directly to the storage endpoint. If you're starting out with a demo project, or you're only using OpenTelemetry for a very limited purpose (for example you're only implementing [OpenTelemetry to send a few key traces to Checkly](https://www.checklyhq.com/docs/traces-open-telemetry/how-it-works/)), it may make sense not to use a collector at all.
+You don't have to use a collector to gather OpenTelemetry data. In the simplest example where you're monitoring a single monolithic application, the difference without a collector would be at the time of reporting data: instead of traces, logs, and metrics going to a collector; data would travel directly to the storage endpoint. If you're starting out with a demo project, or you're only using OpenTelemetry for a very limited purpose (for example you're only implementing [OpenTelemetry to send a few key traces to Checkly](/resolve/traces/how-it-works)), it may make sense not to use a collector at all.
### What is the difference between the OpenTelemetry Agent and Collector?
diff --git a/learn/overview.mdx b/learn/overview.mdx
index dbc6d10e..c5af5028 100644
--- a/learn/overview.mdx
+++ b/learn/overview.mdx
@@ -15,7 +15,7 @@ Whether you're just getting started or looking to advance your monitoring skills
Learn how to install Playwright and get started with your first script.
diff --git a/learn/playwright/assertions.mdx b/learn/playwright/assertions.mdx
index 244c0896..90afd68b 100644
--- a/learn/playwright/assertions.mdx
+++ b/learn/playwright/assertions.mdx
@@ -89,7 +89,7 @@ Non-retrying assertions evaluate conditions only once. They are used when you ex
| `expect(value).toBeDefined()` | value is defined (not `undefined`). |
| `expect(value).toBeNaN()` | value is `NaN`. |
-This makes the most sense when using Playwright to run single end-to-end tests in a controlled environment. If you're using Playwright to run on a cadence and monitor a production system, for example, with [Checkly](https://www.checklyhq.com/docs/browser-checks/playwright-test/), you generally want to stick with the auto-retrying assertions to avoid unnecessary alerts.
+This makes the most sense when using Playwright to run single end-to-end tests in a controlled environment. If you're using Playwright to run on a cadence and monitor a production system, for example, with [Checkly](/detect/synthetic-monitoring/browser-checks/playwright-support), you generally want to stick with the auto-retrying assertions to avoid unnecessary alerts.
### Negating Assertions
diff --git a/learn/playwright/bypass-totp.mdx b/learn/playwright/bypass-totp.mdx
index 252c03ff..e2fee47a 100644
--- a/learn/playwright/bypass-totp.mdx
+++ b/learn/playwright/bypass-totp.mdx
@@ -186,7 +186,7 @@ test("GitHub 2FA works", async ({ page }) => {
I’m still amazed at how far we’ve come with the recent tooling. Playwright continues pushing out monthly releases, and I can’t wait to see what they’ll come up with in the upcoming months.
-But keep in mind end-to-end testing is only a tiny fraction of guaranteeing that your product is working. Third-party providers can go rogue, or your database can struggle days after you tested your deployment. That’s why I’m excited to announce that [the recently released Checkly runtime (2022.10)](https://www.checklyhq.com/docs/runtimes/specs/#2022.10) includes the “otpauth” package and allows you to test your products at all times — even the ones that are behind a 2FA secured login!
+But keep in mind end-to-end testing is only a tiny fraction of guaranteeing that your product is working. Third-party providers can go rogue, or your database can struggle days after you tested your deployment. That’s why I’m excited to announce that [the recently released Checkly runtime (2022.10)](/platform/runtimes/runtime-specification#2022.10) includes the “otpauth” package and allows you to test your products at all times — even the ones that are behind a 2FA secured login!
Do you want to be the first one to know when something’s off with your application? Give Checkly a try 😉.
diff --git a/learn/playwright/mock-api.mdx b/learn/playwright/mock-api.mdx
index 965a5142..23580d07 100644
--- a/learn/playwright/mock-api.mdx
+++ b/learn/playwright/mock-api.mdx
@@ -180,13 +180,13 @@ We can also stress test the UI in other ways: returning very large numbers for t
### Editing API responses and visual regression tests
-As we find ourselves testing correct rendering of a page under unusual conditions, this does suggest a [visual regression test](https://www.checklyhq.com/docs/browser-checks/visual-regression-snapshot-testing/) to make sure a page looks correct. Visual regression tests shouldn’t be a default mode for functionality testing, but they are part of our toolkit and editing dynamic API responses can be an effective way of making sure that a page is always rendering with identical data for visual comparison.
+As we find ourselves testing correct rendering of a page under unusual conditions, this does suggest a [visual regression test](/detect/synthetic-monitoring/browser-checks/visual-regressions) to make sure a page looks correct. Visual regression tests shouldn’t be a default mode for functionality testing, but they are part of our toolkit and editing dynamic API responses can be an effective way of making sure that a page is always rendering with identical data for visual comparison.
*With fixed responses for dynamic page components, a visual regression test can create a golden file with a screenshot that isn’t expected to change*
-To go further, see our full documentation on [visual regression checks in Playwright and Checkly](https://www.checklyhq.com/docs/browser-checks/visual-regression-snapshot-testing/#visual-regression--snapshot-testing).
+To go further, see our full documentation on [visual regression checks in Playwright and Checkly](/detect/synthetic-monitoring/browser-checks/visual-regressions#visual-regression--snapshot-testing).
## Results and Conclusions: Playwright Mocking and Testing in Production
diff --git a/learn/playwright/testing-apis.mdx b/learn/playwright/testing-apis.mdx
index 8d1cab6d..5be294ea 100644
--- a/learn/playwright/testing-apis.mdx
+++ b/learn/playwright/testing-apis.mdx
@@ -111,7 +111,7 @@ with
Now we'll need to run our test locally at least once with the -update-snapshots flag, and we'll save an initial version of the JSON to compare later:
`npx playwright test -update-snapshots`
-The nice thing about this method is, not having to fool around with the file system, it means we can run this test from automated testing and [monitoring platforms like Checkly](https://www.checklyhq.com/docs/browser-checks/visual-regression-snapshot-testing/) without having to send example JSON or encode it into our test code.
+The nice thing about this method is, not having to fool around with the file system, it means we can run this test from automated testing and [monitoring platforms like Checkly](/detect/synthetic-monitoring/browser-checks/visual-regressions) without having to send example JSON or encode it into our test code.
## Filtering your API response
@@ -142,7 +142,7 @@ This test now validates a filtered response, all within the same Playwright test
## Continuous Monitoring with Playwright and Checkly
-By running multiple small API requests from within Playwright, you can verify the underlying APIs you need for your pages. If you want to monitor all your API endpoints continually, check out Checkly’s API monitors. Checkly API monitors let you run on a schedule with [dynamic notification settings and retries](https://www.checklyhq.com/docs/api-checks/limits/), run from multiple geographies, and even [run setup and teardown scripts](https://www.checklyhq.com/docs/api-checks/setup-teardown-scripts/) to add logic for your test, and clean up after your test.
+By running multiple small API requests from within Playwright, you can verify the underlying APIs you need for your pages. If you want to monitor all your API endpoints continually, check out Checkly’s API monitors. Checkly API monitors let you run on a schedule with [dynamic notification settings and retries](/detect/synthetic-monitoring/api-checks/response-limits), run from multiple geographies, and even [run setup and teardown scripts](/detect/synthetic-monitoring/api-checks/setup-and-teardown) to add logic for your test, and clean up after your test.
diff --git a/learn/playwright/testing-coupons.mdx b/learn/playwright/testing-coupons.mdx
index 055bad5f..24b9f764 100644
--- a/learn/playwright/testing-coupons.mdx
+++ b/learn/playwright/testing-coupons.mdx
@@ -80,6 +80,6 @@ node coupon.js
## Takeaways
1. We can simply verify that coupons are accepted, or also check that they command the right discount.
-2. Assertion libraries are useful when non-trivial [assertions](https://www.checklyhq.com/docs/api-checks/assertions/) are required.
+2. Assertion libraries are useful when non-trivial [assertions](/detect/synthetic-monitoring/api-checks/configuration) are required.
diff --git a/platform/managing-false-positives.mdx b/platform/managing-false-positives.mdx
index 02cd041f..382f4aa7 100644
--- a/platform/managing-false-positives.mdx
+++ b/platform/managing-false-positives.mdx
@@ -42,7 +42,7 @@ Running checks from a specific region is important when you need to monitor your
Depending on your use case, we recommend running checks from at least two different regions to more accurately differentiate between a regional network issue and a genuine application problem.
-Learn more about setting up multi-location checks: [Global Location and Scheduling Strategies](https://www.checklyhq.com/docs/monitoring/global-locations/).
+Learn more about setting up multi-location checks: [Global Location and Scheduling Strategies](/concepts/locations).
### Fine-Tune Your Alerting
@@ -58,8 +58,8 @@ In some cases, firewalls, load balancers, or security solutions might inadverten
To prevent this, we recommend reviewing your security settings to ensure that Checkly’s IP ranges are included in your allowlist.
-You can find Checkly’s current IP ranges here: [Allowlisting & filtering traffic](https://www.checklyhq.com/docs/monitoring/allowlisting/#ip-range-allowlisting).
+You can find Checkly’s current IP ranges here: [Allowlisting & filtering traffic](/platform/allowlisting-traffic#ip-range-allowlisting).
## If Issues Persist
-Use [Checkly's Network Diagnostic Tools](./network-diagnostic-tools) to inspect failed checks for issues like DNS errors, dropped packets, or failed handshakes. If that doesn't reveal the root cause, don't hesitate to reach out to [support@checklyhq.com](mailto:support@checklyhq.com), and our team will help investigate further.
\ No newline at end of file
+Use [Checkly's Network Diagnostic Tools](/platform/network-diagnostic-tools) to inspect failed checks for issues like DNS errors, dropped packets, or failed handshakes. If that doesn't reveal the root cause, don't hesitate to reach out to [support@checklyhq.com](mailto:support@checklyhq.com), and our team will help investigate further.
\ No newline at end of file
diff --git a/platform/reporting/analytics-api.mdx b/platform/reporting/analytics-api.mdx
index 9fb45023..54187525 100644
--- a/platform/reporting/analytics-api.mdx
+++ b/platform/reporting/analytics-api.mdx
@@ -14,7 +14,7 @@ Use powerful options like `quickRange` to select time window presets like `last3
per `location` or per `pageIndex`. For aggregated queries you can set the `aggregationInterval` to get, for instance, data
aggregated per week over the last 30 days.
-Dive straight into the [API reference](/api-reference/analytics) or keep reading for more examples!
+Dive straight into the [API reference](/api-reference/analytics/api-checks) or keep reading for more examples!
## Analytics API basics
@@ -153,7 +153,7 @@ First, you need to create the Data Source with the Analytics API connection. Aft
2. Configuring a component
Next, you can pick a **time series** component and configure it by selecting the `Checkly Analytics API` data source and
-setting the required HTTP header and query parameters to fetch the JSON. You'll find detailed docs on available parameters in the [API docs](/api-reference/analytics)
+setting the required HTTP header and query parameters to fetch the JSON. You'll find detailed docs on available parameters in the [API docs](/api-reference/analytics/api-checks)
In the following image you'll see all required configuration for a component:
diff --git a/platform/runtimes/overview.mdx b/platform/runtimes/overview.mdx
index 49bb885f..7f10fbe7 100644
--- a/platform/runtimes/overview.mdx
+++ b/platform/runtimes/overview.mdx
@@ -57,7 +57,7 @@ We introduced the concept of runtimes so customers can upgrade their JavaScript
Currently, Checkly is not a full-blown CI system, where a user has full control over the Node.js version and the packages installed in the `node_modules` directory. To help you navigate this tradeoff, we want to show you exactly what happens under the hood.
-1. We bundle all your user code when using the [Checkly CLI](/cli) or GitHub Sync before storing your Check in our database.
+1. We bundle all your user code when using the [Checkly CLI](/cli/overview) or GitHub Sync before storing your Check in our database.
2. Your Check is scheduled to our 20+ global locations via a message bus that has a 256kb file size limit. This is in 99%
of the cases more than enough for any user code and included file dependencies you may include. However, it is not enough for potentially unlimited
NPM dependencies living in `node_modules`.