Add http logs

[dmedov]

Summary

This adds HTTP request log support to railway logs and railway service logs.

Users can now query request logs from the CLI with the same workflow they already use for build and deploy logs, including filtering by Railway log query syntax and streaming live request traffic from an interactive terminal.

What changed

• added --http to railway logs and railway service logs
• added GraphQL query support for deployment HTTP logs
• added plain-text and JSON formatting for HTTP log entries
• added live follow support for HTTP logs
• updated command help and examples
• added parse coverage for the documented HTTP log example commands

Examples

railway logs --http --lines 50
railway logs --http --filter "@path:/api/users @httpStatus:200"
railway logs --http --json --filter "@requestId:abcd1234"
railway service logs --http --lines 10 --filter "@httpStatus:404"

[dmedov]

@Milo123459 hello! could you check changes to support https logs, very useful for development via agents

[Milo123459]

blocked by previous comment. other then that, all good

[Milo123459]

Hmm, I think this is probably not the right approach- if we can use subscriptions we should. I'll have a look into it so we don't have to do a workaround like this

[dmedov]

thank you!

Fixed this to use the subscription path instead of the polling workaround.

The HTTP logs subscription does work here, but it needed the subscription window args (anchorDate, afterDate, afterLimit) to behave like a live tail. I updated stream_http_logs to use that subscription shape and validated it against a real Railway service with fresh requests while the stream was attached

[Milo123459]

i've got this working locally using subscriptions. lmk if i should just push to this branch

[dmedov]

thank you, i think you could push your implementation also or check mine, let's just make it happen in any way 👍

[dmedov]

hello! could we merge?

[dmedov]

hello @Milo123459! could we merge?

[brody192]

Since HTTP logs are tied to a specific deployment rather than a service, a user could be watching HTTP logs, make a deployment, and the logs will just stop coming in without any indication of why.

So, to avoid this confusion, please implement a poller running on a 5-second loop to detect when the current deployment is removed, close the websocket connection, and notify the user that the deployment was removed.

[m-abdelwahab]

Hey @dmedov, thank you so much for the PR!

I tested this against a live account and pushed a follow-up commit with a few additions:

• Bug fix: The httpLogs query was using limit/startDate/endDate params, but the backend resolver uses
  anchor-based pagination (beforeLimit/anchorDate/beforeDate). This caused --lines 50 to return only 1 result.
  Switched to the correct params.
• JSON field parity: Added all 20 HttpLog fields to both GraphQL fragments so --json output matches the
  dashboard
• Filter discoverability: Added --method, --status, --path, --request-id as typed flags (all require --http) so
  agents and new users can construct queries from --help alone.

Also expanded the --filter help text to list all available fields and operators

[dmedov]

Hey @dmedov, thank you so much for the PR!

I tested this against a live account and pushed a follow-up commit with a few additions:

• Bug fix: The httpLogs query was using limit/startDate/endDate params, but the backend resolver uses
  anchor-based pagination (beforeLimit/anchorDate/beforeDate). This caused --lines 50 to return only 1 result.
  Switched to the correct params.
• JSON field parity: Added all 20 HttpLog fields to both GraphQL fragments so --json output matches the
  dashboard
• Filter discoverability: Added --method, --status, --path, --request-id as typed flags (all require --http) so
  agents and new users can construct queries from --help alone.

Also expanded the --filter help text to list all available fields and operators

Thank you @m-abdelwahab , nice filters