diff --git a/ai/llms-txt.mdx b/ai/llms-txt.mdx index ec44bf2c..15cf8c93 100644 --- a/ai/llms-txt.mdx +++ b/ai/llms-txt.mdx @@ -16,11 +16,9 @@ The [llms.txt standard](https://llmstxt.org/) provides a machine-readable index - [Adding team members to your Checkly account](https://checklyhq.com/docs/admin/team-management/adding-team-members.md): Learn how to invite team members to join your Checkly account and manage team collaboration - [Using Microsoft Entra ID for Single Sign-on in Checkly](https://checklyhq.com/docs/admin/team-management/microsoft-azure-ad.md): This page illustrates the standard procedure to follow in order to get started with Microsoft Entra ID SSO (formerly Azure AD) on Checkly. - [Multi-Factor Authentication in Checkly](https://checklyhq.com/docs/admin/team-management/multi-factor-authentication.md): Learn how to set up and manage multi-factor authentication for enhanced account security -- [Using Okta for Single Sign-on in Checkly](https://checklyhq.com/docs/admin/team-management/okta.md): This page illustrates the standard procedure to follow in order to get started with Okta SSO on Checkly. -- [Role Based Access Control in Checkly](https://checklyhq.com/docs/admin/team-management/rbac.md): Checkly roles and permissions for team members -- [Removing team members from your Checkly account](https://checklyhq.com/docs/admin/team-management/removing-team-members.md): Learn how to remove team members from your Checkly account and understand how it affects your billing -- [Using SAML for Single Sign-On in Checkly](https://checklyhq.com/docs/admin/team-management/saml-sso.md): Learn how to set up SAML-based SSO for your Checkly account with supported identity providers -- [Using SCIM provisioning in Checkly](https://checklyhq.com/docs/admin/team-management/scim-provisioning.md): Learn how to set up SCIM provisioning for Checkly using your identity provider +- [Admin Overview](https://checklyhq.com/docs/admin/team-management/overview.md): Comprehensive guide to managing your Checkly account, team members, security, and integrations +- [SAML for Single Sign-on in Checkly](https://checklyhq.com/docs/admin/team-management/saml.md): Learn how to configure SAML SSO integration with Checkly for your organization +- [Single Sign-on in Checkly](https://checklyhq.com/docs/admin/team-management/single-sign-on.md): Overview of Single Sign-On (SSO) options available in Checkly for enterprise security - [Team management in Checkly](https://checklyhq.com/docs/admin/team-management.md): Manage your team and collaborate effectively in Checkly ``` diff --git a/detect/synthetic-monitoring/browser-checks/file-system.mdx b/detect/synthetic-monitoring/browser-checks/file-system.mdx index 6ec2e3ff..c6200ee5 100644 --- a/detect/synthetic-monitoring/browser-checks/file-system.mdx +++ b/detect/synthetic-monitoring/browser-checks/file-system.mdx @@ -138,7 +138,7 @@ import { test, expect } from '@playwright/test' test('Upload a file using a POST request', async ({ request }) => { const fileUrl = 'https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf' const fileBuffer = await request.get(fileUrl) - const response = await request.post('https://filebin.net/pp9on3zvwv7zq6lm/dummy.pdf', { + const response = await request.post('https://httpbin.org/post', { data: await fileBuffer.body(), }) await expect(response).toBeOK() @@ -151,7 +151,7 @@ const { test, expect } = require('@playwright/test') test('Upload a file using a POST request', async ({ request }) => { const fileUrl = 'https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf' const fileBuffer = await request.get(fileUrl) - const response = await request.post('https://filebin.net/pp9on3zvwv7zq6lm/dummy.pdf', { + const response = await request.post('https://httpbin.org/post', { data: await fileBuffer.body(), }) await expect(response).toBeOK() diff --git a/detect/synthetic-monitoring/multistep-checks/file-system.mdx b/detect/synthetic-monitoring/multistep-checks/file-system.mdx index 314005f7..1693ba33 100644 --- a/detect/synthetic-monitoring/multistep-checks/file-system.mdx +++ b/detect/synthetic-monitoring/multistep-checks/file-system.mdx @@ -27,7 +27,7 @@ test('Upload a file using a POST request', async ({ request }) => { }) await test.step('Upload file', async () => { - const response = await request.post('https://filebin.net/pp9on3zvwv7zq6lm/dummy.pdf', { + const response = await request.post('https://httpbin.org/post', { data: await fileBuffer.body(), }) await expect(response).toBeOK() @@ -45,7 +45,7 @@ test('Upload a file using a POST request', async ({ request }) => { }) await test.step('Upload file', async () => { - const response = await request.post('https://filebin.net/pp9on3zvwv7zq6lm/dummy.pdf', { + const response = await request.post('https://httpbin.org/post', { data: await fileBuffer.body(), }) await expect(response).toBeOK() diff --git a/detect/testing/playwright-reporter.mdx b/detect/testing/playwright-reporter.mdx index d7650e23..89c062ec 100644 --- a/detect/testing/playwright-reporter.mdx +++ b/detect/testing/playwright-reporter.mdx @@ -17,7 +17,7 @@ Before using the Playwright reporter, ensure you have: - Node.js >= 18.0.0 - Playwright >= 1.40.0 -- A Checkly account ([sign up](https://www.checklyhq.com/signup)) +- A Checkly account ([sign up](https://app.checklyhq.com/signup)) ## Install the Playwright Reporter diff --git a/docs.json b/docs.json index 6d36365c..cb2985e2 100644 --- a/docs.json +++ b/docs.json @@ -1415,6 +1415,14 @@ "source": "/api-reference/error-groups/update-an-error-group-mainly-used-for-archiving-error-groups/", "destination": "/api-reference/error-groups/update-an-error-group" }, + { + "source": "/monitoring/check-results", + "destination": "/concepts/results" + }, + { + "source": "/detect/synthetic-monitoring/browser-checks/results", + "destination": "/concepts/results" + }, { "source": "/assertions", "destination": "/detect/assertions" diff --git a/guides/create-multiple-monitors.mdx b/guides/create-multiple-monitors.mdx index a164843b..d7704e08 100644 --- a/guides/create-multiple-monitors.mdx +++ b/guides/create-multiple-monitors.mdx @@ -73,7 +73,7 @@ import { Frequency, UrlMonitor, UrlAssertionBuilder } from 'checkly/constructs' const sitemapUrls = [ 'https://www.checklyhq.com/docs/', 'https://www.checklyhq.com/learn/playwright/codegen/', - 'https://www.checklyhq.com/guides/using-pw-test-command/', + 'https://www.checklyhq.com/docs/guides/setup-scripts-for-apis/', 'https://www.checklyhq.com/docs/api-reference/incidents/create-an-incident/', 'https://www.checklyhq.com/customers/' ] @@ -132,7 +132,7 @@ In our previous check, we defined the URLs to monitor in an array at the top of const sitemapUrls = [ 'https://www.checklyhq.com/docs/', 'https://www.checklyhq.com/learn/playwright/codegen/', - 'https://www.checklyhq.com/guides/using-pw-test-command/', + 'https://www.checklyhq.com/docs/guides/setup-scripts-for-apis/', 'https://www.checklyhq.com/docs/api-reference/incidents/create-an-incident/', 'https://www.checklyhq.com/customers/' ] @@ -144,7 +144,7 @@ Rather than having to edit this check’s code every time we update our list of { "urls":[ "https://www.checklyhq.com/docs/", "https://www.checklyhq.com/learn/playwright/codegen/", - "https://www.checklyhq.com/guides/using-pw-test-command/", + "https://www.checklyhq.com/docs/guides/setup-scripts-for-apis/", "https://www.checklyhq.com/docs/api-reference/incidents/create-an-incident/", "https://www.checklyhq.com/customers/" ]} @@ -166,10 +166,10 @@ Let’s continue to increase the sophistication of our group of monitors. Right | url | logicalID | name | | --- | --- | --- | -| [https://www.checklyhq.com/docs/](https://www.checklyhq.com/docs/,) | docs-1 | url monitor docs-1 | -| [https://www.checklyhq.com/learn/playwright/codegen/](https://www.checklyhq.com/learn/playwright/codegen/,) | codegen-1 | url monitor codegen-1 | -| [https://www.checklyhq.com/guides/using-pw-test-command/](https://www.checklyhq.com/guides/using-pw-test-command/,) | pw-test-1 | url monitor pw-test-1 | -| [https://www.checklyhq.com/docs/api-reference/incidents/create-an-incident/](https://www.checklyhq.com/docs/api-reference/incidents/create-an-incident/,) | incidents-1 | url monitor incidents-1 | +| `https://www.checklyhq.com/docs/` | docs-1 | url monitor docs-1 | +| `https://www.checklyhq.com/learn/playwright/codegen/` | codegen-1 | url monitor codegen-1 | +| `https://www.checklyhq.com/guides/using-pw-test-command/` | pw-test-1 | url monitor pw-test-1 | +| `https://www.checklyhq.com/docs/api-reference/incidents/create-an-incident/` | incidents-1 | url monitor incidents-1 | And this version of the URL monitor fetches the CSV and parses the three values for each check from the row before creating a monitor. diff --git a/guides/getting-started-with-monitoring-as-code.mdx b/guides/getting-started-with-monitoring-as-code.mdx index 29f3171a..6c83d35a 100644 --- a/guides/getting-started-with-monitoring-as-code.mdx +++ b/guides/getting-started-with-monitoring-as-code.mdx @@ -85,7 +85,7 @@ test('Checkly Docs', async ({ page }) => { --- -This test uses the page.goto method to navigate to the specified URL (‘[https://www.checklyhq.com/docs/browser-checks/’](https://www.checklyhq.com/docs/browser-checks/%E2%80%99)). 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. @@ -142,7 +142,7 @@ To set up alerts for your check, go to the specific project, in this case, "home ![setting up alerts with checkly](/images/guides/images/guides-getting-started-alerts.jpeg "Setting up Alerts with Checkly") -Here, configure monitoring parameters according to your needs, including check frequency, locations, retries and alerting. You can also set up your preferred alert channel using the Checkly CLI. Learn more about the alert channels from the [official documentation](https://www.checklyhq.com/cli/overviewconstructs-reference/#alertchannel). +Here, configure monitoring parameters according to your needs, including check frequency, locations, retries and alerting. You can also set up your preferred alert channel using the Checkly CLI. Learn more about the alert channels from the [official documentation](/constructs/alert-channel). With the appropriate alert channels set up, there is no need for customers to regularly visit the dashboard. Instead, they will be promptly notified, allowing them to react immediately upon receiving alerts. diff --git a/guides/monitoring-an-openapi-spec.mdx b/guides/monitoring-an-openapi-spec.mdx index 8674d9b3..33b3012c 100644 --- a/guides/monitoring-an-openapi-spec.mdx +++ b/guides/monitoring-an-openapi-spec.mdx @@ -15,7 +15,7 @@ Following the OAS brings the following advantages: 2. The possibility of automatically generating documentation, implementation logic and even mock servers for testing. 3. Early validation of the data flows happening within the API. -For those new to the OAS and wanting to get a basic understanding without diving straight into the specification itself, the official [OpenAPI Specification Explained](https://oai.github.io/Documentation/specification.html) guide is a great place to start. +For those new to the OAS and wanting to get a basic understanding without diving straight into the specification itself, the official [OpenAPI Specification Explained](https://learn.openapis.org/specification/) guide is a great place to start. ## Swagger vs OpenAPI @@ -186,7 +186,7 @@ Depending on how much is described in a given API spec, it is possible to move e ## Generated monitoring checks with Checkly -[API monitoring](/learn/monitoring/api-monitoring) is key to ensure that our endpoints are returning the correct results in an acceptable timeframe. If we can generate APIs from a OAS description file, we can also generate monitoring checks for them. Checkly is [a member of the OpenAPI initiative](https://www.openapis.org/membership/members), and allows us to import an OpenAPI spec file and automatically creates one or more checks depending on the amount of information available. All it takes is a couple of clicks. +[API monitoring](/learn/monitoring/api-monitoring) is key to ensure that our endpoints are returning the correct results in an acceptable timeframe. If we can generate APIs from a OAS description file, we can also generate monitoring checks for them. Checkly is [a member of the OpenAPI initiative](https://www.openapis.org/about), and allows us to import an OpenAPI spec file and automatically creates one or more checks depending on the amount of information available. All it takes is a couple of clicks. When creating an API check, select the `import from Swagger / OpenAPI` button. diff --git a/guides/monitoring-ecommerce-apps-using-playwright.mdx b/guides/monitoring-ecommerce-apps-using-playwright.mdx index 80482969..b4365271 100644 --- a/guides/monitoring-ecommerce-apps-using-playwright.mdx +++ b/guides/monitoring-ecommerce-apps-using-playwright.mdx @@ -44,7 +44,7 @@ Watch our launch event to learn more about our CLI: Users who have already used Checkly will be familiar with creating Checks, Check Groups, Alert Channels and other resources through the Checkly UI. Creating, debugging and managing E2E and synthetic monitoring at scale is best done “as code”. Currently, Checkly supports three tools you can use for your monitoring as code (MaC) workflow: 1. [The Checkly CLI.](https://www.checklyhq.com/cli/overview) -2. [Terraform (through our Terraform provider)](https://checklyhq-com-git-cli-guide-checkly.vercel.app/docs/terraform-provider/) +2. [Terraform (through our Terraform provider)](/integrations/iac/terraform/overview) 3. [Pulumi (through our Pulumi provider)](https://www.checklyhq.com/docs/integrations/pulumi/) ## Monitoring an e-commerce website - as code diff --git a/guides/moving-from-puppeteer-to-playwright.mdx b/guides/moving-from-puppeteer-to-playwright.mdx index b92abcaa..cf686a53 100644 --- a/guides/moving-from-puppeteer-to-playwright.mdx +++ b/guides/moving-from-puppeteer-to-playwright.mdx @@ -48,7 +48,7 @@ Remember to add `await` as necessary. | `page.waitForXPath(XPathSelector)` | `page.waitForSelector(XPathSelector)` | | `page.$x(xpath_selector)` | `page.$(xpath_selector)` | | `page.waitForNetworkIdle(...)` | `page.waitForLoadState({ state: 'networkidle' })` | -| `page.waitForFileChooser(...)` | Removed, [handled differently](https://playwright.dev/docs/input/#upload-files). | +| `page.waitForFileChooser(...)` | Removed, [handled differently](https://playwright.dev/docs/input#upload-files). | | `page.waitFor(timeout)` | `page.waitForTimeout(timeout)` | | `page.type(selector, text)` | `page.fill(selector, text)` | | `page.cookies([...urls])` | `browserContext.cookies([urls])` | @@ -235,7 +235,7 @@ await page.route('**/*', (route) => { See our [full guide](/learn/playwright/intercept-requests) on request interception for more examples. -> For many of the points in the list above, variations of the same function exist at [Page](https://playwright.dev/docs/api/class-page/), [Frame](https://playwright.dev/docs/api/class-frame/) and [ElementHandle](https://playwright.dev/docs/api/class-elementhandle/) level. For simplicity, we reported only one. +> For many of the points in the list above, variations of the same function exist at [Page](https://playwright.dev/docs/api/class-page), [Frame](https://playwright.dev/docs/api/class-frame) and [ElementHandle](https://playwright.dev/docs/api/class-elementhandle) level. For simplicity, we reported only one. ## New possibilities to be aware of diff --git a/guides/sdlc-monitoring.mdx b/guides/sdlc-monitoring.mdx index f766c2b5..9f804b16 100644 --- a/guides/sdlc-monitoring.mdx +++ b/guides/sdlc-monitoring.mdx @@ -208,7 +208,7 @@ This command overrides the `SCREENSHOT_URL` variable for that specific test run, ### Optional: Private locations for running Checkly within your cloud -For enterprise users, you may want to run Checkly monitors from within your cloud. This is especially helpful if your API isn’t available on the public internet, or you want to run checks from a geographic location not covered by the Checkly system. If your development and staging locations are running on private clouds, a [Checkly Private Location](https://www.checklyhq.com/docs/detect/private-locations/overview) makes testing easier. +For enterprise users, you may want to run Checkly monitors from within your cloud. This is especially helpful if your API isn’t available on the public internet, or you want to run checks from a geographic location not covered by the Checkly system. If your development and staging locations are running on private clouds, a [Checkly Private Location](/platform/private-locations/overview) makes testing easier. ![a diagram showing A container on your cloud running a Checkly Private Location](/images/guides/images/sdlc-monitoring-06.png) @@ -247,7 +247,7 @@ Checkly Traces is easy to implement even if you aren’t currently using OpenTel Once you’ve moved to production, it’s time to run your tests on a cadence, creating a monitor that tell you within minutes if any part of your service goes down. The process for setting this cadence looks like: 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](https://www.checklyhq.com/cli/overviewproject-structure/) file +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 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. diff --git a/guides/uptime-monitoring.mdx b/guides/uptime-monitoring.mdx index 19e0b4e9..36ef7333 100644 --- a/guides/uptime-monitoring.mdx +++ b/guides/uptime-monitoring.mdx @@ -77,13 +77,13 @@ new TcpMonitor('hello-tcp-1', { *A basic URL monitor ready to deploy* -TCP monitors offer similar options to URL monitors, with the addition of assertions to evaluate the responses. Read more about [TCP check assertions on our docs site](https://www.checklyhq.com/cli/overviewconstructs-reference/#tcpassertionbuilder). +TCP monitors offer similar options to URL monitors, with the addition of assertions to evaluate the responses. Read more about [TCP check assertions on our docs site](/constructs/tcp-monitor). ![A TCP check dashboard](/images/guides/images/uptime-01.png) *Results for TCP checks include the status of your SSL certification, and can send alerts if your certs are close to expiring.* -TCP checks are also helpful at identifying any DNS issues, as these request will also perform DNS lookup if you provide a hostname and, like the other checks in this guide, [the results for a TCP check](https://www.checklyhq.com/docs/monitoring/check-results/#tcp-monitor-results) will include DNS lookup time. +TCP checks are also helpful at identifying any DNS issues, as these request will also perform DNS lookup if you provide a hostname and, like the other checks in this guide, [the results for a TCP check](/concepts/results) will include DNS lookup time. ## The Heartbeat Monitor, for services that don’t accept incoming requests diff --git a/integrations/iac/terraform/command-line-triggers.mdx b/integrations/iac/terraform/command-line-triggers.mdx index 054ce909..cc351f9a 100644 --- a/integrations/iac/terraform/command-line-triggers.mdx +++ b/integrations/iac/terraform/command-line-triggers.mdx @@ -4,7 +4,7 @@ sidebarTitle: 'Command line Triggers' description: 'Set up command line triggers to run checks from CI/CD pipelines or programmatically' --- -[Command line triggers](https://www.checklyhq.com/docs/cicd/triggers/) enable you to call a check from a CI/CD pipeline, a bash shell or programmatically in your code. +[Command line triggers](/cli/checkly-trigger) enable you to call a check from a CI/CD pipeline, a bash shell or programmatically in your code. You can specify command line triggers as standalone resources at check or group level: diff --git a/integrations/incident-management/firehydrant.mdx b/integrations/incident-management/firehydrant.mdx index 664f9737..a251ed24 100644 --- a/integrations/incident-management/firehydrant.mdx +++ b/integrations/incident-management/firehydrant.mdx @@ -9,7 +9,7 @@ Checkly integrates with [FireHydrant](https://firehydrant.io/) to create and res * Alert you on Slack when a check fails, allowing you to create an incident on FireHydrant with one click. * Close incidents automatically when a failing check recovers. -Assuming you already have [set up Slack on FireHydrant](https://support.firehydrant.io/hc/en-us/articles/360058203511), the integration can be configured as follows: +Assuming you already have [set up Slack on FireHydrant](https://docs.firehydrant.com/), the integration can be configured as follows: 1. Log in to FireHydrant and navigate to `Integrations > Connected & available`, then select Checkly. diff --git a/learn/incidents/anatomy-of-a-status-page.mdx b/learn/incidents/anatomy-of-a-status-page.mdx index a21ab32e..270d6d16 100644 --- a/learn/incidents/anatomy-of-a-status-page.mdx +++ b/learn/incidents/anatomy-of-a-status-page.mdx @@ -50,7 +50,7 @@ A good status page keeps users informed, reduces frustration, and builds trust. The basic technical requirements (fast loading pages, manual edits permitted, etc) aren’t worth mentioning, but the following features will require some ‘lift’ on any DIY solution, and aren’t offered by every SaaS status page tool. -**1. Automated monitoring** - no matter how slick our status page, if we’re relying on users to report most outages, our status page is worse than useless. Implicit in the requirements above is that most outages and incidents will be detected automatically and added to a status page. The best way to determine your service status automatically is through [synthetic monitoring](https://www.checklyhq.com/learn/monitoring/synthetic-transaction-monitoring/), ideally using [Playwright](https://www.checklyhq.com/learn/playwright/) to simulate user paths in detail. +**1. Automated monitoring** - no matter how slick our status page, if we’re relying on users to report most outages, our status page is worse than useless. Implicit in the requirements above is that most outages and incidents will be detected automatically and added to a status page. The best way to determine your service status automatically is through [synthetic monitoring](/learn/monitoring/transaction-monitoring), ideally using [Playwright](https://www.checklyhq.com/learn/playwright/) to simulate user paths in detail. **2. Independent hosting** - ideally both your monitoring and the status page will be hosted away from your service’s cloud. Even AWS are vulnerable to failures where the monitor (and its notifications) failed in the same outage that took down the service, adding significantly to [time to repair](https://www.checklyhq.com/learn/incidents/mttr-challenges/). diff --git a/learn/incidents/mttr-challenges.mdx b/learn/incidents/mttr-challenges.mdx index 557a192b..2642e998 100644 --- a/learn/incidents/mttr-challenges.mdx +++ b/learn/incidents/mttr-challenges.mdx @@ -25,7 +25,7 @@ Imagine you’re trying to solve an outage that’s only affecting some users an When tools are cumbersome and fail to provide actionable insights, engineers spend more time diagnosing problems, which increases MTTR. ### 2. **Time to Detect (TTD) Is Overlooked** -Another factor contributing to high MTTR is the time it takes to detect an issue in the first place. Reducing the mean time to detect ([MTTD](https://www.checklyhq.com/learn/monitoring/reduce-mttd/)) is crucial for improving MTTR, as delays in detection can lead to prolonged outages. +Another factor contributing to high MTTR is the time it takes to detect an issue in the first place. Reducing the mean time to detect ([MTTD](/learn/incidents/reduce-mttd)) is crucial for improving MTTR, as delays in detection can lead to prolonged outages. An entire guide on time to detection is available on our Learn site, but in short the most common failures are: @@ -33,7 +33,7 @@ An entire guide on time to detection is available on our Learn site, but in shor - Low-frequency monitoring — if you’re using an automated system to check your service’s availability, it’s critical to [set the right frequency for those checks](https://www.checklyhq.com/blog/check-frequency/). Checks that are happening only every 15 minutes won’t provide much better time to detection than waiting for users to report problems. - Slow alerting — While most teams doing monitoring think quite a bit about the optimal frequency for those checks, less thought is put into the time spent between detection and sending an alert to the on-call team. On more than one occasion this author has seen teams drastically improve their MTTR just by adopting faster standards for how the on-call team got notified (for example adding alert channels beyond email). -Again these concerns and more are in a separate page on [optimizing time to detection](https://www.checklyhq.com/learn/monitoring/reduce-mttd/). +Again these concerns and more are in a separate page on [optimizing time to detection](/learn/incidents/reduce-mttd). ### 3. **The Complexity of Cloud-Native Environments** @@ -52,7 +52,7 @@ To address these challenges, organizations need to focus on optimizing each stag ### 1. **Reduce Time to Detect (TTD)** -Improving detection times requires robust monitoring and alerting systems that can quickly identify issues. This involves setting low scrape intervals for data collection and ensuring that observability tools can ingest and generate alerts rapidly. Faster detection allows teams to begin remediation efforts sooner, which can significantly reduce MTTR. This is covered in more detail in our page on [optimizing detection time](https://www.checklyhq.com/learn/monitoring/reduce-mttd/). +Improving detection times requires robust monitoring and alerting systems that can quickly identify issues. This involves setting low scrape intervals for data collection and ensuring that observability tools can ingest and generate alerts rapidly. Faster detection allows teams to begin remediation efforts sooner, which can significantly reduce MTTR. This is covered in more detail in our page on [optimizing detection time](/learn/incidents/reduce-mttd). ### 2. **Streamline Time to Remediate** diff --git a/learn/monitoring/api-monitoring.mdx b/learn/monitoring/api-monitoring.mdx index d66e871c..4a4f1eec 100644 --- a/learn/monitoring/api-monitoring.mdx +++ b/learn/monitoring/api-monitoring.mdx @@ -76,7 +76,7 @@ The next step is to choose an API monitoring tool that will best support your ne 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](https://www.checklyhq.com/guides/setup-scripts/) 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](https://www.checklyhq.com/integrations/), 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](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. ## API Monitoring as Code @@ -193,7 +193,7 @@ Tools like Checkly offer real-time data collection and visualization, enabling d ### Essential monitoring integrations -**Integration** ensures seamless operations and efficient error detection. Choose a tool with robust integration capabilities, like Checkly, which [integrates with tools](https://www.checklyhq.com/docs/integrations/) like Slack, PagerDuty, and Jira. It also offers a REST API for automation and integration into existing workflows. +**Integration** ensures seamless operations and efficient error detection. Choose a tool with robust integration capabilities, like Checkly, which [integrates with tools](/communicate/alerts/channels) like Slack, PagerDuty, and Jira. It also offers a REST API for automation and integration into existing workflows. ### Resources and technical support diff --git a/learn/monitoring/https-for-app-developers.mdx b/learn/monitoring/https-for-app-developers.mdx index 55cbf6a5..be67ef22 100644 --- a/learn/monitoring/https-for-app-developers.mdx +++ b/learn/monitoring/https-for-app-developers.mdx @@ -59,7 +59,7 @@ To enhance security, developers should use HTTP Strict Transport Security (HSTS) 3. **Test Your Setup**: - Use tools like SSL Labs ([https://www.ssllabs.com/](https://www.ssllabs.com/)) to check if your HTTPS setup is correct. - Make sure your app works smoothly with HTTPS. - - Monitor your connections with an automated monitor like [Checkly](https://www.checklyhq.com/docs/monitoring/check-results/#multistep-check-results). + - Monitor your connections with an automated monitor like [Checkly](/concepts/results). --- diff --git a/learn/monitoring/metrics-every-team-needs.mdx b/learn/monitoring/metrics-every-team-needs.mdx index d879d35a..cb00756b 100644 --- a/learn/monitoring/metrics-every-team-needs.mdx +++ b/learn/monitoring/metrics-every-team-needs.mdx @@ -144,7 +144,7 @@ By measuring these fundamentals, your team can: ✔ Prevent minor issues from becoming major outages -Part of starting small is considering the most basic questions first: with Checkly, you can create an automated service to simulate common user requests, and report immediately if anything looks incorrect. Checkly’s [synthetic monitoring](https://www.checklyhq.com/learn/monitoring/synthetic-transaction-monitoring/) ensures that you’re not relying on users to report problems. +Part of starting small is considering the most basic questions first: with Checkly, you can create an automated service to simulate common user requests, and report immediately if anything looks incorrect. Checkly’s [synthetic monitoring](/learn/monitoring/transaction-monitoring) ensures that you’re not relying on users to report problems. --- diff --git a/learn/monitoring/real-user-monitoring.mdx b/learn/monitoring/real-user-monitoring.mdx index 14ece9c1..3531ba64 100644 --- a/learn/monitoring/real-user-monitoring.mdx +++ b/learn/monitoring/real-user-monitoring.mdx @@ -149,4 +149,4 @@ It’s unlikely that Real User Monitoring, as it works in the real world, would These are questions that only RUM can answer easily. -By focusing on aggregate insights, RUM helps prioritize optimizations that benefit the majority of users, while [synthetic monitoring](https://www.checklyhq.com/learn/monitoring/synthetic-transaction-monitoring/) performs consistent, repeatable observation of every critical path, and logs fill in the gaps for edge cases. The key is balancing depth with practicality—using RUM to guide improvements, not chase an unattainable "perfect observability" ideal. Start small, sample wisely, and correlate RUM data with other telemetry to build a complete picture of your application’s health. \ No newline at end of file +By focusing on aggregate insights, RUM helps prioritize optimizations that benefit the majority of users, while [synthetic monitoring](/learn/monitoring/transaction-monitoring) performs consistent, repeatable observation of every critical path, and logs fill in the gaps for edge cases. The key is balancing depth with practicality—using RUM to guide improvements, not chase an unattainable "perfect observability" ideal. Start small, sample wisely, and correlate RUM data with other telemetry to build a complete picture of your application’s health. \ No newline at end of file diff --git a/learn/opentelemetry/getting-started-with-observability.mdx b/learn/opentelemetry/getting-started-with-observability.mdx index 24b80886..e2afe035 100644 --- a/learn/opentelemetry/getting-started-with-observability.mdx +++ b/learn/opentelemetry/getting-started-with-observability.mdx @@ -83,7 +83,7 @@ The flexibility of the collector enables smooth transitions between direct repor - **Metrics Overview**: [Learn how OpenTelemetry handles metrics to provide high-level insights into your system's performance](/learn/opentelemetry/metrics). - **Logging with OpenTelemetry**: [Discover how OpenTelemetry integrates with existing logging libraries and enhances log data correlation across microservices](https://opentelemetry.io/docs/specs/otel/logs/). -- **Quick Start Guide**: A guide for setting up OpenTelemetry quickly to start monitoring your applications [here](https://opentelemetry.io/docs/quickstart/). +- **Quick Start Guide**: A guide for setting up OpenTelemetry quickly to start monitoring your applications [here](https://opentelemetry.io/docs/getting-started/). These resources explain the core pillars of observability, as well as how to use OpenTelemetry’s **Collector** to manage and export telemetry data to observability platforms like Prometheus and Grafana. diff --git a/learn/playwright/codegen.mdx b/learn/playwright/codegen.mdx index 16c2be0c..86822d1f 100644 --- a/learn/playwright/codegen.mdx +++ b/learn/playwright/codegen.mdx @@ -133,6 +133,6 @@ To see the highly visual codegen tool in action, check out Stefan’s video belo You’ve just taken your first steps with creating Playwright tests. Playwright's `codegen` is a powerful tool that simplifies the process of creating automation scripts. As it produces assertions and locators that are industry standard, you should use anytime you need to make a clean, readable test or automation for your site. -If you’d like to dive deeper into Playwright and Checkly’s monitoring tools, join our [upcoming Kick-Start webinar](https://us02web.zoom.us/webinar/register/WN_gKYeJcMqQ_Kh31ziKM7uYw) to see how your end-to-end testing can grow into bullet-proof site monitoring to defend your SLA. +If you’d like to dive deeper into Playwright and Checkly’s monitoring tools, explore the rest of our [Playwright learning resources](/learn/playwright/overview) to see how your end-to-end testing can grow into bullet-proof site monitoring to defend your SLA. diff --git a/learn/playwright/debugging.mdx b/learn/playwright/debugging.mdx index df69625f..22404b18 100644 --- a/learn/playwright/debugging.mdx +++ b/learn/playwright/debugging.mdx @@ -100,7 +100,7 @@ We can also use the console to directly try out a selector on the page in its cu ![debugging selectors in browser console](/images/samples/images/debugging-console.png) -If we are using Playwright, we can also run in debug mode with `PWDEBUG=console node script.js`. This provisions a `playwright` object in the browser which allows us to also try out [Playwright-specific selectors](https://playwright.dev/docs/selectors). +If we are using Playwright, we can also run in debug mode with `PWDEBUG=console node script.js`. This provisions a `playwright` object in the browser which allows us to also try out [Playwright-specific selectors](https://playwright.dev/docs/locators). ![debugging playwright-specific selectors in browser console](/images/samples/images/debugging-selectors.png) diff --git a/learn/playwright/error-target-closed.mdx b/learn/playwright/error-target-closed.mdx index 7d3406d0..2a63bffb 100644 --- a/learn/playwright/error-target-closed.mdx +++ b/learn/playwright/error-target-closed.mdx @@ -16,7 +16,7 @@ import SignUpCta from "/snippets/sign-up-cta.mdx" -Our script can return the sometimes cryptic "Target closed" error. Knowing that the "target" is normally our browser, the [context](https://playwright.dev/docs/core-concepts#browser-contexts) or tab that our script is controlling can help us close in on the cause of the issue. +Our script can return the sometimes cryptic "Target closed" error. Knowing that the "target" is normally our browser, the [context](https://playwright.dev/docs/browser-contexts) or tab that our script is controlling can help us close in on the cause of the issue. Example error message: ```sh diff --git a/learn/playwright/handling-test-data.mdx b/learn/playwright/handling-test-data.mdx index 21850e48..b3b14d05 100644 --- a/learn/playwright/handling-test-data.mdx +++ b/learn/playwright/handling-test-data.mdx @@ -24,7 +24,7 @@ We define _test data_ as any data we consistently use to verify properties such It is often desirable to [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) up our scripts by factoring out test data. In the case of simple tests, it's usually not an issue to embed test data directly inside our script, but complex end-to-end scenarios might require moving this information elsewhere, like a dedicated file. -Looking at our [test webshop](https://danube-store.herokuapp.com/), we might want to verify that a specific item list is loaded on the store's front page. As this list contains several tens of elements, each with different attributes, keeping our fixtures inside our script would be impractical. Let's add this data to a JSON file instead: +Looking at our [test webshop](https://danube-web.shop/), we might want to verify that a specific item list is loaded on the store's front page. As this list contains several tens of elements, each with different attributes, keeping our fixtures inside our script would be impractical. Let's add this data to a JSON file instead: ```json [ @@ -73,7 +73,7 @@ If the platform you are testing exposes an API endpoint to pull up-to-date test ```js const axios = require('axios') ... -const { data } = await axios.get('https://danube-store.herokuapp.com/api/books') +const { data } = await axios.get('https://danube-web.shop/api/books') const bookList = JSON.parse(data) const foundList = bookList ``` diff --git a/learn/playwright/multitab-flows.mdx b/learn/playwright/multitab-flows.mdx index b70cadc7..aa909a31 100644 --- a/learn/playwright/multitab-flows.mdx +++ b/learn/playwright/multitab-flows.mdx @@ -79,6 +79,6 @@ test('open multiple tabs', async ({ browser }) => { ## Further reading -1. Official documentation on [Playwright's multi-tab scenarios](https://playwright.dev/docs/multi-pages) +1. Official documentation on [Playwright's multi-tab scenarios](https://playwright.dev/docs/pages) diff --git a/learn/playwright/taking-screenshots.mdx b/learn/playwright/taking-screenshots.mdx index cadd9a8a..f7c386dd 100644 --- a/learn/playwright/taking-screenshots.mdx +++ b/learn/playwright/taking-screenshots.mdx @@ -96,7 +96,7 @@ test('visual regression', async ({ page }) => { ## Further reading -1. Official documentation for taking screenshots with [Playwright](https://playwright.dev/docs/verification?_highlight=screenshot#screenshots) +1. Official documentation for taking screenshots with [Playwright](https://playwright.dev/docs/screenshots) 2. Blog post from baseweb.design on the whys and hows of [visual regression testing](https://baseweb.design/blog/visual-regression-testing/) 3. Blog post from Gideon Pyzer looking at different visual [regression testing tools](https://gideonpyzer.dev/blog/2018/06/25/visual-regression-testing/) diff --git a/learn/playwright/web-scraping.mdx b/learn/playwright/web-scraping.mdx index 97d439e6..e7b0765b 100644 --- a/learn/playwright/web-scraping.mdx +++ b/learn/playwright/web-scraping.mdx @@ -188,7 +188,7 @@ $ node scraping.js ``` ## Further reading -1. [Playwright](https://playwright.dev/docs/assertions#text-content)'s official API reference on the topic +1. [Playwright](https://playwright.dev/docs/test-assertions)'s official API reference on the topic 2. An [E2E example test](/learn/playwright/testing-coupons/) asserting against an element's `innerText`