Fix broken & stale internal links from Ahrefs site audit (P0 + P1)

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.
 

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  
 

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).
 </Accordion>

detect/overview.mdx

@@ -34,7 +34,7 @@ Run automated Playwright tests to validate functionality and user workflows befo
 <Step title="Add Monitors to your project">
 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)
 </Step>
 
 <Step title="Configure Locations, Frequency, and Alerting">

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
 

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
 

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.

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.

detect/synthetic-monitoring/browser-checks/overview.mdx

@@ -104,7 +104,7 @@ test('User login workflow', async ({ page }) => {
 
 </Tabs>
 <Info>
-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).
 </Info>
 
 ## Browser Check Results

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

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

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.
 
 <Info>
 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.

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
 

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
 </Card>
 
-<Card title="Alert Configuration" href="/communicate/alerts">
+<Card title="Alert Configuration" href="/communicate/alerts/overview">
 Set up effective alerting for your TCP monitors
 </Card>
 </Columns>

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.

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.
 
 ![Checkly dashboard showing a check group with multiple monitors](/images/guides/images/monitor-creation-01.png)
 
@@ -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/)