Skip to content
MARKET CONTEXT PLATFORMNOT FINANCIAL ADVICE

System Status

Platform -Public Web -

Real-time operational health of DepthSignal infrastructure

Last status: not connected · External independent monitoring: UptimeRobot →

Checking...
DB UPDATED n/aDBSTATUS UPDATED not connectedSTATUS

Services

API Gateway/health-
CHECK
Orderbook Engine/v1/symbols-
CHECK
Flow Intelligence/v1/health-
CHECK
Historical Store/v1/tiers-
CHECK
Auth & Billing/v1/payment-methods-
CHECK
SSE Streaming/v1/health-
CHECK
Backtesting/v1/health-
CHECK
AI-Assisted Interpretation/v1/health-
CHECK
Status Telemetry/v1/status-
CHECK

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.

Uptime SLA

99.0%

< 45min/mo downtime
Server Live Avg

-

live probe header average
Server 1h Avg

-

database aggregate window
Server 24h Avg

-

database aggregate window
Uptime Actual 24h

-

Uptime Actual 7d

-

P95 Server Latency (24h)

-

Stale Feed Rate (24h)

-

Observability confidence: monitored services unavailable · external probes unavailable

Exchange Connectivity. 0 live / ... registered

Loading exchanges

External Monitoring

UptimeRobot. Monitor coverage unavailable

External monitor count unavailable. UptimeRobot status page remains the source of current public monitor coverage.

MONITOR COVERAGE UNAVAILABLE

Incident History

Loading recent incident history.

Live Platform, API, and Exchange Status | DepthSignal