System Status
Platform -Public Web -Real-time operational health of DepthSignal infrastructure
Last status: not connected · External independent monitoring: UptimeRobot →
Extended Latency Windows
Source: DB aggregates + live probes + local client net-
PROBE-
DB-
DB-
DB-
DB-
DB-
DB-
DB-
DB-
DB-
DBMethodology
API version: vunknownfallback
Status schema version: not connected to /v1/status
Last updated from DB: not connected
Market data updated: not connected
Server latency windows are expected from /v1/status.latency_analytics and should be computed from internal service-to-service measurements aggregated in the database across containers. Live network latency remains client-observed and is displayed separately as local net metrics.
Trust model: DB canonical historical aggregates,PROBE live response headers sampled by this page,LOCAL client-observed network experience.
Services
Performance Targets
Understanding the latency numbers
Two different numbers measure two different things.
Some readings come from our infrastructure measuring itself. Others come from your browser timing a real request. They will not match, and that is by design.
Server processing (40 to 60 ms)
We probe our own /health endpoint every second. A bare-metal FastAPI handler returning an empty response would finish in 3 to 5 ms. Our number is around ten times higher because /health is not bare-metal. On every probe it runs a real database query (postgres SELECT 1), pings Redis, makes a network call to the market-data service, and reads compliance state. We could shave 45 ms by removing those checks, and in return we would no longer notice when the database is unreachable, when Redis has lost its keyspace, or when the market-data feed has fallen behind. The slower number is the honest one.
Your network round-trip (varies, often 100 to 500 ms)
When the live latency card shows 500 ms in red on a cold session, almost all of that figure is happening on your side. DNS resolution, the TLS handshake, your ISP routing, intercontinental fibre. We do not control any of it. After the first request, the browser reuses the same connection and the figure typically settles to 20 to 30 ms above our server number.
How to tell which is which
The values inside the latency window cards (live, 1h, 6h, 24h, 7d, 14d, 30d, 90d, 180d, 365d) are server-measured. They reflect what our backend spends per request and stay in the 40 to 60 ms range. The values next to each individual service row (148 ms, 266 ms, etc.) are browser-measured, full round-trip from your machine. The gap between the two is your network path.
When to worry
Server figures above 200 ms for more than five minutes mean we have a real problem. Browser figures above 500 ms after multiple consecutive requests usually mean your local network. Open DevTools, Network tab, look at the Timing breakdown. DNS, Connect, SSL, Wait, and Receive will be itemised. If Wait dominates, ping us. If Connect or SSL dominate, the issue is upstream of our control.
99.0%
< 45min/mo downtime-
live probe header average-
database aggregate window-
database aggregate window-
-
-
-
Exchange Connectivity. 0 live / ... registered
External Monitoring
UptimeRobot. Monitor coverage unavailable ↗
External monitor count unavailable. UptimeRobot status page remains the source of current public monitor coverage.
Incident History
Loading recent incident history.