Merge pull request #246 from checkly/paula/docs-check-description

pmallol · web-flow · commit 0e7df9fba268 · 2026-04-06T15:58:13.000+02:00
docs(constructs): add check description property [TREE-735] [show]
diff --git a/ai/rocky-ai.mdx b/ai/rocky-ai.mdx
@@ -5,7 +5,7 @@ sidebarTitle: Rocky AI
 ---
 
 Rocky AI is Checkly's AI agent. Rocky AI can help you automatically determine user impact and root cause on any failing
-check using error messages, code, metrics, traces and logs.
+check using error messages, code, check descriptions, metrics, traces and logs.
 
 ## Rocky AI Capabilities
 ### Root Cause & User Impact Analysis
diff --git a/detect/synthetic-monitoring/api-checks/configuration.mdx b/detect/synthetic-monitoring/api-checks/configuration.mdx
@@ -212,4 +212,12 @@ This list shows all content types that we scrub from the response data.
 |`video/x-ms-wmv`|
 |`video/x-msvideo`|
 |`video/x-flv`|
-|`video/webm`|
+|`video/webm`|
+
+## Additional Settings
+
+* **Name:** Give your check a clear name to identify it in dashboards and alerts
+* **Description:** Add context about what this check does and why it matters. Supports markdown, max 500 characters. When a failure occurs, [Rocky AI](/ai/rocky-ai) uses the description to provide more accurate [root cause and user impact analysis](/resolve/ai-root-cause-analysis/overview)
+* **Tags:** Use tags to organize checks across [dashboards](/communicate/dashboards/overview/) and [maintenance windows](/communicate/maintenance-windows/overview)
+* **Retries:** Define how failed runs should be retried. See [retry strategies](/communicate/alerts/retries)
+* **Alerting:** Configure your [alert settings](/communicate/alerts/configuration), [alert channels](/communicate/alerts/channels), or set up [webhooks](/integrations/alerts/webhooks) for custom integrations
diff --git a/detect/uptime-monitoring/dns-monitors/configuration.mdx b/detect/uptime-monitoring/dns-monitors/configuration.mdx
@@ -323,6 +323,7 @@ Set how often the monitor runs (every 10 seconds to 24 hours):
 ### Additional Settings
 
 * **Name:** Give your monitor a clear name to identify it in dashboards and alerts
+* **Description:** Add context about what this monitor does and why it matters. Supports markdown, max 500 characters. When a failure occurs, [Rocky AI](/ai/rocky-ai) uses the description to provide more accurate [root cause and user impact analysis](/resolve/ai-root-cause-analysis/overview)
 * **Tags:** Use tags to organize monitors across [dashboards](/communicate/dashboards/overview/) and [maintenance windows](/communicate/maintenance-windows/overview)
 * **Retries:** Define how failed runs should be retried. See [retry strategies](/communicate/alerts/retries)
 * **Alerting:** Configure your [alert settings](/communicate/alerts/configuration), [alert channels](/communicate/alerts/channels), or set up [webhooks](/integrations/alerts/webhooks) for custom integrations
diff --git a/detect/uptime-monitoring/heartbeat-monitors/configuration.mdx b/detect/uptime-monitoring/heartbeat-monitors/configuration.mdx
@@ -2,4 +2,12 @@
 title: Heartbeat Configuration
 description:  Ensure your critical automated processes are running as expected.
 sidebarTitle: Configuration
----
+---
+
+### Additional Settings
+
+* **Name:** Give your monitor a clear name to identify it in dashboards and alerts
+* **Description:** Add context about what this monitor does and why it matters. Supports markdown, max 500 characters. When a failure occurs, [Rocky AI](/ai/rocky-ai) uses the description to provide more accurate [root cause and user impact analysis](/resolve/ai-root-cause-analysis/overview)
+* **Tags:** Use tags to organize monitors across [dashboards](/communicate/dashboards/overview/) and [maintenance windows](/communicate/maintenance-windows/overview)
+* **Retries:** Define how failed runs should be retried. See [retry strategies](/communicate/alerts/retries)
+* **Alerting:** Configure your [alert settings](/communicate/alerts/configuration), [alert channels](/communicate/alerts/channels), or set up [webhooks](/integrations/alerts/webhooks) for custom integrations
diff --git a/detect/uptime-monitoring/icmp-monitors/configuration.mdx b/detect/uptime-monitoring/icmp-monitors/configuration.mdx
@@ -101,6 +101,7 @@ Set how often the monitor runs (every 10 seconds to 24 hours):
 ### Additional Settings
 
 * **Name:** Give your monitor a clear name to identify it in dashboards and alerts
+* **Description:** Add context about what this monitor does and why it matters. Supports markdown, max 500 characters. When a failure occurs, [Rocky AI](/ai/rocky-ai) uses the description to provide more accurate [root cause and user impact analysis](/resolve/ai-root-cause-analysis/overview)
 * **Tags:** Use tags to organize monitors across [dashboards](/communicate/dashboards/overview/) and [maintenance windows](/communicate/maintenance-windows/overview)
 * **Retries:** Define how failed runs should be retried. See [retry strategies](/communicate/alerts/retries)
 * **Alerting:** Configure your [alert settings](/communicate/alerts/configuration), [alert channels](/communicate/alerts/channels), or set up [webhooks](/integrations/alerts/webhooks) for custom integrations
diff --git a/detect/uptime-monitoring/tcp-monitors/configuration.mdx b/detect/uptime-monitoring/tcp-monitors/configuration.mdx
@@ -65,6 +65,7 @@ Set how often the monitor runs (every 10 seconds to 24 hours):
 ### Additional Settings
 
 * **Name:** Give your monitor a clear name to identify it in dashboards and alerts
+* **Description:** Add context about what this monitor does and why it matters. Supports markdown, max 500 characters. When a failure occurs, [Rocky AI](/ai/rocky-ai) uses the description to provide more accurate [root cause and user impact analysis](/resolve/ai-root-cause-analysis/overview)
 * **Tags:** Use tags to organize monitors across dashboards and [maintenance windows](/communicate/maintenance-windows/overview)
 * **Retries:** Define how failed runs should be retried. See [retry strategies](/communicate/alerts/retries)
 * **Alerting:** Configure your [alert settings](/communicate/alerts/configuration), [alert channels](/communicate/alerts/channels), or set up [webhooks](/integrations/alerts/webhooks) for custom integrations
diff --git a/detect/uptime-monitoring/url-monitors/configuration.mdx b/detect/uptime-monitoring/url-monitors/configuration.mdx
@@ -139,6 +139,12 @@ Define where notifications are sent when checks fail or recover. Additional chan
 **Global Alert Settings**: By default, monitors inherit your account's notification preferences. Select "Use specific notification settings" to customize alerts for individual monitors.
 </Note>
 
+### Additional Settings
+
+* **Name:** Give your monitor a clear name to identify it in dashboards and alerts
+* **Description:** Add context about what this monitor does and why it matters. Supports markdown, max 500 characters. When a failure occurs, [Rocky AI](/ai/rocky-ai) uses the description to provide more accurate [root cause and user impact analysis](/resolve/ai-root-cause-analysis/overview)
+* **Tags:** Use tags to organize monitors across [dashboards](/communicate/dashboards/overview/) and [maintenance windows](/communicate/maintenance-windows/overview)
+
 
 
 
diff --git a/integrations/alerts/webhooks.mdx b/integrations/alerts/webhooks.mdx
@@ -44,6 +44,7 @@ You can use the following event-related variables in both URL and payload.
 | `API_CHECK_RESPONSE_STATUS_TEXT` | The response status text, e.g. "OK". Only populated for API checks.                                                                                                                |
 | `CHECK_ERROR_MESSAGE`            | The check error message                                                                                                                                                            |
 | `CHECK_ID`                       | The UUID of the check                                                                                                                                                              |
+| `CHECK_DESCRIPTION`              | The description of the check, if set                                                                                                                                               |
 | `CHECK_NAME`                     | Full name of the check                                                                                                                                                             |
 | `CHECK_RESULT_ID`                | The UUID of the result that triggered this message                                                                                                                                 |
 | `CHECK_TYPE`                     | The check type, e.g. API, BROWSER  .                                                                                                                                               |
diff --git a/quickstarts/api-check.mdx b/quickstarts/api-check.mdx
@@ -10,12 +10,15 @@ Learn more about all the [API Check capabilities](/detect/synthetic-monitoring/a
 
 ![Screenshot of the create API check page](/images/docs/images/api-checks/overview-create-check.png)
 
-### Name and tags
+### Name, tags, and description
 
-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.
+* **Name:** A meaningful name helps you and your team quickly identify checks and improves the clarity of alerts when something fails
 
-Tags can relate your checks together. They also determine which checks are shown on your [dashboards](/dashboards/).
+* **Tags:** let you group related checks and control which ones appear on your [dashboards](/dashboards/)
 
+* **Descriptions:** add context about what a check does or why it exists
+
+Together, these fields improve alert clarity and play an important role in incident investigation. [Rocky AI](/resolve/ai-root-cause-analysis/overview) uses this information to provide more accurate root cause and user impact analysis.
 
 ### HTTP request
 
diff --git a/quickstarts/heartbeat-monitor.mdx b/quickstarts/heartbeat-monitor.mdx
@@ -34,7 +34,7 @@ Before creating your heartbeat monitor, make sure you have:
 
 ## Step 1: Basic Configuration
 
-Start by giving your monitor a descriptive name and relevant tags. Choose something descriptive that clearly identifies what the monitor is tracking, like "Nightly Database Backup" or "Weekly Reports Job".
+Start by giving your monitor a descriptive name and relevant tags and description. Choose something descriptive that clearly identifies what the monitor is tracking, like "Nightly Database Backup" or "Weekly Reports Job".
 
 Use tags to group related monitors and make them easier to find and manage.
 
diff --git a/quickstarts/multistep-check.mdx b/quickstarts/multistep-check.mdx
@@ -18,11 +18,15 @@ You'll need a series of API endpoints that work together to complete a business
 ![Multistep check edit page](/images/docs/images/multistep-api-checks/create-multistep-check.png)
 </Frame>
 
-### Name and tags
+### Name, tags, and description
 
-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.
+* **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 can relate your checks together. They also determine which checks are shown on your [dashboards](/dashboards/).
+* **Tags:** let you relate your checks together. They also determine which checks are shown on your [dashboards](/dashboards/)
+
+* **Descriptions:** add context about what a check does or why it exists
+
+Together, these fields improve alert clarity and play an important role in incident investigation. [Rocky AI](/resolve/ai-root-cause-analysis/overview) uses this information to provide more accurate root cause and user impact analysis.
 
 ### Playwright script
 
diff --git a/quickstarts/tcp-monitor.mdx b/quickstarts/tcp-monitor.mdx
@@ -68,6 +68,7 @@ Set how often the monitor runs (every 10 seconds to 24 hours):
 
 * **Name:** Give your monitor a clear name to identify it in dashboards and alerts
 * **Tags:** Use tags to organize monitors across dashboards and [maintenance windows](/communicate/maintenance-windows/overview)
+* **Description:** A description of the check. Supports Markdown. Maximum length: 500 characters
 * **Retries:** Define how failed runs should be retried. See [retry strategies](/communicate/alerts/retries)
 * **Alerting:** Configure your [alert settings](/communicate/alerts/configuration), [alert channels](/communicate/alerts/channels), or set up [webhooks](/integrations/alerts/webhooks) for custom integrations
 
diff --git a/quickstarts/url-monitor.mdx b/quickstarts/url-monitor.mdx
@@ -62,6 +62,7 @@ Set how often the monitor runs (every 10 seconds to 24 hours).
 
 * **Name:** Give your monitor a clear name to identify it in dashboards and alerts
 * **Tags:** Use tags to organize monitors across dashboards and [maintenance windows](/communicate/maintenance-windows/overview)
+* **Description:** A short description of the check. Supports Markdown. Maximum length: 500 characters
 * **Retries:** Define how failed runs should be retried. See [retry strategies](/communicate/alerts/retries)
 * **Alerting:** Configure your [alert settings](/communicate/alerts/configuration), [alert channels](/communicate/alerts/channels), or set up [webhooks](/integrations/alerts/webhooks) for custom integrations
 
diff --git a/resolve/ai-root-cause-analysis/overview.mdx b/resolve/ai-root-cause-analysis/overview.mdx
@@ -22,7 +22,7 @@ synthetic checks and / or monitoring checks.
   />
 </Frame>
 
-Using any available artifacts like error message, user code, logs, metrics, trace routes, packet captures, Playwright traces, screenshots
+Using any available artifacts like error message, user code, check description, logs, metrics, trace routes, packet captures, Playwright traces, screenshots
 and other evidence, it will quickly assess what the impact is of a failure and what the underlying (possible) root cause is.
 It will also provide a suggested code fix for any check based on (Playwright) code.
 
