Connect a Third-Party Observability Tool

observabilityopentelemetrymonitoring

Railway's built-in Observability dashboard, logs, and metrics cover container-level health. A third-party observability tool can be useful for those that require longer retention or custom application-level insight. This guide covers two approaches to shipping telemetry off a Railway service, with tradeoffs for each.

Choosing an approach

Approach	Complexity	Best for
Vendor SDK (Datadog, New Relic, Sentry)	Low	Most users
OpenTelemetry (OTLP)	High	Multi-vendor flexibility, open-source backends (Jaeger, Prometheus, Tempo) or swapping vendors without re-instrumenting

Pattern 1: Vendor SDK

Install the vendor's SDK in your app, store credentials as Railway variables, and map Railway-provided system variables to the vendor's tag names so services, releases, and replicas are labelled consistently.

Map Railway variables to vendor tags

Railway provides system variables like RAILWAY_SERVICE_NAME, RAILWAY_DEPLOYMENT_ID, RAILWAY_ENVIRONMENT_NAME, and RAILWAY_REPLICA_ID to every deployment. See the Variables reference for the full list.

Each vendor expects these values under its own variable names. Set them in your service's variables so the SDK picks them up. For example, with Datadog:

Purpose	Railway variable	Datadog variable
Service name	`RAILWAY_SERVICE_NAME`	`DD_SERVICE=${{RAILWAY_SERVICE_NAME}}`
Release	`RAILWAY_DEPLOYMENT_ID`	`DD_VERSION=${{RAILWAY_DEPLOYMENT_ID}}`
Environment	`RAILWAY_ENVIRONMENT_NAME`	`DD_ENV=${{RAILWAY_ENVIRONMENT_NAME}}`
Replica / instance	`RAILWAY_REPLICA_ID`	`DD_TAGS=replica:${{RAILWAY_REPLICA_ID}}`

New Relic uses NEW_RELIC_* variables; Sentry accepts this data through its tag and context APIs in code. Check your vendor's documentation for the exact names.

Auto-instrumentation

Most vendors offer auto-instrumentation that wraps the start command, so traces and metrics are captured without code changes. Set it in the service's Settings, in railway.json, or in a Procfile. For example, Datadog's Node tracer:

Each vendor uses a different wrapper. Datadog on Python uses ddtrace-run; New Relic on Python uses newrelic-admin run-program; Sentry is initialized in code with Sentry.init(). Check your vendor's documentation for the exact command.

Vendor SDKs handle flushing on shutdown automatically.

Pattern 2: OpenTelemetry

OpenTelemetry is a vendor-neutral standard for emitting telemetry. Instrument your app once and point the exporter at any backend that accepts OTLP, including Datadog, New Relic, Honeycomb, Grafana Cloud, SigNoz, or a self-hosted Tempo or Jaeger stack.

Configuration

Set the following variables on your service:

Prefer http/protobuf (port 4318) over gRPC (port 4317) for portability across proxies.

Auto-instrumentation

Node - NODE_OPTIONS="--require @opentelemetry/auto-instrumentations-node/register"
Python - opentelemetry-instrument python app.py

Graceful shutdown

Railway sends SIGTERM to the old deployment when a new one takes over. OTel SDKs do not flush automatically on shutdown. Call shutdown() on the tracer provider from your signal handler, otherwise the last batch of spans is dropped. See Deployment teardown and, for Node-specific signal handling, Node.js SIGTERM handling.

Vendor SDKs flush on shutdown automatically and do not require this step.

Common pitfalls

No log drain feature. Railway does not have a setting to forward stdout from a service to an external intake URL. Most vendors support logs alongside traces and metrics, but the mechanism varies. To forward raw stdout without instrumentation, run a log forwarder such as Vector or Fluent Bit as its own Railway service.

IPv6 over private networking. Railway's private network uses IPv6. If your app exports to a collector running as another Railway service, the OTLP client must support IPv6. See Library configuration for language-specific settings, including StatsD over IPv6 for the Datadog Agent.

IPv6 over public internet. If you export to a public IPv6-only endpoint, enable outbound IPv6 on the service.