netdata · github-actions · Jul 21, 2026
diff --git a/docs/Alerts & Notifications/Notifications/Notifications.mdx b/docs/Alerts & Notifications/Notifications/Notifications.mdx
@@ -128,6 +128,15 @@ Netdata ships with hundreds of pre-configured alerts. You can also create your o
 - **[Alerts Configuration Manager](/docs/alerts-&-notifications/creating-alerts-with-the-alerts-configuration-manager)** — Visual UI wizard for creating and editing alerts
 - **[Manual configuration](/docs/alerts-&-notifications/alert-configuration-reference)** — Edit `health.d/*.conf` files directly for full control over alert syntax
 
+## On-Call Rotations and Escalation
+
+Netdata does not provide a native on-call rotation, escalation, or shift-scheduling engine. These capabilities are handled by the dedicated incident-management integrations that Netdata delivers alerts to.
+
+- **From the Agent:** incident-management and incident-response integrations such as [PagerDuty](/docs/alerts-&-notifications/notifications/agent-dispatched-notifications/pagerduty), [Opsgenie](/docs/alerts-&-notifications/notifications/agent-dispatched-notifications/opsgenie), [SIGNL4](/docs/alerts-&-notifications/notifications/agent-dispatched-notifications/signl4), and [ilert](/docs/alerts-&-notifications/notifications/agent-dispatched-notifications/ilert), where you define on-call schedules, escalation policies, and shift rotations. See the full list of [supported Agent integrations](https://learn.netdata.cloud/docs/alerts-&-notifications/notifications/agent-dispatched-notifications).
+- **From Cloud:** PagerDuty is available as a [paid-plan notification method](/docs/alerts-&-notifications/notifications/centralized-cloud-notifications/centralized-cloud-notifications-reference#service-classification).
+
+To use on-call rotations, configure one of these integrations to receive your Netdata alerts, then set up your rotations, escalation policies, and shift schedules inside that service. To change where alerts are sent, see [Notification Methods](#notification-methods) or the [Cloud notification methods](/docs/alerts-&-notifications/notifications/centralized-cloud-notifications/manage-notification-methods) guide.
+
 ## Next Steps
 
 - [Set up Cloud Notifications](/docs/alerts-&-notifications/notifications/centralized-cloud-notifications/centralized-cloud-notifications-reference)

diff --git a/docs/Collecting Metrics/Collectors/Storage and Filesystems/SMB Server Shares.mdx b/docs/Collecting Metrics/Collectors/Storage and Filesystems/SMB Server Shares.mdx
@@ -43,7 +43,7 @@ This collector only supports collecting metrics from a single instance of this i
 
 #### Auto-Detection
 
-This collector is disabled by default. When enabled, it automatically detects all available SMB share instances and metrics.
+This collector is enabled by default and automatically detects all available SMB share instances and metrics. On systems where the 'SMB Server Shares' object is not available, no SMB metrics are collected.
 
 
 #### Limits

diff --git a/docs/Collecting Metrics/StatsD.mdx b/docs/Collecting Metrics/StatsD.mdx
@@ -345,6 +345,40 @@ This structure allows for flexible and powerful metric configuration within Netd
 - **`update every (flushInterval) = 1s`** - How often StatsD updates Netdata charts
 - **`decimal detail = 1000`** - Controls decimal precision in gauges and histograms
 
+### Accepting metrics from another machine (LAN/remote host)
+
+By default, Netdata's StatsD listener binds only to `localhost`, so it accepts metrics from applications running on the **same machine** as the Netdata Agent. To accept metrics from another machine on your network, change the `bind to` setting in the `[statsd]` section of `netdata.conf`.
+
+1. Open the StatsD configuration:
+
+   ```bash
+   sudo ./edit-config netdata.conf
+   ```
+
+2. In the `[statsd]` section, set `bind to` to the Netdata host's LAN IP address (for example, `192.168.1.10`):
+
+   ```
+   [statsd]
+   	bind to = udp:192.168.1.10:8125 tcp:192.168.1.10:8125
+   ```
+
+   To listen on all interfaces instead of a single IP, bind to `0.0.0.0`:
+
+   ```
+   [statsd]
+   	bind to = udp:0.0.0.0:8125 tcp:0.0.0.0:8125
+   ```
+
+3. [Restart](/docs/netdata-agent/maintenance/service-control) the Agent so the new binding takes effect.
+
+4. On the sending machine, point your application's StatsD client at the Netdata host's IP address and port `8125`, using either UDP or TCP. For client library examples, see [Using StatsD with Different Languages](#using-statsd-with-different-languages).
+
+:::warning
+
+Binding `bind to` to `0.0.0.0` or a routable network interface exposes port `8125` to other hosts on the network. Restrict access with a firewall that only allows connections from your trusted machines, and avoid binding to public-facing interfaces.
+
+:::
+
 ## StatsD Charts
 
 Netdata can visualize StatsD collected metrics in two ways:

diff --git a/docs/Dashboards and Charts/Charts.mdx b/docs/Dashboards and Charts/Charts.mdx
@@ -78,11 +78,14 @@ A **context** groups charts by metric type and displayed dimensions. Contexts de
 
 - `apps.cpu` for **Apps CPU Time**
 - `apps.mem` for **Apps Real Memory**
+- `net.net` for **network Bandwidth**
 
 The part before the dot (`.`) is the **type**, while the part after is defined by the chart’s developer or its family.
 
 Contexts are also used for alert configurations.
 
+The contexts available on any given node depend on which collectors are enabled and what hardware and software Netdata detects, so there is no fixed universal list. To discover the contexts on your own system, browse the [Metrics tab](/docs/dashboards-and-charts/tabs/metrics) — charts there are grouped into sections by context — open the **Chart info** dialog on any chart to see its context value, or query the `/api/v3/contexts` endpoint programmatically. Each collector documents the metrics and contexts it produces on its integration page, which you can browse through the **Integrations tab** in the dashboard.
+
 ### Families
 
 A **family** represents a specific instance of a hardware or software resource that needs its own chart.
@@ -187,12 +190,12 @@ The **Group by** dropdown allows you to apply different grouping strategies on t
 
 ![Group by dropdown](https://user-images.githubusercontent.com/43294513/235468819-3af5a1d3-8619-48fb-a8b7-8e8b4cf6a8ff.png)
 
-| Grouping Option    | Description                                                |
-|--------------------|------------------------------------------------------------|
+| Grouping Option    | Description                                                                                               |
+|--------------------|-----------------------------------------------------------------------------------------------------------|
 | Group by Node      | Display each node (hostname) as a separate labeled dimension in the chart legend, with one entry per node |
-| Group by Instance  | Summarize data by instance with one dimension per instance |
-| Group by Dimension | Aggregate data across all nodes by dimension               |
-| Group by Label     | Summarize data based on label values                       |
+| Group by Instance  | Summarize data by instance with one dimension per instance                                                |
+| Group by Dimension | Aggregate data across all nodes by dimension                                                              |
+| Group by Label     | Summarize data based on label values                                                                      |
 
 :::tip
 
@@ -229,11 +232,11 @@ Each chart has a default aggregation function, which you can adjust as needed:
 
 When selecting aggregation functions over time, charts may offer dropdown menus for **Percentiles** and **Trimmed Mean / Median** selection. Below are examples of these dropdowns:
 
-### Percentile Selection Example:
+### Percentile Selection Example
 
 ![Percentile selection dropdown](https://user-images.githubusercontent.com/70198089/236410299-de5f3367-f3b0-4beb-a73f-a49007c543d4.png)
 
-### Trimmed Mean / Median Selection Example:
+### Trimmed Mean / Median Selection Example
 
 ![Trimmed Mean or Median selection dropdown](https://user-images.githubusercontent.com/70198089/236410858-74b46af9-280a-4ab2-ad26-5a6aa9403aa8.png)
 

diff --git a/docs/Developer and Contributor Corner/Database Engine.mdx b/docs/Developer and Contributor Corner/Database Engine.mdx
@@ -127,6 +127,8 @@ data from lower tiers, so that the aggregation they provide will be accurate.
 Configuring how the number of tiers and the disk space allocated to each tier is how you can
 [change how long netdata stores metrics](/docs/netdata-agent/configuration/database#tiers).
 
+For how `update every` controls each tier's granularity and interacts with retention time and disk size, see [Update Every and Tier Granularity](/docs/netdata-agent/configuration/database#update-every-and-tier-granularity).
+
 ### Data loss
 
 Until **hot pages** and **dirty pages** are **flushed** to disk, they are at risk (e.g., due to a crash, or

diff --git a/docs/Netdata Agent/Configuration/Database.mdx b/docs/Netdata Agent/Configuration/Database.mdx
@@ -76,6 +76,21 @@ You can change these limits using [`edit-config`](/docs/netdata-agent/configurat
     dbengine tier 2 retention time = 2y
 ```
 
+### Update Every and Tier Granularity
+
+`[db].update every` sets the base data collection interval. Tier 0 stores data at this interval, and every higher tier derives its granularity by multiplying from the tier below it. The per-tier multiplier is `dbengine tier X update every iterations` (`60` by default for each tier above 0), so the effective resolution of a tier is `update every` multiplied by every multiplier below it:
+
+| `update every` | Tier 0 | Tier 1 (`×60`) | Tier 2 (`×60×60`) |
+|:--------------:|:------:|:--------------:|:-----------------:|
+| `1s` (default) | 1s     | 60s            | 3600s (1 hour)    |
+| `5s`           | 5s     | 300s           | 18000s (5 hours)  |
+
+Changing `update every` shifts the resolution of every tier proportionally, but the per-tier **retention time** limits (`dbengine tier X retention time`) are wall-clock durations and do **not** change automatically — you do not need to lower retention when you raise `update every`.
+
+Because a longer `update every` collects fewer samples per unit of time, the same per-tier disk size holds more time of data, so you may optionally reduce `dbengine tier X retention size`. For the full disk-sizing implications, see [Disk Requirements & Retention](/docs/netdata-agent/resource-utilization/disk-&-retention).
+
+In a Parent-Child setup, each Child streams its own `update every` to the Parent. The Parent stores that Child's metrics at the Child's collection interval, so a Child's `update every` affects only that Child's data granularity on the Parent. The Parent's `[db].update every` applies only to metrics the Parent collects locally.
+
 ### Legacy Configuration
 
 <details>

diff --git a/docs/Netdata Agent/Resource Utilization/Disk & Retention.mdx b/docs/Netdata Agent/Resource Utilization/Disk & Retention.mdx
@@ -49,6 +49,12 @@ gantt
 | `tier1` | 60 iterations of `tier0`, so when metrics are collected per-second, this tier is per-minute. |         16 bytes         |     6 bytes     |
 | `tier2` |  60 iterations of `tier1`, so when metrics are collected per second, this tier is per-hour.  |         16 bytes         |    18 bytes     |
 
+:::note
+
+Tier resolution shifts proportionally when you change `[db].update every`, and a longer `update every` lets the same per-tier disk size hold more time of data. See [Update Every and Tier Granularity](/docs/netdata-agent/configuration/database#update-every-and-tier-granularity) for the full mechanics and the Parent-Child behavior.
+
+:::
+
 ### Default Disk Footprint
 
 Netdata Agent metrics storage is limited to 3 GiB by default (configurable), using 1 GiB per tier × 3 tiers. In total, with SQLite databases, alert transitions, and other metadata, expect about 4 GiB of disk usage under normal conditions. The default retention limits are: