diff --git a/crates/wasmtime/src/config.rs b/crates/wasmtime/src/config.rs
index f026d2d27986..4b12fe5f7e25 100644
--- a/crates/wasmtime/src/config.rs
+++ b/crates/wasmtime/src/config.rs
@@ -585,6 +585,24 @@ impl Config {
     /// [`Store::set_epoch_deadline`](crate::Store::set_epoch_deadline). If this
     /// deadline is not configured then wasm will immediately trap.
     ///
+    /// ## Interaction with blocking host calls
+    ///
+    /// Epochs (and fuel) do not assist in handling WebAssembly code blocked in
+    /// a call to the host. For example if the WebAssembly function calls
+    /// `wasi:io/poll/poll` to sleep epochs will not assist in waking this up or
+    /// timing it out. Epochs intentionally only affect running WebAssembly code
+    /// itself and it's left to the embedder to determine how best to wake up
+    /// indefinitely blocking code in the host.
+    ///
+    /// The typical solution for this, however, is to use
+    /// [`Config::async_support(true)`](Config::async_support) and the `async`
+    /// variant of WASI host functions. This models computation as a Rust
+    /// `Future` which means that when blocking happens the future is only
+    /// suspended and control yields back to the main event loop. This gives the
+    /// embedder the opportunity to use `tokio::time::timeout` for example on a
+    /// wasm computation and have the desired effect of cancelling a blocking
+    /// operation when a timeout expires.
+    ///
     /// ## When to use fuel vs. epochs
     ///
     /// In general, epoch-based interruption results in faster