When the API is unavailable, buildPayload() generates a full realistic dataset on each refresh using randomized values seeded from four static arrays: PLATS (9 monitored platforms), CLIENTS (10 managed clients), APOOL (12 alert archetypes), and TICKET_DATA (7 ticket records). Each refresh produces new health scores, incident assignments, and alert combinations — making the dashboard appear live even without a backend.

A nine-cell grid across the top of Console 1, one cell per monitored platform. Each cell shows the platform icon, name, operational status, critical alert count, and API latency. A color stripe at the top of each cell indicates health: green for Operational, orange for Degraded, red for Critical. Clicking any platform cell opens the detail pane with that platform's full status.

Seven KPI tiles below the platform grid: Malware alerts, Firewall criticals, Network down, Backup failures, Open tickets, Clients at risk, and SLA compliance percentage. Each tile shows a directional flag (▲ if above 5, — if zero). Clicking any tile opens the detail pane in kpi mode.

All ten managed clients listed with sector, device count, alert count, health score, and a colored dot (red/yellow/green risk indicator). Clicking a client row opens its full detail in the pane including per-platform scores, patch compliance, and backup failure count.

Open ticket count and closed-today count at the top, SLA compliance percentage (green above 95%, orange 85–94%, red below 85%), followed by the full ticket list. Each ticket row shows priority badge (P1 P2 P3 P4), subject, client, assignee, SLA status, and age. Clicking a ticket row opens its detail in the pane.

A semicircular gauge in the right column shows the overall ENV score. Below it, four health bars (Security, Network, Backup, Endpoints) show the breakdown. The gauge animates on each refresh with a 1.2-second stroke transition. Color rules: green ≥85%, orange 70–84%, red below 70%.

The API status panel lists all nine platforms with their current latency in milliseconds and a color-coded status badge. The 7-day chart below shows a stacked bar chart of Critical (red), Warning (orange), and Informational (blue) alert volumes per day for the rolling week.

The left column shows a scrolling stream of active critical alerts, each with a severity badge, title, source (tool and device), timestamp, and client name. New alerts on the current refresh cycle are marked with a NEW badge. Clicking any alert item loads that incident into Console 3's context panel.

Four animated counters at the top of the left column: Malware (SentinelOne criticals), Firewall (FortiGate criticals), Network (Auvik criticals), and Backup failures. These match the values shown in Console 1's KPI strip and animate via the an() helper on every refresh.

The center column shows the active incident feed — up to 10 incidents combining live-injected events from the session (LIVE array) and the simulated pool. Each incident card shows severity, ID, title, detail text, device, platform, client, and timestamp. Clicking an incident card switches to Console 3 with that incident pre-loaded as context.

The right column shows the same ticket queue as Console 1 — all open tickets sorted by priority with SLA status coloring. P1 tickets with SLA breach are highlighted red. Use this column to cross-reference whether a P1 ticket already exists for an active incident before creating a duplicate.

The left column shows the currently active incident: severity badge, incident ID, timestamp, title, detail text, and a fields grid showing Client, Device, Platform, Ticket link (or Unlinked), Status, and Assigned engineer. Below this is the incident selector list showing up to 8 active incidents — clicking any one loads it into the context panel without leaving Console 3.

When switching from Console 2 by clicking an incident card, Console 3 pre-loads that incident automatically and calls switchConsole(3).

Six one-click ticket operations scoped to the currently active incident: Create P1 Ticket (full ConnectWise workflow), Assign to Engineer, Escalate Incident, Clear Alert, Send Client Update, and Close Ticket. These appear in a compact action-row layout with colored Run buttons matching their severity implication.

Six pre-built scripts that run multi-step automated workflows: Remediation Script, Force Patch Cycle, Malware Cleanup, Emergency Backup, Bulk Password Reset, and Generate SOC Report. Each script displays its target systems and a ▶ Run button. All scripts use the same runAction() modal system as the action buttons above.

A stacked bar chart at the bottom of Console 3 showing critical (red) and warning (orange) alert volumes by hour over the last 24 hours. Rendered with Chart.js. The chart re-renders each time Console 3 becomes active to ensure it draws correctly after being hidden.

The platform array in the API response is matched to the static PLATS array by the id field. Use these exact IDs or the merge will not apply: ninja · auvik · forti · s1 · huntress · backup · cw · email · azure

If your API lives at a different path, find fetchData() in the script and update the fetch URL. The path must be relative to the host serving the HTML file to avoid CORS issues.

Nine objects. Each needs id (API match key), name (display name), icon (emoji), and cat (category label). Add or remove platforms by editing this array — the platform grid, API status panel, and KPI strip all render from it automatically.

Ten objects. Each needs name, sector, and devices. Replace with your actual client list. The simulation randomly assigns health risk states on each refresh. The detail pane pulls directly from this array when opening client detail cards.

Twelve alert templates drawn from randomly on each refresh to generate the active incident feed. Each object defines title, sub (source description), sev (crit/warn/info), icon, detail (full explanation), device, and platform. Customize these to reflect the actual alert types your environment generates most frequently.

Seven ticket objects used as the baseline ticket queue. In production, replace this with live data from your PSA via the API. Each object needs p (priority: p1–p4), subject, client, sla (ok/warn/breach), age, and assignee. This array is only used when the API does not return a tickets field.

The cleanest approach is to add a call property to each step and extend runAction() to execute it when present. This keeps the modal animation intact and only replaces the timing simulation with real async calls.

• 1
  Start with read-only actions.Pull Device Logs, Run EDR Scan, Test Connectivity, and Generate SOC Report are safe to wire first — they cannot cause disruption and let you validate the API integration pattern before touching destructive actions.
• 2
  Wire ticket creation next.Create P1 Ticket in ConnectWise is the highest-value action for most MSPs and has no security risk. Wire it to your PSA API and test against a sandbox board before going to production.
• 3
  Wire destructive actions last.Isolate Endpoint, Kill Process, and Block IP affect live systems. Wire these after the read-only and ticket actions are validated. Add a confirmation prompt step before the destructive API call.