The topbar contains six real-time operational stats that update on every refresh cycle. These are the most important numbers for a shift lead to see at a glance without clicking into any console.

The tab strip sits below the topbar and provides console navigation. Each tab shows a live badge count:

• C1 · OPS Health: Red badge showing total critical alerts (tCrit). Pulses when non-zero.
• C2 · Triage: Red badge showing P1+P2 ticket count. Stays visible to surface triage urgency from any console.
• C3 · Analytics: Static cyan "Charts" badge — no live count, charts are reference data.
• Refresh Countdown: Right-aligned in the tab strip. Shows seconds remaining until next auto-refresh with an animated depletion bar.

The red-bordered scrolling ticker sits between the tab strip and the console content area. It displays the most recent 8 incidents from the current data set, auto-scrolling in a continuous loop.

• Items are color-coded: red for crit, orange for warn, green for info.
• Format per item: SEVERITY · PLATFORM · ISSUE TITLE · CLIENT
• Hover pauses the scroll — CSS animation-play-state:paused on hover. Use this when a specific event needs closer inspection.
• The ticker content is rebuilt on every refresh cycle via buildTicker().

The large left panel contains a 2×2 alert category grid with giant numbers at 56px, a scrollable alert item list below the grid, and a 24-hour trend sparkline at the bottom.

Below the 2×2 grid, individual alert items appear as rows with dot color, label, description, separator dash, and count. These are also clickable and open the same alert category drawer.

The 24h Alert Trend chart at the bottom of this panel is a stacked line chart (Chart.js) showing critical, warning, and info alert counts by hour over the last 24 hours. It provides immediate visual pattern recognition — for example, a spike at 09:00 every morning suggests a scheduled task failure pattern.

This panel renders one row per integrated platform (NinjaRMM, Auvik, SentinelOne, FortiGate, Veeam, PSA). Each row contains:

• A 3px left border (green/orange/red) indicating the platform's current health state.
• A large score number (55–99 range, randomized) with color matching health state.
• The platform icon and name with status label (OK / WARN / CRIT) below.
• A horizontal bar showing the score visually relative to 100.
• Right-aligned meta: uptime percentage and "last seen" timestamp.

The right side of the System Health panel contains a live-refreshing pie chart showing the ratio of Operational / Degraded / Critical platforms. The center label displays the percentage of healthy platforms as a large number. A countdown badge shows when the pie will next refresh (independent of the main refresh cycle — it runs on its own 30-second startPieCountdown() timer started at page load).

This wide panel spans two columns and shows the full client portfolio sorted by risk score (worst first). Three headline KPIs appear above the list:

Each client row in the list shows rank, name, risk score, a mini score bar, and warning/critical badges for backup failures and security incidents. Clicking any row opens the Client Detail Drawer with a 4-cell stat grid and risk factor bars.

The Risk Distribution Donut on the right side of this panel shows the count of clients in each score bucket: <30 (dark red), 30–50 (red), 50–70 (orange), 70–85 (light green), 85+ (bright green). Use this to communicate portfolio health posture at a glance.

The bottom-spanning panel shows all active incidents from the current data set in chronological order (most recent first). Each row has a colored left bar, incident title, source platform badge, client name, timestamp, and severity badge. Clicking any row opens the Incident Detail Drawer with full context and action buttons.

The ticket queue is the core of C2. It contains four KPIs, a priority breakdown bar chart, and a scrollable sortable table.

The Priority Breakdown Bar Chart is a compact horizontal bar showing the split of open tickets across P1/P2/P3/P4. Each priority uses its color token. The chart is 65px tall — just enough for visual proportion without taking up table space.

The Ticket Table below the chart has columns: Priority, Client, Issue, Engineer, SLA, Status. Each row is clickable and opens the Ticket Detail Drawer. The SLA column shows time remaining with color coding: green (healthy), orange (under 1 hour), red (breached, shown as negative).

The engineer workload panel shows three KPIs and a per-engineer bar visualization.

Each engineer row shows name, a load bar (width proportional to open ticket count vs max), a heavy/mid/ok badge, and a OPEN/CLOSED count in monospace. The grouped bar chart below the list shows open vs closed per engineer — a quick visual for identifying both overloaded engineers and strong performers closing more than they open.

The dropdown in this panel lets an engineer select any client to instantly view a 4-cell stat grid (Risk Score, Open Alerts, Backup Fails, Security Incidents) and a device status list showing the first 6 devices sorted by criticality. This eliminates the need to open a separate portal to check on a client during a triage call.

Split into two columns — Integrations on the left and Quick Actions on the right.

The Integrations column shows a live status dot for each connected platform (NinjaRMM, Auvik, SentinelOne, FortiGate, PSA). Status is randomized in demo mode, with a ~10% chance of WARN and ~5% chance of CRIT on each refresh. A pulsing red CRIT dot indicates the platform is unreachable or returning error responses.

The Quick Actions column provides common workflow shortcuts:

A stacked bar chart spanning two columns showing daily alert counts per platform category (Endpoint, Network, Security, Firewall, Backup, Service Desk) over the last 7 days. Four headline KPIs appear above: Total 7d, Peak Day count, Resolved count, and Daily Average. Each platform category uses a distinct color in the stack.

Use this chart to identify platform-specific alert spikes — for example, if Backup has a consistently high bar on Wednesdays, a scheduled backup job is likely failing.

Horizontal bar chart showing SLA compliance percentage per priority tier (P1, P2, P3, P4) with an overall bar at the top. Two headline KPIs: Overall % and P1 % (the most sensitive metric).

A dual-line chart over 14 days showing Mean Time To Acknowledge (blue, target <15 min) and Mean Time To Resolve (green, target <60 min for P1/P2). Four KPIs above: current MTTA, current MTTR, escalations this week, and first-pass resolution rate.

A bar chart showing incident count by hour of day, averaged over the last 7 days. Hours 08:00–18:00 generate significantly more incidents (R(2,10) vs R(0,3) in demo). In production this chart reveals shift patterns — if your 22:00 bar is high, you have overnight monitoring gaps or an early-morning automated task that generates false positives.

A two-line area chart showing daily ticket opened (orange) and closed (green) counts over 7 days. Four KPIs: total opened, total closed, current backlog, and CSAT %. A persistent gap between opened and closed lines indicates backlog growth — the team is not keeping pace with incoming work.

A bar chart showing count of clients in each risk score bucket: <30, 30–50, 50–70, 70–85, 85+. Color graduated from dark red to bright green. Two headline KPIs: Healthy count (score ≥ 70) and Critical count (score < 50). Use this for portfolio-level health reporting in QBRs.

• Click the overlay (dark background behind the drawer) — onclick="closeDrawer()"
• Click the ✕ Close button in the drawer header
• Press Escape — keyboard shortcut bound globally

The client drawer renders animated bar fills using data-w attributes. On drawer open, a 80ms timeout triggers a CSS width transition from 0% to the calculated percentage. The bars represent:

• Open Alerts: min(100, openAlerts × 8) — 13 alerts = 100% red bar.
• Backup Health: 100 − (backupFails × 25) — 4 failures = 0% green bar.
• Patch Gap: 100 − patchFail — 25% patch gap = 75% orange bar.

Controlled by the RINTERVAL constant (default: 30) and the rcountdown variable. The countdown bar in the tab strip depletes linearly over 30 seconds, then triggers triggerRefresh(). In demo mode this regenerates all random data. In live mode, this is where your API calls fire.

// Top of script — adjust RINTERVAL to change the refresh cadence
var DATA=null, CHARTS={}, RINTERVAL=30, rtimer=null, rcountdown=RINTERVAL, curCon=1;

// To change to 60-second refresh:
var RINTERVAL = 60;

When a manual refresh is triggered (topbar button or Ctrl+R), the countdown resets to 30 and the cycle restarts from zero. The refresh button shows ↻ … and is disabled while the fetch is in progress to prevent stacking calls.

The pie chart in C1 has its own countdown (startPieCountdown()) that runs independently of the main refresh. It starts immediately on DOMContentLoaded via triggerRefresh().then(startPieCountdown). The countdown is displayed as a text label below the pie ("Auto-refresh Xs"). When the pie timer expires it calls triggerRefresh(), which resets both timers.

The 10 demo client names and 5 engineer names are defined as top-level arrays and reused across all data generators:

var cNames = [
  'Northgate Industries', 'VertexBio LLC', 'Cascade Dental',
  'Harmon Logistics',    'PeakStar Finance',  'Blue Horizon MSO',
  'Apex Legal Group',    'Ridgeline Schools', 'Summit Healthcare',
  'CoreTech Corp'
];

var engs = ['Alex R.', 'Morgan K.', 'Jamie L.', 'Taylor S.', 'Chris P.'];

// To add clients, extend cNames. To add engineers, extend engs.
// Both arrays are used in pick() calls throughout makeData().

Each ticket has an slaMin value representing minutes remaining until SLA breach. Negative values mean the ticket has already breached. The display format and color are determined as follows:

// slaMin ranges by priority (demo)
P1: R(-30, 180)   // Can start already breached
P2: R(20, 480)    // 20 min to 8 hours
P3/P4: R(60, 1440) // 1 hour to 24 hours

// Display format
if (slaMin < 0) → "BREACHED"  (color: red)
if (slaMin < 60) → "47m remain"  (color: orange)
else → "2h 15m remain"  (color: green)

The C3 SLA chart uses the data.sla object, which contains independent percentage values per priority tier generated on each refresh. These represent the percentage of tickets within that tier that met their SLA requirement over the rolling period. In a live integration, these would come from your PSA's SLA reporting API.

The topbar SLA stat is data.sla.overall — a single number representing blended SLA compliance. It is rendered as a percentage with a % suffix. The color is always green in the topbar regardless of value, since any degradation is better surfaced via the C3 chart where context is available.

Replace the makeData() body with API calls. The fetchData() function is already structured as an async function — add your fetch calls there and return a DATA-shaped object:

async function fetchData() {
  // Replace makeData() with real API calls
  const [ninjaAlerts, s1Threats, pTickets] = await Promise.all([
    fetch('/api/proxy/ninja/v2/alerts').then(r => r.json()),
    fetch('/api/proxy/s1/threats').then(r => r.json()),
    fetch('/api/proxy/psa/tickets?status=open').then(r => r.json())
  ]);

  // Map to DATA shape
  return {
    tCrit: ninjaAlerts.filter(a => a.severity === 'critical').length,
    incidents: s1Threats.map(mapS1ToIncident),
    tickets: pTickets.map(mapPsaToTicket),
    // ... rest of fields
  };
}

// All rendering functions consume DATA — no changes needed there.

• Every refresh regenerates all data — client scores, incident counts, ticket queues, and chart values all change on each 30-second cycle. There is no persistence between refreshes.
• Action buttons fire toasts only — Create Ticket, Acknowledge, Escalate, Update, Reassign, and Close all show a toast notification but do not call any external API.
• API status dots are ~90% OK — with a ~10% chance of WARN and ~5% chance of CRIT per platform on each refresh. This gives the appearance of occasional platform degradation without being always-red.
• The KTC Demo Bar (yellow "DEMO VERSION" notice) is injected via the ktc-home-bar-style block and the #ktc-demo-bar div. Remove both to eliminate this notice in a production deployment.