checkly · sujaya-sys · Jan 27, 2026 · Feb 17, 2026 · Feb 17, 2026 · Feb 17, 2026
diff --git a/communicate/dashboards/overview.mdx b/communicate/dashboards/overview.mdx
@@ -26,7 +26,7 @@ Dashboards provide a detailed way to communicate the status of your checks and m
 Dashboards allow you to do the following:
 
 - Show the status of all your checks, or a subset by filtering by `tag`.
-- Show the availability and p95 / p99 response times over the last 24 hours, 7 days and 30 days.
+- Show the availability and p95 / p99 metrics over the last 24 hours, 7 days and 30 days.
 - Communicate custom incident messages and maintenance messages.
 
 You can create multiple, distinct dashboards based on your plan. Edit your dashboard by clicking on
@@ -35,10 +35,15 @@ the **Dashboards** button on the Checkly dashboard page.
 *Check out our [Checkly Production Dashboard](https://status.checkly-dashboards.com) for a live example* 
 
 ## Available metrics
-Dashboards show the following metrics for each check or monitor:
 
-| Metric | Time Period | Description |
-|--------|-------------|-------------|
-| **Availability** | 24h, 7d, 30d | Percentage of successful run results |
-| **P95** | 24h, 7d, 30d | 95th percentile response time |
-| **P99** | 24h, 7d, 30d | 99th percentile response time |
+Dashboards show the following metrics, depending on the check type:
+
+| Metric | Description | Supported check types |
+|--------|-------------|----------------------|
+| **Availability** | Percentage of successful runs | All check types |
+| **P95** | 95th percentile response time | All check types except Heartbeat & ICMP |
+| **P99** | 99th percentile response time | All check types except Heartbeat & ICMP |
+| **P95 Latency** | 95th percentile ping latency | ICMP |
+| **P95 Loss** | 95th percentile packet loss | ICMP |
+
+Metrics can be viewed over 1h, 3h, 24h, 7d, or 30d, based on your selected time range.
diff --git a/concepts/checks.mdx b/concepts/checks.mdx
@@ -49,6 +49,15 @@ Verify DNS resolution by querying domain records and validating responses. DNS M
 - DNS record validation
 - Detecting propagation issues
 - Troubleshooting resolver performance
+</Accordion>
+<Accordion title="ICMP Monitor">
+Ping hosts to measure network reachability and latency. ICMP monitors help you verify that a server or device is online and understand network-level performance.
+
+**Perfect for:**
+- Host reachability checks
+- Network latency monitoring
+- Packet loss detection
+
 </Accordion>
 
 <Accordion title="API Checks">

diff --git a/concepts/metrics.mdx b/concepts/metrics.mdx
@@ -109,7 +109,7 @@ Success rate metrics measure the reliability and availability of your services.
 
 **Unit:** Percentage (0-100%)  
 **Precision:** 2 decimal places  
-**Available for:** API, Browser, Heartbeat, TCP, Multistep, URL checks
+**Available for:** API, Browser, Heartbeat, ICMP, TCP, Multistep, URL checks
 
 <Accordion title="Use cases">
 - SLA compliance monitoring
@@ -124,7 +124,7 @@ Success rate metrics measure the reliability and availability of your services.
 
 **Unit:** Percentage (0-100%)  
 **Precision:** 2 decimal places  
-**Available for:** API, Browser, Heartbeat, TCP, Multistep, URL checks
+**Available for:** API, Browser, Heartbeat, ICMP, TCP, Multistep, URL checks
 
 <Accordion title="Use cases">
 - Error monitoring and alerting
@@ -137,8 +137,8 @@ Success rate metrics measure the reliability and availability of your services.
 
 **What it measures:** The total number of check executions performed during the selected time period.
 
-**Unit:** Count  
-**Available for:** API, Browser, Heartbeat, TCP, Multistep, URL checks
+**Unit:** Count    
+**Available for:** API, Browser, Heartbeat, ICMP, TCP, Multistep, URL checks
 
 <Accordion title="Use cases">
 - Volume analysis and capacity planning
@@ -151,8 +151,8 @@ Success rate metrics measure the reliability and availability of your services.
 
 **What it measures:** The total number of check executions that completed successfully according to the defined success criteria.
 
-**Unit:** Count  
-**Available for:** API, Browser, Heartbeat, TCP, Multistep, URL checks
+**Unit:** Count
+**Available for:** API, Browser, Heartbeat, ICMP, TCP, Multistep, URL checks
 
 <Accordion title="Use cases">
 - Availability reporting
@@ -166,7 +166,7 @@ Success rate metrics measure the reliability and availability of your services.
 **What it measures:** The total number of check executions that failed to meet the defined success criteria.
 
 **Unit:** Count  
-**Available for:** API, Browser, Heartbeat, TCP, Multistep, URL checks
+**Available for:** API, Browser, Heartbeat, ICMP, TCP, Multistep, URL checks
 
 <Accordion title="Use cases">
 - Error analysis and troubleshooting
@@ -378,6 +378,86 @@ These metrics are specific to heartbeat checks, which monitor the availability a
 - Setting performance benchmarks
 </Accordion>
 
+## ICMP-Specific Metrics
+
+These metrics are specific to ICMP monitors, which verify host reachability and measure network performance using ICMP Echo Requests (pings).
+
+### Average Ping Latency
+
+**What it measures:** The average round-trip time (RTT) across all received ICMP Echo Reply packets within a check run.
+
+**Unit:** Milliseconds
+
+<Accordion title="Use cases">
+- Establishing network latency baselines
+- Detecting latency degradation over time
+- Comparing latency across regions
+</Accordion>
+
+### Minimum Ping Latency
+
+**What it measures:** The fastest round-trip time recorded across all received packets within a check run.
+
+**Unit:** Milliseconds
+
+<Accordion title="Use cases">
+- Understanding best-case network performance
+</Accordion>
+
+### Maximum Ping Latency
+
+**What it measures:** The slowest round-trip time recorded across all received packets within a check run.
+
+**Unit:** Milliseconds
+
+<Accordion title="Use cases">
+- Identifying latency spikes
+- Setting timeout and alerting thresholds
+</Accordion>
+
+### Ping Latency Standard Deviation
+
+**What it measures:** The variability of round-trip times across all received packets within a check run. Higher values indicate less consistent network performance (jitter).
+
+**Unit:** Milliseconds
+
+<Accordion title="Use cases">
+- Measuring network stability and jitter
+</Accordion>
+
+### Packet Loss
+
+**What it measures:** The percentage of ICMP Echo Request packets that did not receive a reply.
+
+**Unit:** Percentage (0-100%)
+
+<Accordion title="Use cases">
+- Detecting network degradation
+- Triggering degraded or failed states via [packet loss thresholds](/detect/uptime-monitoring/icmp-monitors/configuration#packet-loss-limits)
+</Accordion>
+
+### P95 Ping Latency
+
+**What it measures:** The 95th percentile of average ping latency across check runs within the selected time period.
+
+**Unit:** Milliseconds
+
+<Accordion title="Use cases">
+- SLA monitoring for network latency
+- Filtering out outlier spikes for a realistic performance view
+</Accordion>
+
+### P95 Packet Loss
+
+**What it measures:** The 95th percentile of packet loss across check runs within the selected time period.
+
+**Unit:** Percentage (0-100%)
+
+<Accordion title="Use cases">
+- SLA monitoring for packet delivery
+- Identifying persistent vs. intermittent packet loss
+</Accordion>
+
 ## Additional Metrics by Check Type
 
 ### TCP Connection Time
@@ -400,7 +480,7 @@ These metrics are specific to heartbeat checks, which monitor the availability a
 **What it measures:** The time required to resolve the hostname to an IP address via DNS lookup.
 
 **Unit:** Milliseconds  
-**Precision:** 2 decimal places  
+**Precision:** 2 decimal places
 **Available for:** API, Browser, URL, TCP, DNS, ICMP checks (when hostname is used)
 
 <Accordion title="Use cases">

diff --git a/concepts/results.mdx b/concepts/results.mdx
@@ -85,7 +85,8 @@ To learn more about the results shown for each check type, refer to the document
 * [Multistep checks](/detect/synthetic-monitoring/multistep-checks/overview#multistep-check-results)
 * [Heartbeat monitors](/detect/uptime-monitoring/heartbeat-monitors/overview#heartbeat-monitor-results)
 * [TCP monitors](/detect/uptime-monitoring/tcp-monitors/overview#tcp-monitor-results)
-* [DNS monitors](/detect/uptime-monitoring/tcp-monitors/overview#dns-monitor-results)
+* [DNS monitors](/detect/uptime-monitoring/dns-monitors/overview#dns-monitor-results)
+* [ICMP monitors](/detect/uptime-monitoring/icmp-monitors/overview#icmp-monitor-results)
 * [URL monitors](/detect/uptime-monitoring/url-monitors/overview#url-monitor-results)
 
 ## Check results with retries

diff --git a/constructs/dns-monitor.mdx b/constructs/dns-monitor.mdx
@@ -171,7 +171,7 @@ To define `assertions` for the `request` of an `DnsMonitor` you should use the `
 - `responseTime()`: Assert the total response time of the DNS request in milliseconds. Use this to set thresholds for failed lookups
 - `responseCode()`: By default, DNS monitors pass when the return code is NOERROR and fail on error codes (FORMERR, SERVFAIL, NXDOMAIN, etc.). You can override this behavior by defining a custom return code assertion
 - `textAnswer()`: The raw DNS response as plain text. Use this to check for specific strings in the response
-- `jsonAnswer(property?)`: The DNS response in JSON format. This allows you to target specific fields using JSON path assertions. The response structure varies by record type. [Learn more about using JSON path](/detect/assertions/#json-responses-with-json-path).
+- `jsonAnswer(property?)`: The [DNS response in JSON format](/detect/uptime-monitoring/dns-monitors/configuration#json-response-schemas). This allows you to target specific fields using JSON path assertions. The response structure varies by record type. [Learn more about using JSON path](/detect/assertions/#json-responses-with-json-path).
 
 Here are some examples: