How to View and Filter Railway Logs

Last verified on Nov 8, 2026.

Railway captures anything your service writes to standard output or standard error. You can read it in the deployment panel, in the environment-wide Log Explorer, or with railway logs. It uses its own filter syntax for all of them. This guide covers each, the filters, the structured log format, and the retention and rate limits that decide what you can still see.

Three Places to Read Logs

• Deployment panel. Click a deployment in the service window to see its deploy logs. Open the Build Logs tab for the build. This is the first stop when a deploy fails.
• Log Explorer. Click Observability in the top navigation to see logs for the whole environment. It suits problems that span services. It also lets you pick a date range and toggle columns. Right-click any log and choose View in Context to see the lines around it.
• CLI. railway logs, covered below.

There are several log types. Build and deploy logs hold your build output and your service's stdout and stderr. HTTP logs record each request served through Railway's edge. DNS logs record every DNS lookup a service makes, including private network lookups, and appear under a deployment's Network tab in the DNS view.

Filtering Logs

Railway's filter syntax works in the dashboard and in the CLI:

Numeric filters work on deployment logs that use JSON logging, and on HTTP attributes such as @httpStatus, @totalDuration, @responseTime, @txBytes, and @rxBytes.

Common queries:

@level:error AND "failed to send batch"

@httpStatus:500..599

@path:/api/v1/users AND (@httpStatus:500 OR @httpStatus:501)

@responseTime:>1000 @txBytes:>100000

-@service:<postgres_service_id>

@rcode:NXDOMAIN

The first matches error-level deploy logs containing a phrase. The second returns only 5xx responses. The third narrows to one path with either of two statuses. The fourth finds slow, large responses, and the fifth uses @service in environment logs to exclude a noisy database service. The last finds DNS lookups for names that do not exist.

HTTP logs also expose @requestId, @method, @host, @clientUa, @srcIp, @edgeRegion, and @responseDetails, which is populated only when the application fails to respond. DNS logs expose @qname, @domain, @qtype, @rcode, @zone, and @status.

Using the railway logs CLI

With no options in a terminal, railway logs streams deploy logs in real time from the most recent successful deployment. Passing --lines, --since, or --until switches to fetch mode, which returns history and does not stream.

# Live deploy logs
railway logs

# Last 100 lines
railway logs --lines 100

# The last hour, or a window
railway logs --since 1h
railway logs --since 30m --until 10m

# Warnings, with a text match
railway logs --lines 10 --filter "@level:warn AND rate limit"

# Another service and environment
railway logs --service backend --environment production

# Latest deployment even if it failed or is still building
railway logs --latest

Add a log type flag to change what you see. The flags --build, --http, --network, and --dns are mutually exclusive. You can pass a deployment ID to target a specific deployment for deploy, build, and HTTP logs. If the latest deployment failed, build logs are shown by default.

railway logs --build --filter "error"

railway logs --http --status ">=400" --lines 50
railway logs --http --method POST --path /api/users
railway logs --http --request-id abc123
railway logs --http --method GET --filter "@totalDuration:>=1000"

railway logs --network --status dropped

--status takes an exact code, a comparison like >=400, or a range like 500..599, and these HTTP flags compose with --filter. Add --json for newline-delimited JSON you can pipe to jq. Network flow logs, which record connection-level traffic with protocol, direction, peers, ports, and dropped packets, also have their own filter flags such as --direction and --peer.

Structured Logs

Emit one JSON object per line and Railway turns its keys into attributes you can query with @name:value. The message key is required, and level takes debug, info, warn, or error:

{ "level": "info", "message": "New purchase", "productId": 123, "userId": 456 }

Search it with @productId:123. The whole object must be on a single line or it will not parse correctly. JSON also keeps multi-line content like stack traces in one entry.

Railway normalizes everything. Unstructured lines become {"message": "...", "level": "..."}. Output on stderr becomes error and on stdout becomes info, and levels are matched to the nearest of the four names. That means a plain console.error line shows up as an error in the explorer, whatever its contents. See structured logging, log levels, and the JSON logging guide.

Retention and Rate Limits

Upgrading restores logs that previously fell outside the window. Railway does not offer a log drain setting. For longer retention, forward stdout with a log forwarder such as Vector or Fluent Bit, or emit logs from your app with a vendor SDK or OpenTelemetry. See log retention.

Railway also enforces a logging rate limit of 500 log lines per second per replica on all plans. Above that, extra lines are dropped and you see a warning like Railway rate limit of 500 logs/sec reached for replica ... Messages dropped: 50. Lower the verbosity in production, use minified JSON, sample high-frequency events, and combine related entries into one message. See log sampling.

Sending Railway Logs to Sazabi

Sazabi, an AI-native observability and security platform, receives Railway logs from your application rather than from Railway, since Railway has no platform log drain. Set OTEL_EXPORTER_OTLP_ENDPOINT to your Sazabi intake URL on the service's Variables page, with OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf and OTEL_SERVICE_NAME set to Railway's service name reference variable. Then load the OpenTelemetry SDK for your runtime at startup.

Log through your runtime's logger, such as Python logging or pino, winston, or bunyan on Node, because print and console.log stay in Railway's deployment logs and the SDK does not forward stdout. If you cannot add the SDK, run Vector or Fluent Bit as its own Railway service pointed at the same OTLP endpoint. See the Railway endpoint docs, the Railway integration page, the OpenTelemetry integration, and the Fluent Bit integration for forwarder setup. To catch slow responses early, see latency spikes.