Use multiple timestamps
Where available, distinguish the source timestamp, receive timestamp and processed or distribution timestamp. Comparing those stages helps determine whether delay originates upstream, in the network or inside the pricing stack.
Understand the trading session
A symbol that has no updates during a scheduled close is different from a liquid instrument that suddenly stops updating during its active session. Session calendars, holidays and maintenance windows should feed into stale-data logic.
Check source and symbol health separately
A connection can be healthy while one instrument is stale. Conversely, a whole connection failure can affect thousands of symbols. Monitoring at both levels helps failover only the necessary scope.
Avoid one universal timeout
Different instruments update at different rates. A timeout suitable for a major FX pair may not make sense for a less active reference instrument. Thresholds should be deployment-specific and tested against real behaviour.
Make stale state visible
A system should expose stale or unavailable status instead of simply repeating the last value forever. Downstream trading and display applications can then apply the behaviour appropriate to their role.
How this applies to a broker deployment
The exact architecture depends on the selected sources, instruments, platform, regions, data rights and operating model. PriceFeed.xyz scopes those requirements before defining a production design. The examples in this guide explain engineering concepts and do not imply a specific source entitlement, hosting location, latency guarantee or service-level commitment.