Status
Every light here is a probe that ran when the page loaded, out through the public edge and back the way your requests go. Where a probe can’t prove health it says so rather than showing green.
All probed systems operational
checked 21:24:09 UTCre-probes in 60sTerminal & API
sign-in, entitlements, charts, journal
90 days · 4 of 13 logged days affected
Market data & order flow
depth, DOM, footprint, tape
Gamma & options data
dealer exposure, levels, bridge studies
Website & downloads
marketing site, download, billing
One bar per day, scoped to the surface it affected. Counts are against the incident log, which begins Jul 26, 2026.
One request against the public API health endpoint, through the same edge path your terminal takes. The API answers with its own per-subsystem probes, each run fresh for this check under a tight internal timeout.
API
public edge → origin, end to end
Account database
auth, entitlements, journal
Real-time cache
live gamma, levels, chains
Historical tick store
charts, replay, backtests
The incident record since Jul 26, 2026 — including the ones nobody reported. Most of these I found myself, before a customer did; each entry says how it was caught and what changed so it cannot repeat. Click one to read the whole account.
The upstream network in front of the server went down and came back forty times between the evening of the 6th and the early hours of the 7th — thirty-five of them inside one two-hour window, thirty-two minutes of unreachability in total. The machine itself was healthy the whole way through: its link never dropped, its own error counters never moved, and the system log recorded nothing during any of the windows. The failure was in front of it, and on most of the drops the traces were unambiguous about where — the provider's gateway stopped answering while the hop behind it replied in single-digit milliseconds. The provider attributed the event to a distributed denial-of-service attack against their network. Each window took the site, the API and the live feeds down with it; between them, everything served normally. This is the recurrence the previous entry said would put a ticket in front of them.
What changed
The network watcher I added after the earlier drops now traces the first hops the moment one starts and records which side of the provider's gateway went quiet, so each window is attributed while it is happening instead of argued from correlation afterwards. That gave second-precision timings and a per-drop verdict for all forty, which is what goes to the provider — the previous round had to be reconstructed. Update checks and installer downloads serve from the edge cache and rode through the short windows. Nothing on this machine needed restarting or fixing, which is the honest shape of this one: when the break is on the far side of the gateway, the work I can do is measurement good enough to hand over.
The fixes that came out of these incidents shipped like everything else — the changelog has the full record.
90 days · 4 of 13 logged days affected
90 days · 2 of 13 logged days affected
90 days · 4 of 13 logged days affected
Freshness of the last write from each aggregator daemon, read straight from the live cache. Live means the most recent write landed within twice the expected cadence. These loops run around the clock, so staleness here is real — not an off-hours artifact.
Gamma exposure aggregator
last write 11 s ago · 60 s cadence · sampled via ES
Options chain snapshots
last write 62 s ago · 60 s cadence · sampled via QQQ
IV skew aggregator
last write 58 s ago · 60 s cadence · sampled via QQQ
A server-side sweep of the market-data panel endpoints, run from the origin — the same routes the panels on this site read. Gated means the endpoint answered by enforcing its sign-in tier — alive, just not open to an anonymous probe. A grey light means the sweep couldn’t open a connection for that row, which proves nothing about the endpoint — it is marked unverified, never down.
Not probed yet
Per-venue depth-feed liveness — the futures depth bridge and each crypto venue’s book — has health signals inside the terminal (the ladder measures its feed delay end to end as a number), but no public probe surface yet. Feed-level detail lands here once that probe exists. Until then this page claims nothing about it, because I won’t put a hand-set light on a status page.
A transient cache read miss on the public gamma endpoint fell back to a payload that carried wall levels and summary numbers but no per-strike rows — so for roughly a minute at a time, the desktop Gamma Stream showed wall lines and ghost dots with no bars underneath. The data was never wrong, only missing, and each window healed itself on the next compute cycle. Found the same evening from a screenshot of the panel.
What changed
The fallback now reads the full per-strike payload the aggregator already writes to disk every cycle, capped at fifteen minutes of age so it can never present old strikes as fresh. Verified by forcing the cache miss and watching the fallback serve the complete strike set.
The server's upstream network dropped five times across two evenings — each window brief, the machine itself healthy throughout. Simultaneous inbound and outbound failures with zero OS-level events pinned it on the provider's network rather than this stack; the evidence is written up and a provider ticket goes out if it recurs. During each window the site, the API, and the live feeds were unreachable.
What changed
The edge tunnel now runs as a supervised service with automatic restart, swapped in with zero downtime. A network watcher logs WAN state transitions at fifteen-second resolution so the next provider ticket carries second-precision windows instead of my recollection. Update checks and installer downloads are now cached at the edge, so they keep working through a brief origin drop.
The data service process died at 05:17 server time and nothing noticed: the internal liveness reporting cannot report its own absence, and the scheduled-task self-heal only fires when the task's own action fails — a process killed out from under it reads as success. The levels route served its last export until the staleness cutoff, then refused, and every bridge-study customer was dark until I saw it in my own chart about two hours later and restarted the service.
What changed
The watchdog now lives outside the thing it watches: every five minutes it checks that the process exists AND that the pipeline's output file is fresh — the second catches a process that is up but wedged. It restarts first and alerts after, so the alert usually arrives saying the service is already back. A separate check now reads the levels' actual age out of the cache and probes the API through the public edge, end to end, the way a customer reaches it. Verified by killing the service and watching it return in fifteen seconds.
