3 days ago
For a Node/Fastify app on Railway Hobby, does Railway or its infrastructure subprocessors store HTTP request bodies beyond real-time processing, particularly latitude/longitude in a POST JSON payload? Our application does not log or persist raw coordinates. Please clarify whether edge logs, security monitoring, traces, or diagnostics capture such bodies, and the retention/deletion periods for any captured copies. Is the published 7-day Hobby log retention a visibility window or guaranteed deletion period? No credentials, user data, or request samples are attached.
4 Replies
3 days ago
The HTTP logs we record for each request hold metadata only: timestamp, method, path, host, status code, timings, request and response sizes, client user agent, source IP, edge region, request ID, and deployment identifiers. There is no request body field, so latitude and longitude sent in a POST JSON body do not show up there. Coordinates placed in the URL path would, because the path is recorded. Anything your app writes to stdout or stderr is kept as deploy logs, so an app that never logs coordinates keeps them out of those logs too. See HTTP logs for the full list of fields.
The 7-day Hobby figure is a visibility window, not when logs are deleted. Every log type (runtime, deploy, build, and HTTP) is stored for a fixed 90 days and then deleted automatically. Upgrading your plan widens how far back you can query within those 90 days. Logs can't be deleted early or one at a time. All logs are stored in US West, whichever region you deploy to.
Status changed to Awaiting User Response Railway • 3 days ago
Railway
The HTTP logs we record for each request hold metadata only: timestamp, method, path, host, status code, timings, request and response sizes, client user agent, source IP, edge region, request ID, and deployment identifiers. There is no request body field, so latitude and longitude sent in a POST JSON body do not show up there. Coordinates placed in the URL path would, because the path is recorded. Anything your app writes to stdout or stderr is kept as deploy logs, so an app that never logs coordinates keeps them out of those logs too. See [HTTP logs](https://docs.railway.com/cli/logs) for the full list of fields. The 7-day Hobby figure is a visibility window, not when logs are deleted. Every log type (runtime, deploy, build, and HTTP) is stored for a fixed 90 days and then deleted automatically. Upgrading your plan widens how far back you can query within those 90 days. Logs can't be deleted early or one at a time. All logs are stored in US West, whichever region you deploy to.
3 days ago
Thank you. Please have Railway staff confirm whether the no-body statement also covers internal security monitoring, traces, diagnostic or incident capture, and subprocessors, not only customer-visible HTTP logs. Please provide an authoritative source for the stated 90-day deletion period and any exceptions. This clarification is needed for an App Privacy disclosure; no location samples or credentials are required.
Status changed to Awaiting Railway Response Railway • 3 days ago
3 days ago
The no-body statement in our earlier reply covers the HTTP logs we record for your service, which have no request body field. We can't extend that statement to internal operational systems or to individual subprocessors. For subprocessors, the published subprocessor list and DPA at railway.com/legal are the authoritative sources.
On retention, the 90-day figure is our policy for how long logs are stored. It applies to every log type (runtime, deploy, build, and HTTP) with no exceptions, and logs are deleted automatically when it runs out. It can't be shortened, and individual entries can't be removed early. The plan figures on the logs docs page only set how far back you can query, which is why the page notes that upgrading immediately restores logs that were outside your plan's window.
Status changed to Awaiting User Response Railway • 3 days ago