Healthy
healthy
Critical-infrastructure observability · built on the M9K platform
Stop watching dashboards.
Stop watching dashboards.
Start asking your infrastructure.
BigBoard turns live telemetry from your servers, network and power into answers — for the engineer debugging at 2 a.m., the technician in the field, and the people deciding what to spend next.
Plain-language answers from live data
One native agent
No browser-exposed secrets
The shift
Monitoring tells you it's down. It rarely tells you why, what it costs, or what to do next.
Those harder questions usually get answered in spreadsheets, runbooks and chat threads — long after they mattered. BigBoard keeps the answer in the same place as the data.
The usual stack
Status lights and tab-hopping
- A wall of dashboards that says up or down — and little else
- Root cause lives in someone's head, or last quarter's incident doc
- Capacity and cost questions wait for a manual export
- After hours, the first responder is whoever's awake
With BigBoard
One place. Ask in plain language.
- Ask a question; get an answer backed by your real metrics
- The assistant pulls history and correlates across your systems, on the spot
- Utilization and growth trends are a query, not a project
- Alerts open an investigation and do the first triage automatically
One source of truth · four jobs
Observability isn't just an engineering tool. It's a business tool.
The same live data serves the person fixing the problem, the person on site, the person paying the bills, and the person who picks up first. BigBoard speaks to all four.
01
Engineers
Diagnose fast, with evidence
Pull metric history, correlate anomalies across hosts, and query everything you run mid-conversation — without leaving the board or stitching together three tools.
Backed by AI channels · metrics history · cross-object aggregation
02
Field technicians
Troubleshoot on site
Real-time device state and reachability for the rack in front of you, plus an assistant that walks the live data with you — so a site visit ends in a fix, not a follow-up.
Backed by ICMP · SNMP · Modbus · PDU/UPS agents
03
Decision-makers
Spend with evidence
Capacity and growth trends, utilization by site or team, hardware lifecycle and power draw. Telemetry becomes the basis for the next budget — not a guess.
Backed by historical metrics · attribute metadata · group-by trends
04
Support & triage
A first responder that's always on
An always-available assistant that diagnoses against real data before a human is paged — and hands the next person a head start instead of a blank page.
Backed by AI channels · alerting investigations
Ask, and it investigates
Ask in plain language. It queries your live data and shows its work.
BigBoard's assistant doesn't just summarize a chart. It reaches into your systems mid-conversation — pulling metric history, searching devices, and correlating across hosts — then explains what it found and where it looked.
You stay in control: every answer is grounded in your own data, with the queries it ran in plain sight.
The assistant runs server-side, inside the platform. Your API keys never touch the browser — a deliberate design choice after watching the industry burn keys shipped in client-side code.
You
db-2 felt slow this afternoon. What happened?
BigBoard
↳ queried metric history · db-2 · 14:00–18:00
↳ correlated disk & network across 4 peers
Between 15:10 and 15:50, disk read latency on db-2 tripled while inbound network held flat — consistent with a local I/O bottleneck, not replication lag. CPU and memory stayed nominal, and no peer showed the same pattern. Worth checking the slow-query log for that window.
You
Has it happened before?
BigBoard
Yes — a similar 30–40 min spike eight days ago and again last Saturday, both just after 15:00. Looks like a recurring scheduled job.
Compose, don't configure
Describe the view you need. BigBoard builds it.
No widget library to wire up, no drag-and-drop afternoon. Ask for "an executive view of all sites" or "everything wrong right now," and BigBoard assembles the panels — health rollups, top consumers, metric timelines, device detail — into a layout that fits the question.
Save the ones you like. Put the important one on the wall. Hand a customer their own.
A library of purpose-built panel types and layouts — composed for you, not configured by you.
CPU avg
38%
Mem avg
61%
Disk avg
57%
Power
4.2kW
A composed view, built from one sentence. Sample data shown.
What it looks like in use
Built from a sentence. Read at a glance.
The same data, composed for whoever's looking — the engineer on triage and the manager checking trends. These are representative views — or try the live, interactive demo →
- edge-12disk > 90%17s ago
- gw-1mem > 85%6m ago
- cache-5cpu > 80%22m ago
Closest to threshold next
CPU · last 24h
Memory · last 24h
Servers
Network
Power
Coverage
One agent. The whole rack.
BigBoard sees what's actually in your critical infrastructure — not just the servers. A single native agent and a set of protocol pollers cover compute, network, power and industrial gear.
Servers
FreeBSD · Linux · macOS · Windows — CPU, memory, disk, ZFS, network
Network
Switches, routers, firewalls via SNMP v2c / v3
Power
UPS battery & load · Raritan PDU inlets, outlets, sensors
Industrial
Any Modbus TCP device, mapped from a register file
Streaming telemetry
gNMI / OpenConfig from Juniper, Cisco, Nokia, Arista & more
Reachability
ICMP ping checks for anything with an address
Logs
Passive syslog ingestion, alongside metrics
Beyond the rack
External feeds too — e.g. live energy-market pricing
One small native binary, a few hundred KB. Built for each OS, no runtime, no interpreter — your monitoring shouldn't compete with your workloads for the scarce, expensive compute you're paying for.
Few dependencies. Compiled native with no package tree — almost no third-party code for a supply-chain attack to ride in on.
Self-measuring. Each agent reports its own CPU and memory, so the footprint stays honest.
OpenTelemetry-native. OTLP metrics land directly.
Live updates over WebSocket — no refresh button.
Alerting
Alerts that do the first triage.
Define a rule by where it applies in your infrastructure, not by hand-listing devices. When it fires, BigBoard opens an investigation, starts gathering, and routes to the right people.
01 — scope
Rule by subtree
One rule covers a site, a rack, or a device type — and follows new devices automatically.
02 — fire
Open an investigation
Each event becomes a tracked investigation with its own timeline and findings.
03 — notify
Reach the right people
Deliver by email, SMS or webhook, with escalation when it isn't acknowledged.
04 — trust
Backtest first
Replay a rule against real history to see how often it would have fired — before it ever pages anyone.
Email · SMTP
SMS · Twilio
Webhook · HTTP POST
Acknowledge & resolve
Escalation
Investigation history
13
Monitoring agent types, shipped
1hr = 10yr
Same query time, last hour or ten years
OTLP
OpenTelemetry-native ingestion
0
npm / PyPI packages — no dependency tree to poison
For teams who run other people's infrastructure
Many customers, never mixed up.
Managed service providers and multi-site operators get isolation by design, not bolted on after the fact — so onboarding a customer doesn't mean inheriting their risk.
- Per-customer isolation Separate instance, data, configuration and access for every customer.
- Role-based access Grant each team or client visibility to exactly their own infrastructure.
- White-labelable boards Hand a customer a dashboard that looks like yours.
- API for your tools Wire alerts and inventory into the systems you already run.
Pre-launch · early access
Turn telemetry into decisions.
BigBoard is running today. We're opening it to a small set of early teams — operators, MSPs, and the people who have to answer for the spend.