Update TCP check overview page

site/content/docs/monitoring/check-pricing.md

@@ -15,12 +15,15 @@ Checkly supports different kinds of checks which are billed slightly differently
 | Check type | Base cost          | Parallel scheduling    | Retries             |
 |------------|--------------------|------------------------|---------------------|
 | Browser    | $5 per 1k runs     | Each location is a run | Each retry is a run |
-| API & network     | $2 per 10k runs    | Each location is a run | Each retry is a run |
-| Multistep  | $2 per 10k requests| Locations x requests   | Retries x requests  |
+| API    | $2 per 10k runs    | Each location is a run | Each retry is a run |
+| TCP    | $2 per 10k runs    | Each location is a run | Each retry is a run |
+| Multistep  | $2 per 10k requests| Locations × requests   | Retries × requests  |
 | Heartbeat  | -                  | -                      | -                   |
 
 > The check prices above are based on prepaid check bundles as shown on our [Pricing page](https://www.checklyhq.com/pricing/). If you are on a Checkly Enterprise contract, your checks' base cost might differ substantially from what is shown above.
 
+> API, TCP, and Multistep checks all count towards the 'API & network' check run quota. For example, if your plan includes 100k API & network check runs, running any of those three check types will contribute to that 100k limit.
+
 When configuring your check frequency and scheduling strategy, the cost helper will estimate the monthly cost for the check.
 
 ![cost helper widget](/docs/images/monitoring/price-helper.png)

site/content/docs/tcp-checks/_index.md

@@ -10,50 +10,100 @@ slug: /
 
 ---
 
-## Overview
-
-A TCP check establishes a connection to a specified hostname or IP address and port to verify responsiveness. These checks are ideal for monitoring non-HTTP services critical to your infrastructure. Here are a few example use cases:
-
-* **Mail servers** (e.g. `mail.example.org:993`): Use TCP checks to ensure your mail server is online and processing requests efficiently. For example, set an assertion on the response time to confirm the server accepts IMAPS connections without delays. This helps you spot slowdowns and provide reliable email services for your users.
-
-* **FTP servers** (e.g. `ftp.example.org:21`): Check that your server is online and accepting connections. To confirm that protocol commands are processed as expected, you can include a command like `USER anonymous\r\n` as part of your TCP request and confirm the response matches what you'd expect, such as `331 Please specify the password`, using assertions.
-
-* **Firewalls** (e.g. `firewall-protected.example.org:8080`): TCP checks allow you to confirm your firewall rules are working as expected. For example, if you want to verify that a specific port is intentionally blocked, enable the “should fail” option. This will mark the check as passed if the connection fails (e.g. due to a timeout or refusal), confirming that your firewall is doing its job.
-
-There are plenty of other scenarios where TCP checks are helpful, such as monitoring messaging queues or custom applications on proprietary ports. If you’re unsure whether your use case is supported or need assistance getting started, feel free to [reach out](mailto:support@checklyhq.com)!
-
-## Create a TCP check
-
-* **Create a check:** Click the `+` icon on the sidebar and select **TCP check** from the list. This will open the check creation page.
-
-* **Name & tags:** On the check creation page, choose a meaningful name for the check to easily identify it. Optionally, add one or more tags to further categorize or group the check.
-
-* **The TCP request:**
-  * **Target:** Specify the TCP endpoint to monitor by entering a hostname or IP address (e.g. tcpbin.com or 192.168.1.1) and a port (e.g. 4242).
-  * **IP family:** Change the [IP family](/docs/monitoring/ip-info/#ipv4-and-ipv6-support) setting to IPv6 if needed; the default is IPv4.
-  * **This request should fail:** Enable this option to mark failed connections as passed. Please note that failing assertions will still cause the check to fail.
-  * **Data to send:** Use the text editor to specify data that will be sent to the port as part of the TCP request. This can include text or protocol-specific commands expected by the target service. To configure the expected response, see ‘Assertions‘ for more details.
-
-* **Set response time limits:** Define thresholds for marking the check as degraded or failed. This allows you to specify when requests should be considered slow (degraded) or entirely unreachable (failed).
-
-* **Assertions:** Set conditions for a successful check. You can set a ‘response time‘ for the TCP request or specify the expected ‘response data‘ in the server’s reply.
-
-* **Scheduling strategy & locations:** Choose a [scheduling strategy](/docs/monitoring/global-locations#scheduling-strategies) and which [location](/docs/monitoring/global-locations) you would like to run your TCP check from.
-
-* **Scheduling:** Schedule your checks to run at intervals between 10 seconds (minimum) and 24 hours (maximum).
-
-* **Retries & alerting:** Configure [retries & alerts](/docs/alerting-and-retries) by choosing from Checkly's retry strategies and alert channels, ensuring you’re notified through your preferred methods when an issue arises with one of your TCP checks.
-
-## Update or delete a TCP check
-
-* **Update a TCP check:** To update a TCP check, click the kebab menu (three dots) next to the check on your [main dashboard](https://app.checklyhq.com) and select `Edit`, or click `Edit` in the top-right corner of the check's Reporting page.
-
-* **Delete a TCP check:** To delete a TCP check, use the kebab menu (three dots) on the [main dashboard](https://app.checklyhq.com) and select `Delete`. Alternatively click `Edit` in the top-right corner of the check's Reporting page, scroll to the bottom section, and click the `Delete` button.
-
-## TCP check reporting
-
-Learn more about analyzing your TCP check run results in our [check results documentation](/docs/monitoring/check-results#tcp-check-results).
-
-## TCP check pricing
-
-TCP checks are billed at $2 per 10k runs. They share a quota with API checks, allowing you to allocate your budget flexibly between both types. For detailed pricing information, see ‘API & network checks’ on our [pricing & billing page](/docs/monitoring/check-pricing/#pricing--billing---checkly-docs).
+Use TCP checks to verify that your critical non-HTTP services are working properly. TCP checks work by establishing a connection to a host and port, then checking the speed and validity of the response.
+
+For example, use these checks to verify that:
+
+* Your mail server is online and responds to IMAPS requests quickly.
+* Your FTP server responds correctly to commands.
+* Your firewall blocks access to certain ports.
+
+![Screenshot of the TCP check overview page](/docs/images/tcp-checks/tcp-check-overview.png)
+
+You can also monitor services like databases, message queues, custom applications, and more. If your service is unresponsive or fails assertions, the check will trigger any configured [alerts](/docs/alerting-and-retries/).
+
+## Configuring a TCP check
+
+![Screenshot of the TCP check create page](/docs/images/tcp-checks/create-tcp-check.png)
+
+The main part of your check is the TCP request, which defines the endpoint to monitor.
+
+* **Target:** The TCP endpoint to monitor, as defined by a hostname or IP address (e.g. `tcpbin.com` or `192.168.1.1`) and a port (e.g. `4242`).
+* **IP family:** The default is IPv4. If needed, change the [IP family](/docs/monitoring/ip-info/#ipv4-and-ipv6-support) setting to IPv6.
+* **This request should fail:** Enable this option to mark failed connections as passed. Please note that failing assertions will still cause the check to fail.
+* **Data to send:** The content included in the TCP request. For example, this could be text or protocol-specific commands expected by the target service.
+
+To validate the response, you can set:
+
+* **Response time limits**: The thresholds for marking the check as degraded or failed. This allows you to specify when responses should be considered slow (degraded) or entirely unreachable (failed).
+* **Assertions:** Additional conditions for a passing check, beyond just a successful connection. You can set a ‘response time‘ for the TCP request or specify the expected ‘response data‘ for the server’s reply. For example, you can assert that the response time is less than 200 ms. Or, given the command `USER anonymous\r\n`, you can assert that the response contains `331 Please specify the password`.
+
+Finally, here are generic check properties that apply to TCP checks:
+
+* **Name**: A meaningful name will not only help you and others identify your checks within Checkly, but it will help provide a better alerting experience if your checks fall into an alert state.
+* **Tags**: Useful for organizing and filtering your checks. They also determine which checks are included in your [dashboards](/docs/dashboards/) and [maintenance windows](/docs/maintenance-windows/).
+* **Scheduling strategy**: How checks with multiple locations are executed, i.e. parallel or round-robin. Learn more about these [scheduling strategies](/docs/monitoring/global-locations#scheduling-strategies).
+* **Locations**: Where your checks run from. Choose from our [public locations](/docs/monitoring/global-locations/), or use a Checkly Agent to host your own [private locations](/docs/private-locations/).
+* **Scheduling**: How often your checks run. Schedule your TCP checks to run at intervals between 10 seconds (minimum) and 24 hours (maximum).
+* **Retries**: How failed runs are retried. Learn more about the different [retry strategies](/docs/alerting-and-retries/retries/).
+* **Alerting**: This includes general [alert settings](/docs/alerting-and-retries/alert-settings/), like when and how often you're alerted, and the [alert channels](/docs/alerting-and-retries/alert-channels/) we use to notify you. If we don't have your preferred alert channel, use [webhooks](/docs/alerting-and-retries/webhooks/) to configure your alert flow.
+
+## CLI example
+
+The [Checkly CLI](/docs/cli/) gives you a JavaScript/TypeScript-native workflow for coding, testing and deploying synthetic monitoring at scale, from your code base.
+
+You can define a TCP check via the CLI. For example:
+
+{{< tabs "CLI example" >}}
+{{< tab "TypeScript" >}}
+```ts {title="hello-tcp.check.ts"}
+import { TcpCheck, TcpAssertionBuilder } from 'checkly/constructs'
+
+new TcpCheck('hello-tcp-1', {
+  name: 'Hello TCP',
+  activated: true,
+  request: {
+    hostname: 'tcpbin.com',
+    port: 4242,
+    data: 'ping\n',
+    ipFamily: 'IPv6',
+    assertions: [
+        TcpAssertionBuilder.responseData().contains('ping')
+    ]
+  }
+})
+```
+{{< /tab >}}
+{{< tab "JavaScript" >}}
+```js {title="hello-tcp.check.js"}
+const { TcpCheck, TcpAssertionBuilder } = require('checkly/constructs')
+
+new TcpCheck('hello-tcp-1', {
+  name: 'Hello TCP',
+  activated: true,
+  request: {
+    hostname: 'tcpbin.com',
+    port: 4242,
+    data: 'ping\n',
+    ipFamily: 'IPv6',
+    assertions: [
+        TcpAssertionBuilder.responseData().contains('ping')
+    ]
+  }
+})
+```
+{{< /tab >}}
+{{< /tabs >}}
+
+The above example defines:
+- The basic check properties like `name`, `activated` etc.
+- The `hostname` and `port` of the request, and the `data` to send.
+- An array of assertions to assert the response is correct.
+
+For more options, see the [Check construct reference](/docs/cli/constructs-reference/#check).
+
+## Next steps
+
+- Learn about the benefits of [Monitoring as Code](/guides/monitoring-as-code/).
+- Analyze your [TCP check run results](/docs/monitoring/check-results#tcp-check-results).
+- Understand [pricing and billing](/docs/monitoring/check-pricing/#pricing--billing---checkly-docs) for TCP checks.