CPU utilization ↗
—
Memory —
Operations / Overview
C++20 · WEBASSEMBLY · LOCAL OBSERVABILITY
Service overview
A watchful fly. A working C++ engine. An incident you can explore.
30 INPUT SAMPLES · LOCAL SIMULATION
A quiet service meets a busy afternoon.
01 Baseline02 Surge03 Errors04 Outage05 Recovery
Each sample goes through the C++ brain and explicit incident policy.
Demo inputs stay in this browser. No real alerts are sent.
Read-only polling every 10 seconds. HTTPS and CORS required. No credentials sent.
Waiting for inputRead-only · local journal · no remediation
Response latency ◷
—
Per input sample
Error rate ⌁
—
Traffic —
Availability ◉
—
Waiting for recording
The watch station
🪰3D preview unavailable in this browser
INPUT → RESPONSEStarting…
Standing watchAwaiting data
00:00/ 00:00
Recorded inputs drive the neural simulation. Suggestions follow the incident policy.
TRY AN INCIDENT
Demo laboratory
Normal signals · choose a scenario and watch the fly react.
Inject custom metrics
Latency
ms · threshold 750CPU
% · threshold 85Errors
% · threshold 5THE RECORDING, AT A GLANCE
Incident log
HealthyDegradedCriticalRecovering
| TIME | STATE | ASSESSMENT | SUGGESTION |
|---|
THIS BROWSER ONLY
Incident journal
Incidents open after three consecutive bad samples. Recovery requires three healthy samples.
UNDER THE WINGS
C++ where the work happens.
FlyOps connects ordinary service metrics to a portable neural simulation. The same C++ adapter runs natively and in the browser. An explicit threshold policy handles incidents while we establish a reliable baseline.
C++20Shared native core
256Browser fixture neurons
20 ticksPer accepted sample
180 framesNative / WASM parity test
One metric contract
Demo scenarios, same-origin browser probes, and external collectors supply the same validated sample. Unavailable metrics stay unavailable.
Two explicit outputs
FlyBrain computes neural spikes and voltage. The C++ threshold policy assesses service health. Neural activity animates the fly; it is not trained incident confidence.
A local audit trail
Three bad samples open an incident. Confirmed recovery closes it. Source-separated journals and an alert cooldown keep the demonstration legible.
MEASURE, DON'T GUESS
How does it run on your device?
A separate engine processes 256 samples after 32 warm-up samples. Measures the validation → C++ simulation and policy → JSON pipeline, including in-memory incident bookkeeping. Scheduling yields, initialization and warm-up are excluded.
Median / sampleNot measured
p95 / sampleNot measured
Mean / sampleNot measured
Local measurement only. The dashboard stays active; browser load can affect results.
CORRECTNESS BEFORE PROMOTION
Does the incident policy behave as expected?
Replay ten labeled synthetic cases: sustained pressure, errors, outage, traffic, a transient spike, missing metrics, and a recovery relapse. This checks the explicit threshold policy and local incident journal. It is a regression suite, not a claim about production detection quality.
Expected states matchedNot evaluated
Missed / unexpected incidentsNot evaluated
Longest detection delayNot evaluated
Uses a separate engine. Demo and observed journals stay unchanged.
What this demonstrates—and what remains to validate
The browser uses a synthetic 256-neuron wiring fixture. The native adapter has also replayed the 165,122-neuron full graph; that is integration evidence, not a browser performance claim. The input mapping is an engineering choice, not a validated biological sensory pathway. GitHub Pages exposes no host CPU, memory, total traffic, or application error-rate feed. Browser probes describe a visitor's own requests, not independent global uptime. No production actions or remote notifications run here.