From bc87e3984335359d4c37c784104f85699d23e249 Mon Sep 17 00:00:00 2001
From: "Jokob @NetAlertX" <96159884+jokob-sk@users.noreply.github.com>
Date: Mon, 18 May 2026 02:45:23 +0000
Subject: [PATCH] Enhance documentation and improve formatting across multiple
 files

---
 docs/ADVISORY_EYES_ON_GLASS.md    |  3 +++
 docs/ADVISORY_MULTI_NETWORK.md    | 18 ++++++++++++------
 docs/PLUGINS_DEV_UI_COMPONENTS.md |  2 ++
 docs/WORKFLOW_EXAMPLES.md         | 28 ++++++++++++++--------------
 front/css/app.css                 |  1 +
 5 files changed, 32 insertions(+), 20 deletions(-)

diff --git a/docs/ADVISORY_EYES_ON_GLASS.md b/docs/ADVISORY_EYES_ON_GLASS.md
index ace8f0dc..41803b76 100644
--- a/docs/ADVISORY_EYES_ON_GLASS.md
+++ b/docs/ADVISORY_EYES_ON_GLASS.md
@@ -4,6 +4,9 @@ For Managed Service Providers (MSPs) and Network Operations Centers (NOC), "Eyes
 
 ![filters](./img/ADVISORIES/filters.png)
 
+> [!TIP]
+> If you are using Grafana check the `/metrics` endpoint that exposes **Prometheus-compatible metrics** for NetAlertX, including aggregate device counts and per-device status. See the [Metrics API endpoint](./API_METRICS.md) documentation for details.
+
 ---
 
 ### 1. Configure Auto-Refresh for Live Monitoring
diff --git a/docs/ADVISORY_MULTI_NETWORK.md b/docs/ADVISORY_MULTI_NETWORK.md
index 7a0dd094..c26a4f6e 100644
--- a/docs/ADVISORY_MULTI_NETWORK.md
+++ b/docs/ADVISORY_MULTI_NETWORK.md
@@ -12,20 +12,25 @@ Effective multi-network monitoring starts with understanding how NetAlertX "sees
 * **Manual Entry:** For static assets where only ICMP (ping) status is needed.
 
 > [!TIP]
-> Explore the [remote networks](./REMOTE_NETWORKS.md) documentation for more details on how to set up the approaches menationed above.
+> Explore the [remote networks](./REMOTE_NETWORKS.md) documentation for more details on how to set up the approaches mentioned above.
 
 ---
 
 ### 2. Automating IT Asset Inventory with Workflows
 
-[Workflows](./WORKFLOWS.md) are the "engine" of NetAlertX, reducing manual overhead as your device list grows.
+[Workflows](./WORKFLOWS.md) are the "engine" of NetAlertX, reducing manual overhead as your device list grows. See some examples below.:
+
+#### A. Logical Ownership & VLAN Tagging
+
+Create a workflow triggered on **Device Creation** to:
 
-* **A. Logical Ownership & VLAN Tagging:** Create a workflow triggered on **Device Creation** to:
 1. Inspect the IP/Subnet.
 2. Set `devVlan` or `devOwner` custom fields automatically.
 
+#### B. Auto-Grouping:
+
+Use conditional logic to categorize devices.
 
-* **B. Auto-Grouping:** Use conditional logic to categorize devices.
 * *Example:* If `devLastIP == 10.10.20.*`, then `Set devLocation = "BranchOffice"`.
 
 ```json
@@ -56,9 +61,9 @@ Effective multi-network monitoring starts with understanding how NetAlertX "sees
   ]
 }
 ```
+#### C. Sync Node Tracking
 
-
-* **C. Sync Node Tracking:** When using multiple instances, ensure all synchub nodes have a descriptive `SYNC_node_name` name to distinguish between sites.
+When using multiple instances, ensure all synchub nodes have a descriptive `SYNC_node_name` name to distinguish between sites.
 
 > [!TIP]
 > Always test new workflows in a "Staging" instance. A misconfigured workflow can trigger thousands of unintended updates across your database.
@@ -107,6 +112,7 @@ As your environment grows, tuning the underlying engine is vital to maintain a s
 * **Plugin Scheduling:** Avoid "Scan Storms" by staggering plugin execution. Running intensive tasks like `NMAP` or `MASS_DNS` simultaneously can spike CPU and cause database locks.
 * **Database Health:** Large-scale monitoring generates massive event logs. Use the **[DBCLNP (Database Cleanup)](https://www.google.com/search?q=https://docs.netalertx.com/PLUGINS/%23dbclnp)** plugin to prune old records and keep the SQLite database performant.
 * **Resource Management:** For high-device counts, consider increasing the memory limit for the container and utilizing `tmpfs` for temporary files to reduce SD card/disk I/O bottlenecks.
+* Enable the `DEEP_SLEEP` setting.
 
 > [!IMPORTANT]
 > For a deep dive into hardware requirements, database vacuuming, and specific environment variables for high-load instances, refer to the full **[Performance Optimization Guide](https://docs.netalertx.com/PERFORMANCE/)**.
diff --git a/docs/PLUGINS_DEV_UI_COMPONENTS.md b/docs/PLUGINS_DEV_UI_COMPONENTS.md
index 663f52e0..ef2d75fd 100644
--- a/docs/PLUGINS_DEV_UI_COMPONENTS.md
+++ b/docs/PLUGINS_DEV_UI_COMPONENTS.md
@@ -7,6 +7,7 @@ Configure how your plugin's data is displayed in the NetAlertX web interface.
 Plugin results are displayed in the UI via the **Plugins page** and **Device details tabs**. You control the appearance and functionality of these displays by defining `database_column_definitions` in your plugin's `config.json`.
 
 Each column definition specifies:
+
 - Which data field to display
 - How to render it (label, link, color-coded badge, etc.)
 - What CSS classes to apply
@@ -275,6 +276,7 @@ Replaces specific values with display strings or HTML.
 ```
 
 **Output Examples:**
+
 - `"online"` → 🟢 Online
 - `"offline"` → 🔴 Offline
 - `"idle"` → 🟡 Idle
diff --git a/docs/WORKFLOW_EXAMPLES.md b/docs/WORKFLOW_EXAMPLES.md
index a6c1b3f0..5f5da444 100755
--- a/docs/WORKFLOW_EXAMPLES.md
+++ b/docs/WORKFLOW_EXAMPLES.md
@@ -45,23 +45,23 @@ Sometimes devices are manually archived (e.g., no longer expected on the network
   ],
   "enabled": "Yes"
 }
-```
+````
 
 ### 🔍 Explanation
 
-    - Trigger: Listens for updates to device records.
-    - Conditions:
-        - `devIsArchived` is `1` (archived).
-        - `devPresentLastScan` is `1` (device was detected in the latest scan).
-    - Action: Updates the device to set `devIsArchived` to `0` (unarchived).
+* **Trigger**: Listens for updates to device records.
+* **Conditions**:
+
+  * `devIsArchived` is `1` (archived).
+  * `devPresentLastScan` is `1` (device was detected in the latest scan).
+* **Action**:
+
+  * Updates the device to set `devIsArchived` to `0` (unarchived).
 
 ### ✅ Result
 
 Whenever a previously archived device shows up during a network scan, it will be automatically unarchived — allowing it to reappear in your device lists and dashboards.
 
-
-Here is your updated version of **Example 2** and **Example 3**, fully aligned with the format and structure of **Example 1** for consistency and professionalism:
-
 ---
 
 ## Example 2: Assign Device to Network Node Based on IP
@@ -107,7 +107,7 @@ When new devices join your network, assigning them to the correct network node i
 ### 🔍 Explanation
 
 * **Trigger**: Activates when a new device is added.
-* **Condition**:
+* **Conditions**:
 
   * `devLastIP` contains `192.168.1.` (matches subnet).
 * **Action**:
@@ -173,12 +173,12 @@ You may want to automatically clear out newly detected Google devices (such as C
 * **Trigger**: Runs on device updates.
 * **Conditions**:
 
-  * Vendor contains `Google`.
-  * Device is marked as new (`devIsNew` is `1`).
+  * `devVendor` contains `Google`.
+  * `devIsNew` is `1` (device marked as new).
 * **Actions**:
 
-  1. Set `devIsNew` to `0` (mark as not new).
-  2. Delete the device.
+  1. Sets `devIsNew` to `0` (mark as not new).
+  2. Deletes the device.
 
 ### ✅ Result
 
diff --git a/front/css/app.css b/front/css/app.css
index df77fc02..24bbdf6b 100755
--- a/front/css/app.css
+++ b/front/css/app.css
@@ -1417,6 +1417,7 @@ textarea[readonly],
     grid-template-columns: repeat(auto-fit, minmax(125px, 1fr));
     gap: 0.75em;
     padding: 0.5em 0;
+    padding-top: 0;
 }
 
 #columnFilters::before,