IoT Edge and Ops freshness

Author: sethmanheim

articles/iot-edge/how-to-access-built-in-metrics.md

@@ -4,7 +4,7 @@ description: Access built-in metrics from IoT Edge runtime components to monitor
 #customer intent: As a system administrator, I want to access built-in metrics in Azure IoT Edge so that I can monitor and understand the health of my IoT Edge devices.  
 author: sethmanheim
 ms.author: sethm
-ms.date: 02/20/2026
+ms.date: 03/02/2026
 ms.topic: concept-article
 ms.service: azure-iot-edge
 services: iot-edge
@@ -18,9 +18,9 @@ The IoT Edge runtime components, IoT Edge hub, and IoT Edge agent, produce built
 
 Use your own solution to access these metrics, or use the [metrics-collector module](https://mcr.microsoft.com/artifact/mar/azureiotedge-metrics-collector/tags), which collects the built-in metrics and sends them to Azure Monitor or Azure IoT Hub. For more information, see [Collect and transport metrics](how-to-collect-and-transport-metrics.md).
 
-Metrics are exposed by default on **port 9600** of the **edgeHub** and **edgeAgent** modules (`http://edgeHub:9600/metrics` and `http://edgeAgent:9600/metrics`). They aren't mapped to the host by default.
+By default, the **edgeHub** and **edgeAgent** modules expose metrics on **port 9600** (`http://edgeHub:9600/metrics` and `http://edgeAgent:9600/metrics`). The metrics aren't mapped to the host by default.
 
-Access metrics from the host by exposing and mapping the metrics port in the module's `createOptions`. The following example maps the default metrics port to port 9601 on the host:
+To access metrics from the host, expose and map the metrics port in the module's `createOptions`. The following example maps the default metrics port to port 9601 on the host:
 
 ```json
 {
@@ -42,9 +42,9 @@ Access metrics from the host by exposing and mapping the metrics port in the mod
 Choose different and unique host port numbers when mapping both the edgeHub and edgeAgent metrics endpoints.
 
 > [!NOTE]
-> The environment variable `httpSettings__enabled` must not be set to `false` for built-in metrics to be available for collection.
+> You must set the environment variable `httpSettings__enabled` to `true` for collection of built-in metrics.
 >
-> Environment variables that can be used to disable metrics are listed in the [azure/iotedge repo doc](https://github.com/Azure/iotedge/blob/main/doc/EnvironmentVariables.md).
+> For more information about environment variables that can disable metrics, see the [azure/iotedge repo doc](https://github.com/Azure/iotedge/blob/main/doc/EnvironmentVariables.md).
 
 ## Available metrics
 
@@ -54,7 +54,7 @@ Metrics include tags that identify the nature of the metric being collected. All
 |-|-|
 | iothub | The hub the device communicates with |
 | edge_device | The ID of the current device |
-| instance_number | A GUID representing the current runtime. On restart, all metrics are reset. This GUID makes it easier to reconcile restarts. |
+| instance_number | A GUID representing the current runtime. On restart, all metrics reset. This GUID makes it easier to reconcile restarts. |
 
 The Prometheus exposition format includes four core metric types: counter, gauge, histogram, and summary. For more information about the different metric types, see the [Prometheus metric types documentation](https://prometheus.io/docs/concepts/metric_types/).
 
@@ -64,10 +64,10 @@ The **edgeHub** module generates the following metrics:
 
 | Name | Dimensions | Description |
 |-|-|-|
-| `edgehub_gettwin_total` | `source` (operation source)<br> `id` (module ID) | Type: counter<br> Total number of GetTwin calls |
-| `edgehub_messages_received_total` | `route_output` (output that sent message)<br> `id` | Type: counter<br> Total number of messages received from clients |
-| `edgehub_messages_sent_total` | `from` (message source)<br> `to` (message destination)<br>`from_route_output`<br> `to_route_input` (message destination input)<br> `priority` (message priority to destination) | Type: counter<br> Total number of messages sent to clients or upstream<br> `to_route_input` is empty when `to` is $upstream |
-| `edgehub_reported_properties_total` | `target`(update target)<br> `id` | Type: counter<br> Total reported property updates calls |
+| `edgehub_gettwin_total` | `source` (operation source)<br> `id` (module ID) | Type: counter<br> Total number of GetTwin calls. |
+| `edgehub_messages_received_total` | `route_output` (output that sent message)<br> `id` | Type: counter<br> Total number of messages received from clients. |
+| `edgehub_messages_sent_total` | `from` (message source)<br> `to` (message destination)<br>`from_route_output`<br> `to_route_input` (message destination input)<br> `priority` (message priority to destination) | Type: counter<br> Total number of messages sent to clients or upstream<br> `to_route_input` is empty when `to` is $upstream. |
+| `edgehub_reported_properties_total` | `target`(update target)<br> `id` | Type: counter<br> Total reported property updates calls. |
 | `edgehub_message_size_bytes` | `id`<br> | Type: summary<br> Message size from clients<br> Values might be reported as `NaN` if no new measurements are reported for 10 minutes. For the `summary` type, corresponding `_count` and `_sum` counters are emitted. |
 | `edgehub_gettwin_duration_seconds` | `source` <br> `id` | Type: summary<br> Time taken for get twin operations |
 | `edgehub_message_send_duration_seconds` | `from`<br> `to`<br> `from_route_output`<br> `to_route_input` | Type: summary<br> Time taken to send a message |
@@ -106,13 +106,13 @@ The **edgeAgent** module generates the following metrics:
 | `edgeAgent_total_disk_space_bytes` | `disk_name`, `disk_filesystem`, `disk_filetype`| Type: gauge<br> Size of the disk |
 | `edgeAgent_used_memory_bytes` | `module_name` | Type: gauge<br> Amount of RAM used by all processes |
 | `edgeAgent_total_memory_bytes` | `module_name` | Type: gauge<br> RAM available |
-| `edgeAgent_used_cpu_percent` | `module_name` | Type: histogram<br> Percent of cpu used by all processes |
-| `edgeAgent_created_pids_total` | `module_name` | Type: gauge<br> The number of processes or threads the container has created |
+| `edgeAgent_used_cpu_percent` | `module_name` | Type: histogram<br> Percent of CPU used by all processes |
+| `edgeAgent_created_pids_total` | `module_name` | Type: gauge<br> The number of processes or threads the container creates |
 | `edgeAgent_total_network_in_bytes` | `module_name` | Type: gauge<br> The number of bytes received from the network |
 | `edgeAgent_total_network_out_bytes` | `module_name` | Type: gauge<br> The number of bytes sent to network |
 | `edgeAgent_total_disk_read_bytes` | `module_name` | Type: gauge<br> The number of bytes read from the disk |
 | `edgeAgent_total_disk_write_bytes` | `module_name` | Type: gauge<br> The number of bytes written to disk |
-| `edgeAgent_metadata` | `edge_agent_version`, `experimental_features`, `host_information` | Type: gauge<br> General metadata about the device. The value is always 0, and information is encoded in the tags. Note that `experimental_features` and `host_information` are JSON objects. `host_information` looks like ```{"OperatingSystemType": "linux", "Architecture": "x86_64", "Version": "1.2.7", "Provisioning": {"Type": "dps.tpm", "DynamicReprovisioning": false, "AlwaysReprovisionOnStartup": false}, "ServerVersion": "20.10.11+azure-3", "KernelVersion": "5.11.0-1027-azure", "OperatingSystem": "Ubuntu 20.04.4 LTS", "NumCpus": 2, "Virtualized": "yes"}```. Note `ServerVersion` is the Docker version and `Version` is the IoT Edge security daemon version. |
+| `edgeAgent_metadata` | `edge_agent_version`, `experimental_features`, `host_information` | Type: gauge<br> General metadata about the device. The value is always 0, and the tags encode the information. Note that `experimental_features` and `host_information` are JSON objects. `host_information` looks like ```{"OperatingSystemType": "linux", "Architecture": "x86_64", "Version": "1.2.7", "Provisioning": {"Type": "dps.tpm", "DynamicReprovisioning": false, "AlwaysReprovisionOnStartup": false}, "ServerVersion": "20.10.11+azure-3", "KernelVersion": "5.11.0-1027-azure", "OperatingSystem": "Ubuntu 20.04.4 LTS", "NumCpus": 2, "Virtualized": "yes"}```. Note `ServerVersion` is the Docker version and `Version` is the IoT Edge security daemon version. |
 
 ## Next steps
 

articles/iot-edge/offline-capabilities.md

@@ -3,7 +3,7 @@ title: Operate Azure IoT Edge devices offline
 description: Understand how IoT Edge devices can operate without internet connection for an extended time, and how to enable regular IoT devices to operate offline.
 author: sethmanheim
 ms.author: sethm
-ms.date: 06/04/2025
+ms.date: 03/02/2026
 ms.topic: concept-article
 ms.service: azure-iot-edge
 services: iot-edge
@@ -13,13 +13,13 @@ services: iot-edge
 
 [!INCLUDE [iot-edge-version-all-supported](includes/iot-edge-version-all-supported.md)]
 
-Azure IoT Edge lets your IoT Edge devices work offline for extended periods and lets downstream devices work offline too. After an IoT Edge device connects to IoT Hub once, the device and any downstream device can keep working with intermittent or no internet connection.
+Azure IoT Edge enables your IoT Edge devices to work offline for extended periods and enables downstream devices work offline too. After an IoT Edge device connects to IoT Hub once, the device and any downstream device can keep working with intermittent or no internet connection.
 
 ## How it works
 
 When an IoT Edge device goes into offline mode, the IoT Edge hub takes on three roles:
 
-* Stores any messages that goes upstream and saves them until the device reconnects.
+* Stores any messages that go upstream and saves them until the device reconnects.
 * Acts on behalf of IoT Hub to authenticate modules and downstream devices so they can keep operating.
 * Enables communication between downstream devices that normally go through IoT Hub.
 
@@ -29,32 +29,32 @@ The following example shows how an IoT Edge scenario operates in offline mode:
 
    IoT Edge devices have offline capabilities enabled by default. To extend this capability to other devices, configure downstream devices to trust their assigned parent device and route device-to-cloud communications through the parent as a gateway.
 
-2. **Sync with IoT Hub**
+1. **Sync with IoT Hub**
 
    After you install the IoT Edge runtime, make sure the IoT Edge device is online at least once to sync with IoT Hub. During this sync, the IoT Edge device gets details about any downstream devices assigned to it. The IoT Edge device also securely updates its local cache to enable offline operations and gets settings for local storage of telemetry messages.
 
-3. **Go offline**
+1. **Go offline**
 
    While disconnected from IoT Hub, the IoT Edge device, its deployed modules, and any downstream devices can keep operating indefinitely. Modules and downstream devices can start and restart by authenticating with the IoT Edge hub while offline. Device telemetry bound upstream to IoT Hub is stored locally. Communication between modules or between downstream devices is maintained through direct methods or messages.
 
-4. **Reconnect and resync with IoT Hub**
+1. **Reconnect and resync with IoT Hub**
 
-   When the connection with IoT Hub is restored, the IoT Edge device syncs again. Locally stored messages are delivered to IoT Hub right away, but delivery depends on the speed of the connection, IoT Hub latency, and related factors. Messages are delivered in the same order in which they were stored.
+   When the connection to IoT Hub is restored, the IoT Edge device syncs again. Locally stored messages are delivered to IoT Hub right away, but delivery depends on the speed of the connection, IoT Hub latency, and related factors. Messages are delivered in the same order in which they were stored.
 
    Any differences between the desired and reported properties of the modules and devices are reconciled. The IoT Edge device updates any changes to its set of assigned downstream devices.
 
 ## Restrictions and limits
 
-IoT Edge devices and their assigned downstream devices can function indefinitely offline after the initial, one-time sync. However, message storage depends on the [time to live (TTL) setting](#time-to-live) and available disk space.
+IoT Edge devices and their assigned downstream devices can function offline indefinitely after the initial, one-time sync. However, message storage depends on the [time to live (TTL) setting](#time-to-live) and available disk space.
 
-A device's *EdgeAgent* updates its reported properties whenever deployment status changes, like a new or failed deployment. When a device is offline, the *EdgeAgent* can't report status to the Azure portal. Therefore, the device status in the Azure portal can remain **200 OK** when the IoT Edge device has no internet connectivity.
+A device *EdgeAgent* updates its reported properties whenever deployment status changes, like a new or failed deployment. When a device is offline, the EdgeAgent can't report status to the Azure portal. Therefore, the device status in the Azure portal can remain **200 OK** when the IoT Edge device has no internet connectivity.
 
 ## Set up parent and child devices
 
 By default, a parent device can have up to 100 children. Change this limit by setting the **MaxConnectedClients** environment variable in the edgeHub module. A child device only has one parent.
 
->[!NOTE]
->A downstream device sends data directly to the internet or to gateway devices (IoT Edge-enabled or not). A child device can be a downstream device or a gateway device in a nested topology.
+> [!NOTE]
+> A downstream device sends data directly to the internet or to gateway devices (IoT Edge-enabled or not). A child device can be a downstream device or a gateway device in a nested topology.
 
 A downstream device can be any device, IoT Edge or non-IoT Edge, registered to the same IoT Hub.
 
@@ -86,7 +86,7 @@ For devices that can go offline for a long time, optimize performance by setting
 
 ### Time to live
 
-The *time to live* setting is how long (in seconds) a message waits to be delivered before it expires. The default is 7,200 seconds (two hours). The maximum value is limited by the maximum value of an integer variable, which is about 2 billion.
+The time to live setting is how long (in seconds) a message waits to be delivered before it expires. The default value is 7,200 seconds (two hours). The maximum value is limited by the maximum value of an integer variable, which is about 2 billion.
 
 This setting is a desired property of the IoT Edge hub, stored in the module twin. Configure it in the Azure portal or directly in the deployment manifest.
 
@@ -108,7 +108,7 @@ By default, the IoT Edge hub stores messages and module state in its local conta
 
 ## Next steps
 
-Learn more about how to set up a transparent gateway for your parent/child device connections:
+For more information about how to set up a transparent gateway for your parent and child device connections, see:
 
 * [Configure an IoT Edge device to act as a transparent gateway](how-to-create-transparent-gateway.md)
 * [Authenticate a downstream device to Azure IoT Hub](how-to-authenticate-downstream-device.md)