Measurement Methodology

Every HTTP request to the API is timed on the server and recorded with its route template (e.g. /api/accounts/{account_number}), HTTP method, status code, and duration in milliseconds. We never record identity, IP address, query strings, request bodies, cookies, or account numbers.

• Success rate — 2xx/3xx responses ÷ eligible requests.
• Server error rate — 5xx responses ÷ eligible requests. 4xx (client input) is reported separately and is not a server failure.
• Latency p50/p95/p99 — nearest-rank percentiles of server-observed request duration. Excludes client network, DNS, and TLS.

Metrics are aggregated over rolling 1-hour and 24-hour windows. When fewer than 20 eligible requests fall in a window, we report Insufficient Data rather than unstable percentiles or a vanity availability figure.

Health checks (/api/health), the root endpoint, and the reliability surfaces themselves (/status, /api/public/*) are excluded from the denominator so synthetic traffic cannot inflate uptime or success rate.

• The current store is in-memory: history resets on each deploy or restart. A durable store and a 30-day baseline are prerequisites before any public reliability commitment is made.
• Latency is server-side only and does not reflect what a user's browser experiences end to end.
• Per-component status is only claimed for services we instrument (Core API, Database). Others are shown as Insufficient Data, never as operational.

Any future kill-switch timing will distinguish server-side halt acknowledgement, EA observation, close-order submission, and broker-confirmed closure. An API acknowledgement metric will never be presented as proof that a broker closed a position.