diff --git a/docs/sdks/debugging.mdx b/docs/sdks/debugging.mdx
index 5387a0ec3..4d4d446ff 100644
--- a/docs/sdks/debugging.mdx
+++ b/docs/sdks/debugging.mdx
@@ -57,6 +57,22 @@ For server SDKs, these reasons for the value you are seeing can be:
 - `Unrecognized`: the sdk was initialized, but this config did not exist in the set of values
 - `Uninitialized`: the sdk was not yet successfully initialized
 
+In newer server SDKs, the reasons will be a combination of initialization source and evaluation reason:
+Initialization Source
+- `Network`
+- `Bootstrap`
+- `DataAdapter`
+- `Uninitialized`
+- `StatsigNetwork`: this refers to when custom proxy/grpc streaming has triggered the fallback behavior, thus falling back to statsig api. 
+   * If no network config/overrides were used, the sdk default uses statsig apis but the reason will be Network.
+
+Evaluation Reason
+- `LocalOverride`
+- `Unrecognized`
+- `Unsupported`
+- `error`: an error happened during evaluation
+- no reason: successful evaluation
+
 In addition to these reasons, the most recent versions of server SDKs will also give you two times to watch: the time at which config definitions initialized the SDK,
 and the time at which the SDK was currently evaluating those definitions.  When you change a gate/config/experiment, the project time will update
 and server SDKs will download the new definition.  If you have not changed your project in two hours, and the evaluation time is saying
@@ -117,3 +133,14 @@ Android: Available with  `Statsig.openDebugView()`. Available in [v4.29.0](https
 |Landing|Gates List|Gate Details|Experiment Details|
 |--|--|--|--|
 |![client-debugger-landing](https://github.com/statsig-io/statsig-sdk-debugger-chrome-extension/assets/95646168/fa6d7237-eb47-4f09-896c-696cfd5c956c)|![client-debugger-gates-list](https://github.com/statsig-io/statsig-sdk-debugger-chrome-extension/assets/95646168/161d8f35-a9b8-4ff9-b549-e04d04acac8a)|![client-debugger-gate-info](https://github.com/statsig-io/statsig-sdk-debugger-chrome-extension/assets/95646168/ab15e586-5259-4475-8f5c-018b2ab6e8db)|![client-debugger-experiment-details](https://github.com/statsig-io/statsig-sdk-debugger-chrome-extension/assets/95646168/920a6e8a-eb84-4d37-bf77-bb909a575d58)|
+
+
+## SDK Event Handling and Minimizing Event Loss
+
+The SDK batches and flushes events in the background to our server. When the volume of incoming events exceeds the SDK's flushing capacity, some events may be dropped after a certain number of retries. To reduce the chances of event loss, you can adjust several settings in the Statsig options:
+- Event Queue Size: Determines how many events are sent in a single batch.
+  - Increasing the event queue size allows more events to be flushed at once, but it will consume more memory. It's recommended not to exceed 1800 events per batch, as larger payloads may result in failed requests.
+- Retry Queue Size: Specifies how many batches of events the SDK will hold and retry.
+  - By default, the SDK keeps 10 batches in the retry queue. Increasing this limit allows more batches to be retried, but also increases memory usage.
+Tuning these options can help manage event volume more effectively and minimize the risk of event drops.
+