diff --git a/sidebars.js b/sidebars.js
index dc25ebb6..2892508b 100644
--- a/sidebars.js
+++ b/sidebars.js
@@ -41,6 +41,8 @@ module.exports = {
         "guides/contract-error-handling",
         "guides/subscribe-to-event",
         "guides/standalone-delegation",
+        "guides/metrics",
+        "guides/bug-report",
         "guides/migration-guide",
       ],
       collapsed: true,
diff --git a/src/docs/guides/bug-report.mdx b/src/docs/guides/bug-report.mdx
new file mode 100644
index 00000000..a5d3d584
--- /dev/null
+++ b/src/docs/guides/bug-report.mdx
@@ -0,0 +1,41 @@
+import DynamicImage from "@site/src/components/DynamicImage";
+
+# Bug Reporting
+
+:::warning
+To enable this feature, please refer to the [performance metrics page](/guides/metrics).
+:::
+
+## Overview
+
+Beacon includes a bug reporting feature, designed to gather and transmit user generated issue. This document outlines the structure and usage of the bug reporting system.
+
+<DynamicImage src="/img/bug_report_alert.png" alt="Beacon Pairing" />
+
+## Bug Report Object
+
+When a user encounters a bug, they can submit a report which is sent to our backend for analysis.
+Here is an overview of each field in the bug report object sent:
+
+```ts
+{
+    userId: string, // A unique identifier for the user submitting the report. This helps in tracking bugs specific to user accounts or in following up with the user if needed.
+    sdkVersion: string, // The version of the SDK.
+    title: string, // [User generated] A brief, descriptive title of the bug. This should be concise yet informative enough to give an overview of the issue.
+    description: string, // [User generated] A detailed description of the bug. It should include what the user expected to happen and what actually happened. This field can contain error messages, observations, and any relevant details about the bug's behavior.
+    steps: string, // [User generated] A step-by-step guide on how to reproduce the bug. This is crucial for developers to understand and fix the issue. Clear and precise steps can significantly speed up the debugging process.
+    os: string, // The operating system of the user's device. This information is vital as some bugs are OS-specific.
+    browser: string, // The browser on which the bug was encountered. Browser-specific bugs are common, and this information helps in pinpointing such issues.
+    localStorage: string, // A stringified version of the user's Beacon local storage data. Beacon's local storage often contains user settings and other information that could be relevant in understanding the bug.
+    wcStorage: string // A stringified version of the user's WalletConnect storage data.
+}
+```
+
+## Snapshot of Broken State
+
+Beacon creates a copy of the user's storage data at the moment of disconnection. This snapshot includes a copy of local and WalletConnect storage data at the time of disconnection.
+These snapshots provide us with a clear picture of the application's state at the time of the bug, which is crucial for understanding and rectifying the issue.
+
+## Data Privacy
+
+Sensitive information should not be included in bug reports unless it's crucial for the issue resolution. User-specific data is not transmitted.
diff --git a/src/docs/guides/metrics.mdx b/src/docs/guides/metrics.mdx
new file mode 100644
index 00000000..ab924b04
--- /dev/null
+++ b/src/docs/guides/metrics.mdx
@@ -0,0 +1,61 @@
+# Performance Metrics
+
+## Overview
+
+In Beacon, we have implemented a system to monitor the performance of requests made to the wallet. This system helps identifying issues related to wallet interactions. This document details the structure and purpose of the performance metrics feature.
+
+## Enabling Performance Metrics
+
+To activate performance metrics in your DApp, you need to set the `enableMetrics` parameter to `true` in the DAppClientOptions. Here's an example of how to enable it:
+
+```ts
+const client = new DAppClient({
+  name: "Beacon Docs", // Name of the DApp
+  // ...
+  enableMetrics: true, // Activating performance metrics
+});
+```
+
+Your DApp will now start collecting and transmitting data on every wallet requests
+
+:::important
+When `enableMetrics` is set to `true`, an initial request is sent to our backend.
+This serves two key purposes: verifying if the dApp is authorized to send metrics to our system and preemptively checking for any potential network issues.
+It's crucial to note that if this initial request, or any subsequent metric-related request, fails, Beacon will automatically disable all metrics collection to prevent any operational disruptions and reliability of the metrics collection process.
+:::
+
+## Performance Metrics Object
+
+For each request sent to the wallet, we record and send two key pieces of data to our backend: the initial request and the outcome of the request (successful, error, or aborted). The object transmitted contains the following fields:
+
+```ts
+{
+    userId: string, // The unique identifier of the user making the request
+    os: string, // The operating system of the user's device.
+    walletName: string, // The name of the wallet being used.
+    walletType: string, // The type of wallet being interacted with, categorized as "extension", "mobile", "web", or "desktop".
+    sdkVersion: string, // The version of the SDK.
+    transport: string, // The method used for connecting to the wallet. Options include "extension", "p2p" (peer-to-peer), "walletconnect", or "website".
+    time: Date, // The timestamp when the request was made.
+    action: string, // The type of action being performed, such as "connect", "message", or "disconnect".
+    status: string // The status of the request, which can be "start", "abort", "success", or "error".
+}
+```
+
+:::note
+userId is a [UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier) generated when instantiating `DAppClient`, not on page refresh.
+:::
+
+## Use of Performance Metrics
+
+These performance metrics are critical for several reasons:
+
+- They enable real-time monitoring of wallet interactions, helping identify patterns or issues in user experience.
+- Understanding how different wallet types and transports behave under various conditions helps in optimizing the application for better user experience.
+
+## Data Collection Process
+
+To collect these metrics, the application automatically wraps every wallet request with the necessary data logging. This process is run:
+
+1. When a user initiates an action with the wallet, the application logs the start of the request with the user's details and action information.
+2. When an outcome is received (success, error, or aborted).
diff --git a/src/docs/wallet/getting-started/web/getting-started.mdx b/src/docs/wallet/getting-started/web/getting-started.mdx
index 1c0faf2a..fb21c3df 100644
--- a/src/docs/wallet/getting-started/web/getting-started.mdx
+++ b/src/docs/wallet/getting-started/web/getting-started.mdx
@@ -109,7 +109,7 @@ const connectApp = async (): Promise<void> => {
       client.respond(response);
     })
     .catch((error) => console.error("connect error", error));
-  
+
   connectApp().catch((error) => console.error("connect error", error));
 ```
 
diff --git a/static/img/bug_report_alert.png b/static/img/bug_report_alert.png
new file mode 100644
index 00000000..5c835eda
Binary files /dev/null and b/static/img/bug_report_alert.png differ