Monitor Railway with Sazabi

Last verified on Nov 8, 2026.

Railway keeps your build and runtime logs for a limited time and has no setting to forward them elsewhere. That shapes how you monitor a Railway service. The data has to leave from inside the application, which also means it can carry more than the platform would add on its own.

Sazabi is AI-native observability and security. For Railway it receives logs and traces straight from your app over OpenTelemetry, and its agent can read Railway itself through a connector.

What Sazabi reads from Railway

On the log side, the Railway source is a set of service variables and the OpenTelemetry SDK. Your app exports logs and traces to the Sazabi intake. The variable OTEL_EXPORTER_OTLP_ENDPOINT points there, and OTEL_RESOURCE_ATTRIBUTES fills in deployment.environment, service.version and railway.deployment.id from Railway's own variables. Those variables are defined in Railway's variables reference: RAILWAY_SERVICE_NAME, RAILWAY_ENVIRONMENT_NAME, RAILWAY_GIT_COMMIT_SHA and RAILWAY_DEPLOYMENT_ID.

Two details matter. print and console.log output is not forwarded, so use a logger such as Python logging, pino, winston or bunyan. And metrics sent to this endpoint are not stored; they belong on the OpenTelemetry Metrics source.

Sazabi ingests OpenTelemetry metrics (Prometheus metrics through an OpenTelemetry Collector) and OTLP traces through the same intake as your logs. It stores each metric data point and each span as a log record that its agent queries alongside your logs, so there is no separate metrics store to run.

On the agent side, the Railway MCP connector authorizes with OAuth and gives the agent tools to read deployment status, build logs and runtime logs, to inspect and update environment variables, and to trigger deployments. The CLI connection adds the railway command to the sandbox with a RAILWAY_TOKEN.

Questions it answers

• Which commit was running when the errors started?
• Did the failures begin in one environment, or in all of them?
• What did the build log say for the deployment that is now failing?
• Which replica region is the slow trace coming from?
• Did an environment variable change shortly before the behavior changed?

A worked example: tying errors to a commit

Because service.version is set from RAILWAY_GIT_COMMIT_SHA, every record from the SDK says which commit produced it. That turns a vague report into a short query:

sazabi logs ask "Group error-level Railway records by service.version over the last 6 hours and show the first error for each version"

Say two versions appear. The older commit has a few scattered errors. The newer commit has hundreds, all starting within a minute of its first record. You now have the commit to review and the deployment to roll back to. Ask the agent in a thread to read the build log for railway.deployment.id through the Railway connector, and check whether it also changed an environment variable.

If the older version shows errors too, the commit is not the whole story. Compare deployment.environment next.

Limits to plan around

Railway's own logs expire. Retention is 3 days on Free, 7 on Trial and Hobby, 30 on Pro and up to 90 on Enterprise. Railway also enforces a rate limit of 500 log lines per second per replica, and drops lines above it with a warning (Railway: Logs). Records sent through OpenTelemetry are exported by your app, so check for exporter errors in the deployment logs if volume looks low.

How it fits with other integrations

If your Railway services already use OpenTelemetry, the OpenTelemetry integration explains the protocol, and OpenTelemetry metrics covers the part this source does not store. Compare Railway with Render and Vercel, or browse the cloud platforms category.