docs: review Monitor documentation in all seven translations

web/messages/en/docs/monitor/dashboard/hardware.json

@@ -108,7 +108,7 @@
   "coral": {
     "heading": "Coral TPU / AI Accelerators",
     "subHeading": "(conditional)",
-    "intro": "Renders when the host has Google Coral or other AI-accelerator devices wired up. Each device opens a modal with its connection type (M.2 / mini-PCIe / USB), PCIe link width, vendor / product ID, kernel driver (<code>apex</code> for PCIe, <code>libedgetpu</code> for USB), kernel modules (<code>gasket</code> + <code>apex</code>), device nodes (<code>/dev/apex_*</code>), Edge TPU runtime status, live temperature and the firmware hardware-warning thresholds.",
+    "intro": "Renders when the host has Google Coral or other AI-accelerator devices wired up. Each device opens a modal with its connection type (M.2 / mini-PCIe / USB), PCIe link width, vendor / product ID, software support (the <code>apex</code> kernel driver for PCIe, the <code>libedgetpu</code> user-space library for USB), kernel modules (<code>gasket</code> + <code>apex</code>), device nodes (<code>/dev/apex_*</code>), Edge TPU runtime status, live temperature and the firmware hardware-warning thresholds.",
     "imageAlt": "Coral Edge TPU detail modal: PCIe / M.2 connection, PCIe 5.0 GT/s x1 link, vendor 1ac1:089a, kernel driver apex, gasket and apex modules loaded, /dev/apex_0 present, Edge TPU Runtime not installed, temperature 53.5 °C with hardware warning thresholds",
     "imageCaption": "M.2 Coral with the host kernel modules loaded, the device node up and the firmware temperature warnings exposed. The runtime line goes green once the matching Edge TPU runtime is installed.",
     "pathsIntro": "Two install paths exist depending on the form factor:",
@@ -189,7 +189,7 @@
       {
         "section": "CPU temperature history",
         "endpoint": "/api/temperature/history",
-        "source": "Time series sampled by the Health Monitor every 5 min and persisted to SQLite."
+        "source": "Time series recorded by the temperature collector every 60 seconds and persisted to SQLite."
       },
       {
         "section": "GPU live metrics",

web/messages/en/docs/monitor/dashboard/network.json

@@ -59,7 +59,7 @@
       "<strong>Click</strong> — every node except the host is clickable and opens the same per-interface drill-in modal documented below. Tapping the host is intentionally a no-op — there is no host-level modal in this view."
     ],
     "useTitle": "When it's useful",
-    "useBody": "The group cards below tell you <em>what</em> exists; the diagram tells you <em>how it's connected</em> and where the traffic is flowing right now. Patterns easy to spot at a glance: a bridge with no active guest attached, two heavy guests going through the same NIC (bottleneck candidate), or a single VM saturating a link while everything else is quiet."
+    "useBody": "The group cards show <em>what</em> exists; the diagram shows <em>how it is connected</em> and where traffic is flowing. You can spot guests sharing a bridge, two busy guests sharing a NIC (a possible bottleneck), or one VM saturating a link while others are quiet."
   },
   "groups": {
     "heading": "Three interface groups",
@@ -121,7 +121,7 @@
     "mode1Title": "Mode 1 — Historical view",
     "mode1Alt": "Network Latency modal in historical mode — Gateway target with a 1-hour timeframe and the past samples plotted",
     "mode1Caption": "Historical view — Gateway target over the last hour, fed from the latency-history database written every 60 seconds by the temperature/latency collector thread.",
-    "mode1Body1": "The default mode when the modal opens. A second dropdown picks the timeframe (<em>1 Hour / 24 Hours / 7 Days / 30 Days / 1 Year</em>); data resolution drops with the window so the chart stays readable. Headline stats — Current / Min / Avg / Max — render above the chart, with a status pill (Excellent / Good / Fair / Poor) reflecting the current value against the thresholds below.",
+    "mode1Body1": "The default mode when the dialog opens. A second dropdown selects the timeframe (<em>1 Hour / 6 Hours / 24 Hours / 3 Days / 7 Days</em>). Current / Min / Avg / Max appear above the chart, with an Excellent / Good / Fair / Poor status indicator based on the thresholds below.",
     "mode1Body2": "Source: the same latency samples the Health Monitor uses to detect persistent network slowdowns — sampled every 60 seconds against the gateway by the background <code>_temperature_collector_loop</code> thread, written to a local SQLite history.",
     "mode2Title": "Mode 2 — Real-time test",
     "mode2Alt": "Network Latency modal running a real-time ping test against Cloudflare — progress bar at 50%, live samples accumulating on the chart",
@@ -162,9 +162,9 @@
       }
     ],
     "reportTitle": "Network Latency Report (PDF)",
-    "reportIntro": "Both modes have a <strong>Report</strong> button next to the target selector. Clicking it generates a PDF with everything you'd send to your ISP if you wanted to make a case for poor service.",
+    "reportIntro": "Both modes have a <strong>Report</strong> button beside the target selector. It generates a PDF of the measurements that you can attach to a troubleshooting request to your ISP.",
     "reportPreviewAlt": "First page of the Network Latency Report PDF — Executive Summary with the gauge, latency statistics, the latency graph and the threshold guide",
-    "reportPreviewCaption": "First page of the Network Latency Report — Executive Summary with the gauge dial and headline stats, the per-second latency graph, and the threshold guide. Page 2 onwards has the per-sample table and methodology.",
+    "reportPreviewCaption": "The first page of the Network Latency Report contains the executive summary, gauge, main statistics, time-series latency graph and threshold guide. Page 2 onwards contains the per-sample table and methodology.",
     "downloadLabel": "Download sample Network Latency report (PDF)",
     "sectionsIntro": "The report has six sections:",
     "sections": [
@@ -173,10 +173,10 @@
       "<strong>Latency Graph</strong> — area chart of every sample over the test window with a min/avg/max y-axis grid.",
       "<strong>Performance Thresholds</strong> — the same four-tier scale documented above, with a coloured dot per tier.",
       "<strong>Detailed Test Results</strong> — numbered table with timestamp, latency, packet loss and status for every sample. Useful for spotting micro-bursts that the headline averages hide.",
-      "<strong>Methodology</strong> — test method (ICMP Echo Request), samples per test (3 consecutive pings), target name, target IP and a final \"Performance Assessment\" paragraph derived from the verdict."
+      "<strong>Methodology</strong> — ICMP Echo Request, 3 consecutive pings per sample, target name and IP, and a final performance assessment derived from the status."
     ],
-    "useCaseTitle": "Use case: claims to your ISP",
-    "useCaseBody": "Run the real-time test against Cloudflare for 2 minutes during a moment of perceived slowness, then click <em>Test Again</em> a few times to extend the dataset, and finally <em>Report</em>. The PDF carries the full per-sample table plus the methodology block — ISPs typically accept this as evidence, especially when correlated with timestamps from a separate complaint."
+    "useCaseTitle": "Use case: support from your ISP",
+    "useCaseBody": "Run the real-time Cloudflare test for 2 minutes while the connection feels slow, use <em>Test Again</em> to extend the record, then select <em>Report</em>. The PDF includes all samples and the methodology. You can attach it to a support request with the incident timestamps; your ISP decides what evidence it requires."
   },
   "excluding": {
     "heading": "Excluding noisy interfaces",
@@ -202,7 +202,7 @@
       {
         "section": "Per-interface RX/TX time series",
         "endpoint": "/api/network/<iface>/metrics",
-        "source": "<code>/proc/net/dev</code> sampled by the Health Monitor with byte-rate calculation."
+        "source": "Live counters use <code>/proc/net/dev</code>; chart history comes from Proxmox RRD through pvesh. VM/LXC interfaces use guest RRD data; physical and bridge interfaces use node-level RRD data."
       },
       {
         "section": "Latency: current",
@@ -212,7 +212,7 @@
       {
         "section": "Latency: historical",
         "endpoint": "/api/network/latency/history",
-        "source": "Persisted samples — every 5 min by the Health Monitor cycle."
+        "source": "Samples persisted about every 60 seconds by the background temperature/latency collector."
       }
     ],
     "codeComment1": "# Cross-check the interface state seen by the dashboard",

web/messages/en/docs/monitor/dashboard/security.json

@@ -10,7 +10,7 @@
   },
   "intro": {
     "title": "Two scopes, one tab",
-    "body": "The Security tab is divided into two clearly separated sections: <strong>ProxMenux Monitor</strong> (settings for the dashboard itself) and <strong>Proxmox VE</strong> (settings for the host underneath). Cards render conditionally — Fail2Ban and Lynis only appear once installed."
+    "body": "The Security tab has two sections: <strong>ProxMenux Monitor</strong> (dashboard settings) and <strong>Proxmox VE</strong> (host settings). The Fail2Ban and Lynis cards offer installation when those tools are missing, then show their controls once installed."
   },
   "monitor": {
     "heading": "ProxMenux Monitor",
@@ -101,13 +101,13 @@
   },
   "pve": {
     "heading": "Proxmox VE",
-    "intro": "The host's own protections — firewall, intrusion prevention and security audit. Last two only render when their respective tools are installed."
+    "intro": "The host’s protections: firewall, intrusion prevention and security audit. The Fail2Ban and Lynis cards offer installation if the tools are missing, then expose their management controls."
   },
   "firewall": {
     "heading": "Proxmox Firewall",
     "imageAlt": "Proxmox Firewall card showing Cluster Firewall and Host Firewall status, Quick Access Rules for ProxMenux Monitor and Proxmox Web UI, Rules Overview counters and a list of Firewall Rules with Add Rule button",
     "imageCaption": "Proxmox Firewall card — cluster-level and host-level enable / disable toggles, common ports as <em>Quick Access Rules</em>, totals across <em>Rules Overview</em>, and the full rule list with <em>+ Add Rule</em>.",
-    "intro": "The card surfaces the Proxmox VE built-in firewall (which is independent from any host-level <code>iptables</code> / <code>nftables</code> you may run alongside). Three blocks:",
+    "intro": "The card manages the Proxmox VE firewall configuration. The classic backend uses <code>iptables</code>; the alternative backend uses <code>nftables</code>. It does not manage arbitrary rules created outside Proxmox. Three blocks:",
     "items": [
       "<strong>Cluster Firewall + Host Firewall</strong> — global toggles. The cluster firewall must be active for any host-level rule to take effect; the card flags this dependency inline.",
       "<strong>Quick Access Rules</strong> — pre-defined rows for ports that matter to ProxMenux itself: <code>8008/TCP</code> (Monitor), <code>8006/TCP</code> (Proxmox Web UI). Each row shows the current allow / deny / unprotected state. The Proxmox Web UI is allowed via the <em>built-in</em> Proxmox firewall macro and can't be removed accidentally.",
@@ -135,8 +135,8 @@
     "configAlt": "Configure sshd jail form with Max Retries, Ban Time in seconds with Permanent Ban option, Find Time, common values reminder, and Save Configuration button",
     "configCaption": "Editing the sshd jail — pick a stricter <em>Max Retries</em> for SSH if you only ever log in from your own subnet, or extend <em>Ban Time</em> for the public-facing dashboard.",
     "outro": "The full <em>What it installs / how it's configured / how to uninstall</em> walkthrough — including the manual install path, the SSH MaxAuthTries side effect, and the relationship with the <code>proxmenux-auth.log</code> journal — is in <link>ProxMenux → Security → Fail2Ban</link>.",
-    "calloutTitle": "Without Fail2Ban, brute-force protection is best-effort",
-    "calloutBody": "ProxMenux Monitor has its own <em>application-level</em> ban hook in the Flask request pipeline — but it only takes effect if Fail2Ban is installed and writes to the bans table. Without Fail2Ban, the Monitor logs failed logins to <code>proxmenux-auth.log</code> for future inspection but doesn't actively block IPs."
+    "calloutTitle": "Without Fail2Ban, this mechanism does not block IPs",
+    "calloutBody": "ProxMenux Monitor checks Fail2Ban’s banned IPs at the <em>application level</em> before handling Flask requests. It queries fail2ban-client and caches the result for 30 seconds; it does not read a SQL bans table. Without Fail2Ban, failed logins are recorded in <code>proxmenux-auth.log</code>, but this mechanism does not actively block IPs."
   },
   "lynis": {
     "heading": "Lynis Security Audit",
@@ -145,7 +145,7 @@
     "whyUseful": "<strong>Why it's useful.</strong> Knowing the security posture of your server is hard to do by reading config files one by one. Lynis catches the things that are routinely overlooked: kernel hardening flags missing, weak SSH ciphers enabled, journal not persistent, sudoers <code>NOPASSWD</code> on default accounts, and many more. Re-running it after applying ProxMenux post-install tweaks gives you an objective number for the improvement.",
     "notInstalledAlt": "Lynis Security Audit card with Not Installed state and Install Lynis button, listing features: hardening scoring, vulnerability detection, compliance checking and GitHub source",
     "notInstalledCaption": "Lynis card before install — the blue box summarises what the tool does.",
-    "notBundled": "Lynis is also <strong>not bundled</strong>. ProxMenux installs the latest release directly from the official GitHub source (not the Debian package, which lags several minor versions).",
+    "notBundled": "Lynis is also <strong>not bundled</strong>. ProxMenux installs it directly from the official GitHub source rather than the Debian package.",
     "confirmAlt": "Install Lynis confirmation modal listing what Lynis does: hardening scoring, vulnerability detection, configuration analysis, compliance checking, source from official GitHub repository",
     "confirmCaption": "Install confirmation — explicit about the GitHub source.",
     "progressAlt": "Lynis Installation streaming panel: installing latest scan tool, version 3.1.6 confirmed, installation completed message",
@@ -157,7 +157,7 @@
     "runningCaption": "Audit in progress — the action button shows a spinner and the card explicitly warns that the scan can take 2–5 minutes.",
     "finishedBody": "When it finishes, the card flips to the results view: hardening index, warnings, suggestions and an <em>Audit Reports</em> list with each historical scan.",
     "resultsAlt": "Lynis Security Audit card with results: Hardening Index 71 with Lynis 66 PVE 71 breakdown, 3 warnings, 40 suggestions, Security Hardening Score progress bar Proxmox Adjusted 71 of 100 in the Good range, audit reports list with PDF download and Run Security Audit button",
-    "resultsCaption": "Audit results — Hardening Index <strong>71/100 (Good)</strong> on a sample run. The card also shows the \"Lynis raw score\" (66) versus the Proxmox-adjusted score (71) which adds back 11 points for findings the Lynis test corpus flags but are expected behaviour on Proxmox VE.",
+    "resultsCaption": "Audit results — Hardening Index <strong>71/100 (Good)</strong> in a sample run. The card shows the Lynis raw score (66) and the Proxmox-adjusted score (71). The adjustment depends on the raw score and the share of findings classified as expected on Proxmox VE; it is not a fixed 11-point addition.",
     "scoreTitle": "Lynis raw score vs Proxmox-adjusted score",
     "scoreIntro": "Lynis ships rules tuned for general-purpose Debian. Proxmox legitimately diverges from some of them (services running as root for cluster reasons, custom <code>journald</code> tuning, etc.). The card shows both numbers so you can:",
     "scoreItems": [
@@ -179,7 +179,7 @@
       {
         "card": "Authentication, 2FA, password change",
         "endpoint": "/api/auth/*",
-        "source": "Local SQLite + JWT issued by the Monitor."
+        "source": "Local auth configuration in ~/.config/proxmenux-monitor/auth.json; JWTs issued by the Monitor."
       },
       {
         "card": "SSL / HTTPS",

web/messages/en/docs/monitor/dashboard/settings.json

@@ -76,18 +76,18 @@
   },
   "thresholds": {
     "heading": "Health Monitor Thresholds",
-    "intro": "Where the previous card decides <em>how long to stay quiet after a dismiss</em>, this one decides <strong>at what value an alert fires in the first place</strong>. Every check the Health Monitor runs is parameterised by a pair of numbers — a <strong>Warning</strong> threshold and a <strong>Critical</strong> threshold — and both are exposed here for the operator to tune.",
+    "intro": "The previous card sets <em>how long to stay quiet after a dismiss</em>; this one sets <strong>the value at which an alert is raised</strong>. Most threshold-based checks have adjustable <strong>Warning</strong> and <strong>Critical</strong> values. The table below explains exceptions such as the combined swap rule and the current RAM detector.",
     "whatForTitle": "What it is for",
     "whatForIntro": "Defaults that ship with ProxMenux are sane for the average Proxmox host, but every environment has its own envelope:",
     "whatForItems": [
       "A small homelab with a single-disk SSD may want to page earlier on capacity (75 / 90 %) to leave room for snapshots.",
-      "A datacenter host with redundant Ceph nodes can be more relaxed on memory warnings (a 90 % working set is normal under ZFS ARC).",
-      "A passively-cooled mini-PC needs lower temperature thresholds than a server with forced-air cooling — same drive class, different physical envelope.",
+      "Memory thresholds should reflect the host’s memory measurements and workload. Ceph redundancy alone does not justify relaxing memory warnings, and high ZFS ARC usage must not be confused with an unreclaimable working set.",
+      "Choose drive-temperature thresholds using the drive’s specifications and observed operating conditions. Passive versus forced-air cooling alone does not determine a universally lower or higher safe limit.",
       "A heavily-virtualized host that pegs CPU during builds should not page on every 80 % spike, but must still alert on sustained pressure."
     ],
-    "whatForOutro": "Editing a threshold takes effect <strong>on the next scan</strong> — the Health Monitor re-reads the values from <code>/usr/local/share/proxmenux/health_thresholds.json</code> on every cycle, no service restart needed. The same numbers also feed the colour ranges of the dashboard widgets (the temperature line in the disk-temperature modal, the bars on the storage cards) so the visual classification matches what triggers the alert.",
+    "whatForOutro": "Supported threshold changes take effect <strong>on the next scan</strong>. The Health Monitor reads <code>/usr/local/share/proxmenux/health_thresholds.json</code> each cycle without a restart. Selected widgets, including disk temperature, use these values; some capacity bars retain separate visual cutoffs. See the RAM row below for a current runtime exception.",
     "coloursTitle": "Status colours: how Warning and Critical render in the dashboard",
-    "coloursIntro": "Every threshold below produces the same three-state classification across the dashboard — same colours for storage bars, CPU/memory rings, temperature chips, and the dot on the disk modal. Reading a colour anywhere in the Monitor maps to a definite range relative to the configured pair:",
+    "coloursIntro": "Widgets that use the configured Warning/Critical pair follow the three-state classification below. Some visual indicators, including the PVE storage capacity bars, use their own cutoffs; do not infer a Health Monitor alert solely from their colour.",
     "headerColour": "Colour",
     "headerRange": "Range",
     "headerMeaning": "Meaning",
@@ -105,7 +105,7 @@
       {
         "colour": "Red",
         "range": "value ≥ Critical",
-        "meaning": "Critical state. The Health Monitor fires a CRITICAL event; CRITICAL bypasses Quiet Hours and always reaches the channel."
+        "meaning": "Critical state. The Health Monitor raises a CRITICAL event, which bypasses Quiet Hours. Channel category/event settings still apply; delivery also depends on the channel being available."
       }
     ],
     "sectionsTitle": "Sections and recommended defaults",
@@ -125,13 +125,13 @@
         "section": "Memory",
         "warning": "85 %",
         "critical": "95 %",
-        "gates": "RAM pressure on the host."
+        "gates": "Host RAM pressure. The configurable Critical default shown here is 95 %, but the current detector uses a hard-coded 90 % sustained RAM rule; changing that setting does not currently change this runtime branch."
       },
       {
         "section": "Swap (critical only)",
         "warning": "—",
-        "critical": "5 %",
-        "gates": "Swap actually being used. The number is intentionally low: a healthy Proxmox host should rarely touch swap, so even 5 % is a meaningful signal of RAM pressure."
+        "critical": "80 %",
+        "gates": "Swap CRITICAL requires both swap usage above 80 % and available RAM below 15 %, sustained across the detector’s samples. Used swap alone does not trigger this rule."
       },
       {
         "section": "CPU temperature",
@@ -143,25 +143,25 @@
         "section": "Disk temp — HDD",
         "warning": "60 °C",
         "critical": "65 °C",
-        "gates": "Standard spinning drives. Manufacturer envelope tops out around 60–65 °C, so Critical is set right at the hard limit."
+        "gates": "HDD temperature. The defaults are 60 °C Warning and 65 °C Critical; these are monitoring defaults, not a universal manufacturer limit. Check the specific drive model’s specifications."
       },
       {
         "section": "Disk temp — SSD",
         "warning": "70 °C",
         "critical": "75 °C",
-        "gates": "2.5'' / M.2 SATA SSDs — run cooler than NVMe but warmer than HDDs."
+        "gates": "SATA SSDs in 2.5-inch or M.2 formats. This class uses 70/75 °C monitoring defaults; actual temperature limits depend on the drive model."
       },
       {
         "section": "Disk temp — NVMe",
         "warning": "80 °C",
         "critical": "85 °C",
-        "gates": "NVMe drives run hotter by design; controllers self-throttle above ~85 °C, so Warning catches the climb before throttling kicks in."
+        "gates": "NVMe temperature. The class uses 80/85 °C monitoring defaults. Controller throttling temperatures vary by model and are not universally 85 °C."
       },
       {
         "section": "Disk temp — SAS",
         "warning": "55 °C",
         "critical": "65 °C",
-        "gates": "Enterprise SAS drives share the same ~65 °C manufacturer limit as HDDs, but are normally deployed in rack chassis with active cooling. A reading at 55 °C already signals a cooling problem (failed fan, HVAC issue) <em>before</em> the drive itself is at risk — hence a lower Warning than HDD, not because SAS is less heat-tolerant."
+        "gates": "SAS temperature. This class uses 55 °C Warning and 65 °C Critical. These are <em>monitoring defaults</em>, not proof of a cooling fault at 55 °C or a universal manufacturer limit."
       },
       {
         "section": "Disk space — host",
@@ -185,7 +185,7 @@
         "section": "PVE storage",
         "warning": "85 %",
         "critical": "95 %",
-        "gates": "Block-style PVE storages (LVM, LVM-thin, ZFS-pool, RBD/Ceph, PBS)."
+        "gates": "PVE-managed storages, including LVM, LVM-thin, ZFS-pool, RBD/Ceph and PBS. These are not all block-storage backends."
       },
       {
         "section": "ZFS pool",
@@ -197,7 +197,7 @@
     "defaultsTitle": "Defaults, overrides and reset",
     "defaultsBody": "The backend exposes a merged view: every section starts from the ProxMenux defaults (the values you see when the host is fresh) and you override only the knobs you care about. The card shows the <em>effective</em> value — the override if you set one, otherwise the default. A <strong>Reset</strong> button wipes every override and goes back to defaults across all sections at once.",
     "validationTitle": "Validation",
-    "validationBody": "Saving rejects values that don't make sense (percentages outside 0–100, critical below warning, negative temperatures). The frontend shows the inline error; the backend validates again before persisting, so the API can't be tricked into a broken threshold by a hand-crafted PUT."
+    "validationBody": "Saving validates values against each field’s allowed range and rejects Critical below Warning. The interface shows validation errors, and the backend validates API requests again before persisting changes."
   },
   "lxcDetection": {
     "heading": "LXC Update Detection",
@@ -207,18 +207,18 @@
     "whatRunsTitle": "What the scan actually runs",
     "whatRunsIntro": "For each CT in <code>running</code> state with a supported package manager:",
     "whatRunsItems": [
-      "<strong>Cache freshness gate.</strong> If the in-container apt/apk metadata cache is older than <strong>24 hours</strong>, a best-effort refresh runs first (<code>apt-get update -qq</code> on Debian/Ubuntu, <code>apk update</code> on Alpine) with a 60 s timeout. Any failure (no network, broken repo, timeout) is swallowed silently — the listing below still runs against whatever cache exists, so a transient repo issue can never make detection worse than before.",
+      "<strong>Metadata freshness.</strong> If the in-container apt/apk metadata cache is older than <strong>24 hours</strong>, a refresh is attempted first (<code>apt-get update -qq</code> on Debian/Ubuntu, <code>apk update</code> on Alpine), with a 60 s timeout. If it fails, listing still uses the available cache; results may therefore be stale.",
       "<strong>Listing.</strong> Then ProxMenux runs <code>apt list --upgradable</code> / <code>apk list -u</code> and parses the output into a structured count plus a sample of the top package names.",
       "<strong>Per-CT dedup.</strong> A fingerprint built from count, security-count and the sorted top names is stored so a stable set of pending updates doesn't re-notify daily, while a meaningfully different set does."
     ],
     "selfUpdateTitle": "CTs that self-update outside apt may legitimately report 0",
-    "selfUpdateBody": "Detection only sees what the in-container package manager knows about. A CT whose key software updates itself outside apt (Plex's <code>plexupdate</code> cron, Docker containers updated via <code>docker pull</code>, Frigate's built-in updater, etc.) will keep reporting low or zero apt updates even when the appliance is actively staying current — that's correct, not a bug. The apt-level base system on the same CT may still have its own pending updates, which the scan does surface.",
+    "selfUpdateBody": "Detection only covers the in-container package manager. Software updated outside apt, such as a configured <code>plexupdate</code> job or Docker images fetched with <code>docker pull</code>, is outside that count. Zero apt updates does not prove that every application is current. The same CT’s base system can still have package updates detected by the scan.",
     "refreshTitle": "Why the 24 h auto-refresh",
-    "refreshBody": "Long-running appliance CTs frequently end up with apt caches months out of date because nobody routinely runs <code>apt update</code> inside them. Without the refresh, <code>apt list --upgradable</code> reports 0 updates from a frozen snapshot and the operator never sees the backlog. The threshold matches the rest of the check cycle — if the CT was refreshed within the last 24 h, ProxMenux trusts that signal and skips the refresh.",
+    "refreshBody": "Long-running CTs can have stale apt metadata if nobody runs <code>apt update</code>. Then <code>apt list --upgradable</code> can miss newer updates. ProxMenux attempts a refresh when the metadata is older than 24 hours and skips it when the cache was refreshed more recently.",
     "toggleTitle": "Conditional notification toggle",
     "toggleBody": "The <code>lxc_updates_available</code> per-channel notification toggle in <strong>Notifications → Services</strong> only renders while detection is enabled. When you turn detection OFF, that row disappears from every channel's category list — but its stored preference is preserved in the DB, so re-enabling detection brings the toggle back at the value it had before.",
     "purgeTitle": "What gets purged when you disable detection",
-    "purgeBody": "Turning the switch OFF immediately removes every <code>type=lxc</code> entry from <code>/usr/local/share/proxmenux/managed_installs.json</code>. The Hardware tab badges drop to zero on the next dashboard refresh. Turning it back ON repopulates the registry on the next detection cycle (or sooner if you trigger a manual refresh from the API)."
+    "purgeBody": "Turning the switch OFF immediately removes every <code>type=lxc</code> entry from <code>/usr/local/share/proxmenux/managed_installs.json</code>. LXC update counts on the Hardware tab clear on the next dashboard refresh. Turning it back ON repopulates the registry on the next detection cycle, or sooner with a manual API refresh."
   },
   "storageExclusions": {
     "heading": "Remote Storage Exclusions",
@@ -238,9 +238,9 @@
     "intro": "Same shape as Storage Exclusions but for network interfaces. Per interface: exclude from Health checks and / or exclude from notifications. Typical use cases:",
     "items": [
       "An intentionally-down spare bridge.",
-      "A NIC that was physically removed but still references in <code>/etc/network/interfaces</code>.",
+      "A NIC that was physically removed but is still referenced in <code>/etc/network/interfaces</code>.",
       "A VLAN sub-interface used only during maintenance windows.",
-      "A management bridge that is up but doesn't carry traffic — flapping noisily on every cycle."
+      "A management bridge with known, repeated link-state changes during maintenance."
     ],
     "outro": "State is persisted in the <code>excluded_interfaces</code> SQLite table. Same purple <em>excluded</em> badge on the <link>Network tab</link> so excluded interfaces stay visible."
   },
@@ -255,26 +255,26 @@
   },
   "optimizations": {
     "heading": "ProxMenux Optimizations",
-    "intro": "A live, transparent inventory of every ProxMenux post-install optimization currently active on the host. Every time you apply a post-install option from the Scripts side — either via the <autoLink>Automated post-install</autoLink> or via the à-la-carte <customLink>Customizable post-install</customLink> — the corresponding script registers itself in <code>/usr/local/share/proxmenux/installed_tools.json</code>. The Monitor reads that file and renders this card so you can see, at a glance, what's been changed on your server.",
+    "intro": "An inventory of post-install optimizations recorded by ProxMenux on the host. Options from <autoLink>Automated post-install</autoLink> and <customLink>Customizable post-install</customLink> register their application in <code>/usr/local/share/proxmenux/installed_tools.json</code>. The Monitor reads that registry for this card. A recorded entry is not a fresh check that every underlying setting remains unchanged.",
     "imageAlt": "ProxMenux Optimizations card with grid of installed tools, each row showing a green dot, tool name and version. Examples include APT IPv4 Force, Bashrc Customization, Fastfetch, Log2ram SSD Protection, Memory Settings Optimization, Setting persistent network interfaces, System Limits Increase, APT Language Skip, Entropy Generation haveged with Legacy badge, Kernel Panic Configuration, Logrotate Optimization, Network Optimizations, Subscription Banner Removal, VFIO IOMMU Passthrough — 14 active total",
     "imageCaption": "The card lists every active optimization with its name, version, a coloured dot and an orange <em>14 active</em> counter at the top right. Tools whose source is reachable are clickable.",
     "dotsTitle": "What the dots mean",
     "dotsItems": [
-      "<green/> <strong>Green dot</strong> — current optimization, registered by the active version of ProxMenux. Source code is reachable: click the row to open it.",
-      "<amber/> <strong>Amber dot + <em>legacy</em> badge</strong> — applied by an older ProxMenux version whose script has since been renamed or replaced. Still active on the host; the source opens in \"legacy\" mode (with an amber accent) so you can audit what was actually run."
+      "<green/> <strong>Green dot</strong> — a registered optimization that is not marked legacy and has no available update indicated. Click the row when source code is available.",
+      "<amber/> <strong>Amber dot + <em>legacy</em> badge</strong> — a registered optimization whose script was renamed or replaced. Its preserved source opens in legacy mode with an amber accent. This does not revalidate the current host configuration."
     ],
     "clickTitle": "Click-through to source code",
-    "clickBody": "Clicking a tool opens a modal with the exact bash function that applied the change, plus the script file path it lives in (<code>auto_post_install.sh</code> for the Automated bundle, <code>customizable_post_install.sh</code> for the à-la-carte side). Comments and shell constructs are syntax-highlighted; a Copy button puts the source on your clipboard. This is the \"show your work\" surface — verify what ProxMenux did to your host before any manual change you make on top.",
+    "clickBody": "Clicking a tool opens a modal with its mapped bash function and script name (<code>auto_post_install.sh</code> or <code>customizable_post_install.sh</code>). Current tools are extracted from files on the host; legacy tools can use preserved source. Syntax highlighting and Copy help inspect the code. This is not a guaranteed snapshot of the exact code that ran at installation time.",
     "detailAlt": "Tool source code modal for APT IPv4 Force showing the bash function force_apt_ipv4 from customizable_post_install.sh version 1.0 with syntax-highlighted code that configures /etc/apt/apt.conf.d/99-force-ipv4 with Acquire ForceIPv4 true, registers the tool and emits a translate APT IPv4 configuration completed message",
     "detailCaption": "Source modal for <em>APT IPv4 Force</em> — exact <code>force_apt_ipv4()</code> function from <code>customizable_post_install.sh v1.0</code>, with syntax highlighting and a one-click Copy.",
     "whyTitle": "Why this matters",
-    "whyBody": "ProxMenux changes things on your host: kernel parameters, repository configuration, network bits, log rotation, GPU passthrough, etc. Knowing exactly what's active is essential before you start adding manual customisation on top — and even more so if a different admin runs the host than the one who set it up. This card is the auditable record of every optimisation currently in effect, with the exact code that produced it.",
+    "whyBody": "ProxMenux can change kernel parameters, repository settings, networking, log rotation and GPU passthrough. Review the recorded optimizations before adding manual changes, especially when another administrator set up the host. The card shows registry entries and available source; it does not audit every live setting or preserve an exact execution history.",
     "updatesTitle": "Updates available banner",
     "updatesBody": "When a post-install optimization gets a newer version on disk than the one currently registered on the host, the card shows an \"Updates available\" banner at the top with the count and an <strong>Apply</strong> button. Clicking <strong>Apply</strong> opens a per-optimization picker (the same one available from the Post-Install menu's <em>Apply available updates</em> entry). Pick which optimizations to lift; ProxMenux re-runs the corresponding function and refreshes the version in the registry. When everything is current the banner disappears.",
     "updatesAlt": "ProxMenux Optimizations card with an Updates available banner at the top — count of pending updates plus an Apply button that opens the per-optimization picker",
     "updatesCaption": "The banner only renders when at least one optimization has a newer version on disk. See <link>Apply Available Updates</link> for the full update flow and the Path-A equivalent in the shell menu.",
     "revertTitle": "Reverting an optimization",
-    "revertBody": "The card is read-only — to undo an optimization, run the corresponding <link>Uninstall Optimizations</link> option from the ProxMenux Scripts menu. The uninstall step removes the entry from <code>installed_tools.json</code>, so it disappears from this card on the next refresh."
+    "revertBody": "To undo an optimization, use the corresponding <link>Uninstall Optimizations</link> option in the ProxMenux Scripts menu. Uninstalling removes its entry from <code>installed_tools.json</code>, so the card stops listing it on the next refresh."
   },
   "dataCollected": {
     "heading": "How the data is collected",
@@ -320,7 +320,7 @@
       {
         "card": "Optimization source-code modal",
         "endpoint": "/api/proxmenux/tool-source",
-        "source": "Extracts the matching bash function from <code>auto_post_install.sh</code> or <code>customizable_post_install.sh</code> on the host."
+        "source": "Extracts the mapped bash function from <code>auto_post_install.sh</code> or <code>customizable_post_install.sh</code> on the host; legacy tools can use preserved source."
       }
     ]
   },

web/messages/en/docs/monitor/dashboard/storage.json

@@ -14,7 +14,7 @@
   },
   "thresholds": {
     "title": "Status colours and thresholds applied here",
-    "intro": "Every bar, chip, and dot on this tab follows the same three-state classification — <green/> <strong>green</strong> below Warning, <amber/> <strong>amber</strong> from Warning to Critical, <red/> <strong>red</strong> at Critical and above. Recommended defaults shipped with ProxMenux:",
+    "intro": "Health Monitor classifies status as <green/> <strong>green</strong> below Warning, <amber/> <strong>amber</strong> from Warning to Critical, and <red/> <strong>red</strong> at Critical and above. Its recommended defaults follow. Individual dashboard bars can use different visual cutoffs, described below.",
     "items": [
       "<strong>Capacity</strong> (host disks, PVE storages, ZFS pools, LXC mounts) — Warning 85 %, Critical 95 %.",
       "<strong>Disk temperature</strong> — HDD 60/65 °C · SSD 70/75 °C · NVMe 80/85 °C · SAS 55/65 °C (warning / critical)."
@@ -33,7 +33,7 @@
     "localLabel": "Local Used",
     "localWhat": "Bytes used on local storages (LVM / LVM-thin / ZFS / dir on the host's own disks). Shows the used bytes prominently, with a footer line of <em>X.XX % of Y TB</em> so you see the fill-percentage at the same time.",
     "remoteLabel": "Remote Used",
-    "remoteWhat": "Same shape as Local Used but for remote storages (NFS / CIFS / PBS / Ceph / iSCSI). Counted separately because remote outages don't affect local data and you typically size and monitor them differently.",
+    "remoteWhat": "Same format as Local Used, for remote storages (NFS / CIFS / PBS / Ceph / iSCSI). Counted separately because local and remote failures have different scopes and these resources are typically sized and monitored differently.",
     "disksLabel": "Physical Disks",
     "disksIntro": "Two lines of breakdown for the inventory:",
     "disksItems": [
@@ -45,9 +45,9 @@
     "heading": "Proxmox Storage card",
     "intro": "One row per storage configured in <code>/etc/pve/storage.cfg</code>. Each row shows the type badge (<code>nfs</code> / <code>cifs</code> / <code>zfspool</code> / <code>lvm</code> / <code>lvmthin</code> / <code>dir</code> / <code>pbs</code>), the storage name, an active / error / not-monitored badge, the usage percentage and a coloured progress bar:",
     "items": [
-      "<strong>&lt; 75 %</strong> — blue progress bar, value in blue.",
-      "<strong>75 – 90 %</strong> — yellow progress bar, value in yellow (Health Monitor warns at this point).",
-      "<strong>> 90 %</strong> — red progress bar, value in red (Health Monitor escalates).",
+      "<strong>Up to 75 %</strong> — blue progress bar and value.",
+      "<strong>Above 75 % through 90 %</strong> — yellow progress bar and value. These are visual cutoffs, separate from Health Monitor thresholds.",
+      "<strong>> 90 %</strong> — red progress bar and value; this visual cutoff is separate from Health Monitor escalation.",
       "<strong>error</strong> — full row outlined in red, used when the storage is configured but unreachable (NFS server down, CIFS creds expired).",
       "<strong>excluded</strong> — purple outline + the badge \"not monitored\". Storages explicitly excluded by the user from health checks (handy for manual / archive volumes that are intentionally offline)."
     ],
@@ -70,7 +70,7 @@
     "items": [
       "<strong>Device path</strong> — <code>/dev/sda</code>, <code>/dev/nvme0n1</code>.",
       "<strong>Type badge</strong> — SATA / NVMe (and the relevant icon).",
-      "<strong>System badge</strong> — orange tag that marks disks the host's OS is running from. The dashboard derives this from the mountpoints of <code>/</code> and <code>/boot</code>: any physical disk hosting them gets the <em>System</em> tag so you don't accidentally wipe or repurpose it. Disks without the tag are pure data drives.",
+      "<strong>System badge</strong> — orange tag for disks identified as hosting the OS. Detection uses the mountpoints of <code>/</code> and <code>/boot</code>; physical disks hosting them receive the <em>System</em> tag. A missing tag does not prove a disk is safe to erase or repurpose.",
       "<strong>Model</strong> — vendor + model string from <code>smartctl -i</code>.",
       "<strong>Capacity</strong> — formatted human-readable.",
       "<strong>Temperature</strong> — current °C, coloured by the disk-type threshold (NVMe runs warmer than SATA).",
@@ -96,7 +96,7 @@
     "overviewItems": [
       "<strong>Identity</strong> — model, serial, capacity, Health badge (Healthy / Warning / Critical).",
       "<strong>Wear & Lifetime</strong> — large life-remaining ring (97 %, 50 %, …) with the source attribute spelled out (<em>Media Wearout Indicator</em>, <em>Percentage Used</em>, …), a wear bar (current consumption %), an <em>Est. Life</em> projection in years and the total Data Written. NVMe drives also show <em>Available Spare</em>.",
-      "<strong>SMART Attributes</strong> — six headline fields on a 2-column grid: Temperature, Power On Hours (with humanised duration like <em>3y 116d</em>), Rotation Rate (or <em>SSD</em>), Power Cycles, SMART Status, Reallocated Sectors, Pending Sectors, CRC Errors. The full attribute table lives in the SMART tab."
+      "<strong>SMART Attributes</strong> — key fields on a 2-column grid: Temperature, Power On Hours (with humanised duration like <em>3y 116d</em>), Rotation Rate (or <em>SSD</em>), Power Cycles, SMART Status, Reallocated Sectors, Pending Sectors, CRC Errors. The full attribute table lives in the SMART tab."
     ],
     "smartTitle": "Tab 2 — SMART",
     "smartImageAlt": "Disk drill-in modal — SMART tab with Run SMART Test buttons (Short / Extended), last-test result and the full SMART attribute table",
@@ -108,11 +108,11 @@
       "<strong>SMART Attributes</strong> — the full attribute table (ID / name / value / worst / status with OK / warning / critical icons). For SATA / SAS, the classical numbered list. For NVMe, the structured fields from <code>nvme smart-log</code> (temperature, available spare, percentage used, data units written / read, host reads / writes, controller busy time, power cycles, unsafe shutdowns, media errors, error-log entries, warning / critical composite temperature time)."
     ],
     "pdfTitle": "View Full SMART Report (PDF)",
-    "pdfIntro": "At the bottom of the SMART tab, the <strong>View Full SMART Report</strong> button generates a printable, archive-ready PDF — the same structured report you'd send to a vendor for an RMA.",
+    "pdfIntro": "At the bottom of the SMART tab, <strong>View Full SMART Report</strong> opens a printable report. Use the browser’s print dialog to save it as PDF for archiving or to share with vendor support for an RMA.",
     "pdfPreviewAlt": "First page of the generated SMART Health Report PDF — Executive Summary with the PASSED ring + Disk Information block",
     "pdfPreviewCaption": "First page of the SMART Health Report — Executive Summary with the PASSED ring and the full Disk Information block. The full PDF below has the SSD wear ring, every SMART attribute and the test history.",
     "pdfDownloadLabel": "Download sample SMART report (PDF)",
-    "pdfSectionsIntro": "The report has five top-level sections:",
+    "pdfSectionsIntro": "The report has six main sections:",
     "pdfSections": [
       "<strong>Executive Summary</strong> — large PASSED / FAILED verdict, plain-language disk health assessment paragraph (\"your disk is healthy / showing signs of wear / failing\"), and four quick stats (report timestamp, last-test type, test result, attributes checked).",
       "<strong>Disk Information</strong> — model, serial, capacity, type (HDD / SSD / NVMe), family, form factor, interface (SATA 3.3 · 6.0 Gb/s, …), TRIM support, current temperature with the optimal threshold, power-on time, power cycles, SMART status, plus the headline counters (pending sectors, CRC errors, reallocated sectors).",
@@ -121,13 +121,13 @@
       "<strong>Last Self-Test Result + Full Self-Test History</strong> — the latest test (type, result, completion message, at which power-on-hours mark) plus a numbered table of every retained test.",
       "<strong>Recommendations</strong> — action items based on the verdict: <em>Disk is Healthy / Schedule periodic tests / Backup strategy</em> for healthy drives, escalating language with replacement guidance when attributes are out of range."
     ],
-    "pdfOutro": "The PDF is produced server-side and downloaded with a stable filename pattern (<code>SMART-&lt;short-id&gt;.pdf</code>) so multiple snapshots over time can sit side-by-side in your archive. Useful when you're tracking degradation across months or sending evidence to vendor support.",
+    "pdfOutro": "The browser builds the printable report; Print and Save as PDF both open its print dialog. Choose a filename such as <code>SMART-&lt;short-id&gt;.pdf</code> when saving. Keep dated snapshots to compare changes over time or share them with vendor support.",
     "historyTitle": "Tab 3 — History",
     "historyImageAlt": "Disk drill-in modal — History tab listing past SMART tests with download and delete actions",
     "historyImageCaption": "History tab — every retained SMART test for this disk. Per row: type, timestamp, \"X days ago\" tag, latest marker, download (raw <code>smartctl</code> output) and delete actions.",
     "historyIntro": "The retained pool of SMART tests for this disk — both short and extended runs that completed. Each entry is the raw <code>smartctl</code> output captured at run time, plus the structured fields the Monitor parsed out for the dashboard. Per-row actions:",
     "historyItems": [
-      "<strong>Download</strong> — saves the raw <code>smartctl -a</code> output as a text file. Identical to what the PDF report parses, useful when you need the exact line a vendor asks for.",
+      "<strong>Download</strong> — saves the retained JSON snapshot with the <code>smartctl -a</code> data used by the report. Useful when vendor support needs the original diagnostic fields.",
       "<strong>Delete</strong> — removes the test from history. The retention limit set in the Schedule tab (<em>Last 5 / 10 / 20</em>) deletes oldest-first automatically; this action is the manual override."
     ],
     "scheduleTitle": "Tab 4 — Schedule",
@@ -154,7 +154,7 @@
       "HDD — typically cooler thresholds.",
       "SSD — moderate thresholds.",
       "NVMe — higher thresholds (NVMe runs hotter by design).",
-      "SAS — same defaults as HDD."
+      "SAS — defaults of 55 °C warning and 65 °C critical, distinct from HDD’s warning threshold."
     ],
     "tempConfigurable": "All four are configurable from <em>Settings → Health Monitor Thresholds</em>.",
     "tempWhyTitle": "Why a history matters here",
@@ -164,7 +164,7 @@
       "<strong>Threshold tuning.</strong> Before raising or lowering a threshold in <em>Settings → Health Monitor Thresholds</em>, the 30-day chart shows the disk's actual operating range so the new value lines up with what the hardware really does rather than a guess."
     ],
     "obsTitle": "Observation history (across tabs)",
-    "obsIntro": "Modern disks fail gradually. A disk can report SMART <strong>PASSED</strong> and still log occasional read errors in dmesg, drop SATA links, or expose pending sectors that come and go. The standard Proxmox UI shows you the current SMART verdict — it does not keep a history of those <em>signals</em>. ProxMenux does, and surfaces them right inside the disk modal.",
+    "obsIntro": "Disk faults can develop gradually. A disk may report SMART <strong>PASSED</strong> while logging read errors in dmesg, losing SATA links or reporting intermittent pending sectors. ProxMenux keeps a history of these <em>signals</em> and shows it inside the disk dialog alongside the current SMART verdict.",
     "obsImageAlt": "Disk Details modal Overview tab showing a healthy disk with SMART status Passed, 0 reallocated/pending/CRC errors, and an Observations section listing one recorded I/O Error event with the raw kernel message, a human translation of the ATA error code, first and last occurrence timestamps and an occurrence count",
     "obsImageCaption": "A disk that <strong>SMART says is fine</strong> can still have an observation history. The card is the historical signal layer underneath the SMART verdict.",
     "obsWhatTitle": "What an observation is",
@@ -177,8 +177,8 @@
     ],
     "obsWhyTitle": "Why ProxMenux records and shows them",
     "obsWhyItems": [
-      "<strong>Disk failure is rarely a single event.</strong> It usually starts with sporadic ATA bus errors, the odd UNC sector, or a couple of medium errors weeks before SMART flips to <em>FAILED</em>. Without persistence those early warnings disappear from dmesg on the next boot.",
-      "<strong>SMART can lie.</strong> A drive can show all attributes green and still be on the way out — the observation layer catches the symptoms SMART doesn't expose (especially ICRC, IDNF, link resets at lower SATA speeds).",
+      "<strong>Faults can develop over time.</strong> Sporadic ATA bus errors, UNC sectors or media errors may appear before SMART reports <em>FAILED</em>. A dmesg buffer alone does not preserve them across a reboot; the observation history does.",
+      "<strong>SMART does not rule out every fault.</strong> A drive can show green attributes while experiencing problems. Observations retain additional symptoms, including ICRC, IDNF and SATA link resets or speed reductions.",
       "<strong>It separates \"is happening now\" from \"happened recently\".</strong> The Health Monitor auto-resolves transient errors as soon as they stop firing, which is great for keeping the active alert list clean — but you still want to see, days later, that this disk had three I/O errors that night. The observation table is the answer.",
       "<strong>It feeds the tiered notification model.</strong> The disk_io detector reads observation rate from this table to decide silent / WARNING / CRITICAL (the sliding 24h window introduced in 1.2.1.2). The history is what makes that classification possible."
     ],
@@ -213,12 +213,12 @@
       {
         "section": "SMART current values",
         "endpoint": "/api/storage/smart/<disk>",
-        "source": "<code>smartctl -A &lt;dev&gt;</code> — refreshed on demand, not cached."
+        "source": "<code>smartctl -A &lt;dev&gt;</code> is one available probe; the detail endpoint also uses full SMART JSON and NVMe-specific data."
       },
       {
         "section": "SMART self-test history",
         "endpoint": "/api/storage/smart/<disk>/history",
-        "source": "Stored under <code>/var/lib/proxmenux-monitor/smart/&lt;disk&gt;/</code> as JSON snapshots."
+        "source": "Stored under <code>/usr/local/share/proxmenux/smart/&lt;disk&gt;/</code> as JSON snapshots."
       },
       {
         "section": "Permanent observations",

web/messages/en/docs/monitor/dashboard/system-logs.json

@@ -48,7 +48,7 @@
       "<strong>Message</strong> — the full untruncated message in a monospace block, ready to copy."
     ],
     "maxLevelStoreTitle": "Journald MaxLevelStore",
-    "maxLevelStoreBody": "On a fresh Proxmox install, journald defaults to <code>MaxLevelStore=warning</code>, which silently drops info-level messages. The Monitor detects this on startup and adds a drop-in (<code>/etc/systemd/journald.conf.d/proxmenux-loglevel.conf</code>) raising the threshold to <code>info</code> so the Logs tab actually has something to show across all severities.",
+    "maxLevelStoreBody": "On a fresh Proxmox install, journald defaults to <code>MaxLevelStore=warning</code>, which silently drops info-level messages. The Monitor detects this on startup and adds a drop-in (<code>/etc/systemd/journald.conf.d/proxmenux-loglevel.conf</code>) raising the threshold to <code>info</code> so informational and more severe messages are stored. This does not include debug messages.",
     "backupsTitle": "Backups",
     "backupsBody": "Proxmox task history filtered to backup-related entries. One row per task (<code>vzdump</code>, PBS transfers, Garbage Collect, Verify) with the status (OK / WARNINGS / ERROR), guest involved, source storage, duration and the UPID. Click a row to load the full task log via <code>GET /api/task-log/&lt;upid&gt;</code> — the same data Proxmox exposes through <em>Datacenter → Tasks</em>, scoped to backups.",
     "notificationsTitle": "Notifications",

web/messages/en/docs/monitor/dashboard/system-overview.json

@@ -5,7 +5,7 @@
   },
   "header": {
     "title": "Dashboard: System Overview tab",
-    "description": "The first tab the dashboard opens on. Four live metric cards across the top, the historical-metrics chart in the middle, and condensed storage / network panels at the bottom — all derived from the same APIs that drive the dedicated tabs.",
+    "description": "The tab the dashboard opens on by default. Four live metric cards across the top, the historical-metrics chart in the middle, and condensed storage / network panels at the bottom — all derived from the same APIs that drive the dedicated tabs.",
     "section": "ProxMenux Monitor · Dashboard"
   },
   "readOnly": {
@@ -13,7 +13,7 @@
     "body": "Nothing on this tab is a control surface — every panel is informational. Actions live in the dedicated tabs they link to: drill into Storage to manage disks, into VMs & LXCs to start / stop guests, into the Security tab to configure auth, and so on."
   },
   "captureAlt": "System Overview tab — four metric cards (CPU, Memory, Active VMs, Temperature), node metrics chart, and Storage / Network summary cards",
-  "captureCaption": "The System Overview tab — what the dashboard opens on. The four cards are live, the chart below is historical, and the two cards at the bottom summarise Storage and Network.",
+  "captureCaption": "The System Overview tab — the default landing tab. The four cards are live, the chart below is historical, and the two cards at the bottom summarise Storage and Network.",
   "topRow": {
     "heading": "Top row: live metric cards",
     "intro": "Four cards in a 2×2 grid on mobile, single row on desktop. Each updates from <code>/api/system</code> every few seconds.",
@@ -102,9 +102,9 @@
     "intro": "Each panel manages its own loading state (<code>loadingStates.cpu</code>, <code>loadingStates.storage</code>, …) so a slow source doesn't block the rest. While a panel is fetching, it shows a pulse-animated skeleton; failed fetches degrade gracefully — for example, a missing temperature sensor renders the card as <em>N/A</em> instead of an error.",
     "items": [
       "<strong>Top metric cards</strong> — refresh every ~5 s. The CPU and temperature panels also receive a 1 s push from the vital-signs sampler.",
-      "<strong>Node metrics chart</strong> — refresh every 30 s, or on timeframe change.",
+      "<strong>Node metrics chart</strong> — loads when opened and when the timeframe or language changes. When a retry is needed, it waits 60 s.",
       "<strong>Storage card</strong> — refresh every 60 s. SMART data is cached longer (the Storage tab triggers a fresh read on demand).",
-      "<strong>Network card</strong> — refresh every 5 s on the active timeframe.",
+      "<strong>Network card</strong> — summary refreshes every 59 s and the traffic chart every 60 s on the active timeframe.",
       "<strong>Manual refresh</strong> — the Refresh button in the header forces all panels to re-fetch immediately."
     ]
   },
@@ -137,7 +137,7 @@
       {
         "card": "Refresh cadence",
         "endpoint": "—",
-        "source": "CPU / network 5 s; storage / VMs 30 s; static info every 5 min. The Refresh button in the header forces an immediate re-fetch on every panel."
+        "source": "System data every 5 s; storage, VMs and network summary every 59 s. The Refresh button in the header forces an immediate re-fetch on every panel."
       }
     ],
     "codeComment1": "# Single call that backs the header pill",
@@ -165,7 +165,7 @@
       {
         "label": "Dashboard index",
         "href": "/docs/monitor/dashboard",
-        "tail": " — the other eight tabs at a glance."
+        "tail": " — the other dashboard tabs at a glance."
       },
       {
         "label": "Architecture",

web/messages/en/docs/monitor/dashboard/terminal.json

@@ -100,7 +100,7 @@
   "auth": {
     "heading": "Authentication",
     "items": [
-      "The WebSocket upgrade carries the JWT in the <code>Authorization</code> header. If auth is enabled and the token is missing or expired, the connection is rejected with HTTP 401 before a PTY is allocated.",
+      "The browser first requests a single-use ticket through <code>POST /api/terminal/ticket</code>, authenticated with a JWT in the <code>Authorization</code> header. It then passes that ticket when opening the WebSocket. The ticket expires after 5 seconds; with authentication enabled, a missing or invalid ticket closes the connection before a PTY is allocated.",
       "If the Monitor sits behind a reverse proxy, the proxy must forward WebSocket upgrades. See the <link>Access & Authentication</link> page for Nginx / Caddy / Traefik snippets."
     ]
   },
@@ -120,7 +120,7 @@
     "headerFix": "Fix",
     "rows": [
       {
-        "cause": "Session JWT expired (24 h window).",
+        "cause": "Session JWT expired when opening or reconnecting a terminal (24 h window).",
         "fix": "Refresh the page and log in again. The terminal isn't designed for unattended sessions, so the JWT lifetime matches the regular dashboard login."
       },
       {

web/messages/en/docs/monitor/dashboard/vms-lxcs.json

@@ -1,7 +1,7 @@
 {
   "meta": {
     "title": "ProxMenux Monitor — Dashboard: VMs & LXCs tab | ProxMenux Documentation",
-    "description": "The VMs & LXCs tab inventories every guest on the host with live CPU / memory / disk usage. Per-guest drill-in shows configuration, resources, backups, full guest logs, notes, and Start / Shutdown / Reboot / Stop controls."
+    "description": "The VMs & LXCs tab inventories every guest on the host with live CPU / memory / disk usage. Per-guest details show configuration, resources, backups, recent Proxmox log results, notes, and Start / Shutdown / Reboot / Stop controls."
   },
   "header": {
     "title": "Dashboard: VMs & LXCs tab",
@@ -10,7 +10,7 @@
   },
   "intro": {
     "title": "The control surface for guests",
-    "body": "Other tabs are read-only; this is the one you act from. Anything that changes guest state goes through <code>POST /api/vms/&lt;vmid&gt;/control</code> with an explicit confirmation and the response is reflected back in the guest's row. There is no force-shutdown without going through the dedicated Stop button."
+    "body": "Use this tab to control guest lifecycles. Lifecycle actions go through <code>POST /api/vms/&lt;vmid&gt;/control</code> with an explicit confirmation and the response is reflected back in the guest’s row. Force shutdown requires the dedicated Force Stop button."
   },
   "topRow": {
     "heading": "Top row: four stat cards",
@@ -186,9 +186,9 @@
         "source": "PVE RRD data (<code>pvesh get /nodes/&lt;node&gt;/qemu/&lt;id&gt;/rrddata</code>) condensed to a chart-friendly shape."
       },
       {
-        "section": "Recent task logs (modal)",
+        "section": "Recent Proxmox log results",
         "endpoint": "/api/vms/<vmid>/logs",
-        "source": "Tasks for that <code>vmid</code> from <code>/var/log/pve/tasks/index</code>."
+        "source": "<code>pvesh get /nodes/&lt;node&gt;/&lt;qemu|lxc&gt;/&lt;vmid&gt;/log --start 0 --limit 1000</code>. A command failure returns an empty list; this does not provide complete in-guest system logs."
       },
       {
         "section": "Backups available for guest",