22 days ago
We need verifiable clock-synchronization evidence for a financial-data receiver running in a Railway container.
Please confirm officially:
- Whether Railway host clocks are continuously synchronized using NTP or PTP.
- Whether containers can verify the synchronization status and exact UTC source identity.
- The guaranteed maximum clock offset/error.
- The behavior of these guarantees when Railway migrates a deployment between hosts.
- Whether an API, metadata endpoint, attestation, or official document exposes this evidence.
- Whether these properties are contractually guaranteed on Trial, Hobby, Pro, or only Enterprise.
We need objective, machine-verifiable evidence; an approximate statement that hosts “normally have correct time” is insufficient.
1 Replies
22 days ago
Railway does not publish clock-synchronization specifics (NTP/PTP protocol, maximum offset bound, UTC source identity) and does not expose an API, metadata endpoint, or attestation surface that reports synchronization status from inside a container. There is no contractual clock-offset guarantee on any plan, Trial through Enterprise. Host clocks are managed by the platform, but the mechanism and its tolerances are not documented or externally verifiable. Because Railway migrates deployments between hosts for maintenance and infrastructure events, and does not attest clock state across those transitions, a requirement for machine-verifiable synchronization evidence across the lifecycle of a deployment is not met.
Status changed to Awaiting User Response Railway • 22 days ago
15 days ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 15 days ago