Service status: current component state
The public API’s liveness route is probed from the visitor’s browser every 30 seconds. Market-feed and reasoning-engine states are taken from the data-sources report. The result covers the current probe only: internal components are not checked, and it is not an availability measurement — no probe history is retained across a reload.
| Component | State | Observed | Source |
|---|---|---|---|
| Public API | — | — | The liveness route, requested by this browser every 30 seconds. |
| Market data feed | 2 of 4 sources real-time | The data-sources report — per-source detail on data sources. | |
| Reasoning engine | UNAVAILABLE | silent · out of credit | The same data-sources report: whether the engine behind extraction and AI-assisted narratives is configured and reachable. |
0 probes this session · 0 failed. Counted in this browser tab only; a reload resets the count.
Availability figures not yet measured
No measurement exists for the figures below; each is shown as an em dash with the reason.
| Figure | Published | Reason |
|---|---|---|
| Monthly uptime percentage | — | The liveness route is stateless and this browser tab retains nothing across a reload; no probe history exists from which to compute a percentage. |
| Trailing 90-day availability | — | No probe history is retained. A server-side probe that records every check is in the pipeline; the figure will be published once 90 days of checks exist. |
| Mean time to recovery | — | No incident register is published, so there are no resolved incidents to average. |
| Incident history | — | No incident register is published. Once one exists, incidents will be listed with start, end and cause. |
The availability target, the downtime formula, the exclusions and the service-credit schedule are published on service levels, together with the conditions that must be met before those terms are in force. Feed-by-feed provenance is on data sources.