The railway logs CLI command fetches logs from a single deployment (by default, the most recent successful one), while the web UI's log viewer aggregates logs across all deployments for a service. The gap you're seeing on July 13 is because those logs belong to a different deployment than the one the CLI selected. You can target a specific deployment by passing its ID as a positional argument (railway logs <DEPLOYMENT_ID>), or use --since and --until with different deployments to piece together the full timeline.

I dug into this further and the "different deployment" explanation was correct.

The deployment ID I supplied turned out to be a deployment in the wrong environment. On top of that, it happened to be an idle deployment: its entire log history is a boot banner on July 12 and a shutdown line on July 14, with nothing in between. So it genuinely emitted no application logs on July 13 — the missing day wasn't truncated or lost, it just never existed for that deployment. The real July 13 activity lived on the active production deployments in a different environment.

So: my confidence that "this single command shows lines from both July 12 and 14, therefore it's the right deployment" was misplaced — a boot line and a shutdown line two days apart look exactly like a deployment that spanned both dates, which is precisely what it was.

While chasing this I did find one genuine, separate CLI behaviour worth flagging, unrelated to the deployment mixup above. Testing historical fetches against a single (correct) deployment, sorting the returned events by their time field:

• --since T16:00 --until T17:00 (1h window) → 107 lines, full window covered.
• --since T16:00 --until T18:00 (2h window) → 209 lines, full window covered.
• --since T12:00 --until T18:00 (6h window) → exactly 500 lines, but only 13:39–18:00 covered (earliest ~1h40m dropped).
• --since T00:00 --until T+24h (24h window) → exactly 500 lines, but only the last ~6h covered (first 18h dropped).
• --since T00:00 (no --until) → exactly 500 lines, all from now — nowhere near the requested start.

In other words, with -n omitted a historical fetch returns at most ~500 lines, and when a range is requested it returns the newest ~500 within that range, silently dropping older lines with no gap marker and no warning. Passing -n 5000 removes the limit — the 24h window then returns 2111 lines covering the full span, and --since alone returns 4085 lines back to the requested start. (The effective default line count isn't documented, so I can't say whether ~500 is a client default or a server-side fetch cap.)

That truncation is easy to mistake for missing/lost logs, so it might be worth either documenting the default -n limit on the railway logs page, or emitting a warning when a bounded --since/--until fetch is cut short by the line cap. But that's a minor nice-to-have — the original issue here was entirely my deployment/environment mixup, so thanks for bearing with me, and feel free to close this out.