Skip to content
Knowledge base

Monitor a Railway app: uptime checks and cron heartbeats

Railway gives you a managed container, not a server, so there is no box to install anything on. What external monitoring looks like on a managed platform: an HTTP check on the public domain, heartbeats for cron jobs and private workers, and error tracking wired to Railway's own deploy variables.

1. Know what a managed platform changes

On Railway you do not own the host, so there is no persistent server for a monitoring agent to live on. That removes one layer (no host metrics to collect yourself) but leaves the two questions that still matter entirely yours: does the service answer from where your users are, and did the scheduled work actually run. Railway's dashboard shows deploys and resource graphs from the inside; neither answers those two from the outside.

2. Create an HTTP check on the public domain

Point a check at the domain Railway gave the service (the up.railway.app address, or your own custom domain if you attached one). The check probes it on your chosen interval from the regions you select, each region reporting separately, and alerts route to email, Slack, webhook, or your existing paging tool the moment a region confirms a failure.

3. Give private services and cron jobs a heartbeat

A Railway worker with no public domain, reachable only over the private network, cannot be probed from outside at all. Same for anything you run on Railway's cron schedule. Both get a heartbeat monitor instead: the job or worker pings a unique RealUptime URL each time it runs or on a loop, and silence past the interval plus grace is what fires the alert. Put the ping after the work succeeds, so a failing job never reports a false all-clear.

4. Wire in error tracking with Railway's deploy variables

An HTTP check catches "the app is down"; RealUptime Errors catches "the app is up but throwing". Railway sets RAILWAY_GIT_COMMIT_SHA and RAILWAY_ENVIRONMENT_NAME on every deploy; pass them to the Errors SDK's release and environment fields and every error is tagged with the exact commit and environment it happened on, which turns "something broke overnight" into "this deploy broke it".

5. Finish with a status page

Add the HTTP check and the heartbeats as components on a status page, so users and teammates get the same measured answer instead of asking you. The page shows per-region state from the same probes that page you.

Go deeper

The full reference lives in the docs: RealUptime + Railway documentation. Error codes named above are each explained in the error-code reference.