Railway uptime monitoring
Railway calls your healthcheckPath only while a new deploy goes live and never after, so uptime monitoring on Railway means an external monitor that requests your public domain every few minutes and alerts you when it fails.
What Railway gives you
- A deploy healthcheck. Railway calls healthcheckPath until it gets any 2xx, for up to 300 seconds by default, and marks the deploy failed if it never does. The old deploy keeps serving.
- A restart policy, ON_FAILURE, ALWAYS or NEVER, which acts when the process exits.
- Project webhooks on every deploy state change, including Failed and Crashed.
- Monitors on the Observability dashboard that alert on CPU, RAM, disk or egress thresholds by email, in-app or webhook. They need the Pro plan.
The healthcheck is the one people mistake for monitoring, and Railway says plainly that it does not monitor the endpoint after the deployment has gone live. A process that is up and returning 500 to every request has not crashed, so nothing restarts and no webhook fires. The same goes for a custom domain that stopped resolving or a database that went away. Railway's own docs send you to the Uptime Kuma template for continuous checks.
The config and the route
{
"$schema": "https://railway.com/railway.schema.json",
"deploy": {
"healthcheckPath": "/health",
"healthcheckTimeout": 120,
"restartPolicyType": "ON_FAILURE"
}
}const express = require('express');
const { Pool } = require('pg');
const pool = new Pool({
connectionString: process.env.DATABASE_URL,
connectionTimeoutMillis: 3000,
});
const app = express();
app.get('/health', async (req, res) => {
res.set('Cache-Control', 'no-store');
try {
await pool.query('select 1');
res.json({ ok: true });
} catch {
res.status(503).json({ ok: false, error: 'db' });
}
});
app.listen(process.env.PORT || 3000, '0.0.0.0');Listen on PORT, because Railway injects it and uses the same value for the deploy healthcheck. That check arrives with the hostname healthcheck.railway.app, so if your app only answers allowlisted hosts, add it or every deploy fails. The same route then serves the deploy gate and the outside monitor. A healthcheckTimeout of 120 seconds is plenty for most apps; the 300-second default only makes a broken deploy take longer to fail.
Railway uptime with Serverless on
Serverless puts a service to sleep once it has sent no outbound traffic for 5 to 10 minutes. Answering a request from the internet counts as activity, so a monitor that checks every minute keeps the service awake for good and Serverless saves you nothing. At the 5-minute free interval it can fall asleep between checks, and Railway warns that the first request to a sleeping service may get a 502, which Logdash records as down. Turn Serverless off on any service you monitor.
Three steps to an alert
- Add the public domain Create a service in Logdash and give its monitor https://yourapp.up.railway.app/health, or your custom domain. Private network addresses are not reachable from outside, so it has to be the public one.
- Pick the interval Every 5 minutes on the free plan, every minute on Builder, every 15 seconds on Pro. Each check stores the status code and the response time.
- Break it on purpose Stop the database under the running deploy. Do not test with a broken deploy: the healthcheck would reject it and keep the old one serving, which is the gate doing its job. The route returns 503, the next check flips the monitor to down, and a Telegram alert arrives with the status code and the error.
Railway Uptime Kuma or a hosted monitor
Logdash vs Uptime Kuma on Railway
| Feature | Logdash | Uptime Kuma on Railway |
|---|---|---|
| Where it runs | Outside Railway | A Railway service next to your app |
| Monitor types | HTTP checks, push heartbeats on Pro | HTTP, keyword, TCP, ping, DNS, Docker and more |
| Reaches the private network | No, public URLs only | Yes, anything the project can reach |
| Fastest interval | 15 seconds on Pro | 20 seconds, on your usage bill |
| Alert channels | Telegram and webhook | More than 90 providers |
| Upkeep | None | Volume at /app/data, image updates, backups |
When Uptime Kuma on Railway is the better pick
- You need to check services on the private network that have no public domain.
- You need TCP, DNS or keyword checks, or alerts in Slack, Discord or email. Logdash has HTTP, heartbeats, Telegram and webhooks.
- You want the history in your own SQLite file. Attach the volume at /app/data before you create the admin account.
- The catch: a Railway routing incident takes your app and your monitor down together. Many teams run Kuma inside and one free outside check as well.