diff --git a/docs/CONFIGURATION.md b/docs/CONFIGURATION.md
index c87c6e233..bb4b42a37 100644
--- a/docs/CONFIGURATION.md
+++ b/docs/CONFIGURATION.md
@@ -261,7 +261,8 @@ The agent table configures Telegraf and the defaults used across all plugins.
 - **metric_buffer_limit**:
   Maximum number of unwritten metrics per output.  Increasing this value
   allows for longer periods of output downtime without dropping metrics at the
-  cost of higher maximum memory usage.
+  cost of higher maximum memory usage. Oldest metrics are overwritten in favor
+  of new ones when the buffer fills up.
 
 - **collection_jitter**:
   Collection jitter is used to jitter the collection by a random [interval][].
diff --git a/docs/specs/tsd-005-output-buffer-strategy.md b/docs/specs/tsd-005-output-buffer-strategy.md
index c2307d2a1..fbc5497f9 100644
--- a/docs/specs/tsd-005-output-buffer-strategy.md
+++ b/docs/specs/tsd-005-output-buffer-strategy.md
@@ -8,8 +8,8 @@ output plugin metric queues.
 ## Overview
 
 Currently, when a Telegraf output metric queue fills, either due to incoming
-metrics being too fast or various issues with writing to the output, new
-metrics are dropped and never written to the output. This specification
+metrics being too fast or various issues with writing to the output, oldest
+metrics are overwritten and never written to the output. This specification
 defines a set of options to make this output queue more durable by persisting
 pending metrics to disk rather than only an in-memory limited size queue.
 
@@ -33,10 +33,9 @@ memory only mode, retaining current behavior.
 
 ## Metric Ordering and Tracking
 
-Tracking metrics will be accepted either on a successful write to the output
-source like currently, or on write to the WAL file. Metrics will be written
-to their appropriate output in the order they are received in the buffer
-regardless of which buffer strategy is chosen.
+Tracking metrics will be accepted on a successful write to the output
+destination. Metrics will be written to their appropriate output in the order
+they are received in the buffer regardless of which buffer strategy is chosen.
 
 ## Disk Utilization and File Handling
 
@@ -49,7 +48,7 @@ WAL file as they are written to the output.
 
 Telegraf will not make any attempt to limit the size on disk taken by these
 files beyond cleaning up WAL files for metrics that have successfully been
-flushed to their output source. It is the user's responsibility to ensure
+flushed to their output destination. It is the user's responsibility to ensure
 these files do not entirely fill the disk, both during Telegraf uptime and
 with lingering files from previous instances of the program.
 
diff --git a/plugins/outputs/azure_monitor/README.md b/plugins/outputs/azure_monitor/README.md
index 9781a4365..cfdb1064a 100644
--- a/plugins/outputs/azure_monitor/README.md
+++ b/plugins/outputs/azure_monitor/README.md
@@ -14,6 +14,13 @@ is written as the Azure Monitor metric name. All field values are written as a
 summarized set that includes: min, max, sum, count. Tags are written as a
 dimension on each Azure Monitor metric.
 
+Note that Azure Monitor won’t accept metrics that are too far in the past
+or future. Keep this in mind when configuring your output buffer limits or other
+variables, such as flush intervals, or when using input sources that could cause
+metrics to be out of this allowed range.
+Currently, the timestamp should not be older than 30 minutes or more than
+4 minutes in the future at the time when it is sent to Azure Monitor service.
+
 ## Global configuration options <!-- @/docs/includes/plugin_config.md -->
 
 In addition to the plugin-specific configuration settings, plugins support