---
title: "Railway uptime monitoring | Logdash"
description: "Railway healthchecks only gate deploys. The railway.json, a health route on PORT, and an outside monitor that sends a Telegram alert in 3 steps."
url: https://logdash.io/monitor/railway
---

# 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

 railway.json 

```json
{
  "$schema": "https://railway.com/railway.schema.json",
  "deploy": {
    "healthcheckPath": "/health",
    "healthcheckTimeout": 120,
    "restartPolicyType": "ON_FAILURE"
  }
}
```

 server.js 

```javascript
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

1. **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.
2. **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.
3. **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.

### How do I check Railway uptime? 

For the platform, status.railway.com lists incidents with wide user impact. For your own service, Railway keeps no uptime figure after a deploy goes live, so an external monitor on your public domain is what records it.

### Should I use Railway Uptime Kuma or a hosted monitor? 

Kuma on Railway is one template and a volume, and it can reach the private network. A hosted monitor keeps alerting when Railway itself has a bad hour. If uptime matters, have at least one check that does not run on Railway.

### Does the Railway healthcheck do uptime monitoring? 

No. It runs only while a deploy goes live, to decide whether to switch traffic over. After that Railway does not call the endpoint again, so a broken but running app stays broken until someone notices.

## Keep reading

[All platforms](https://logdash.io/monitor): One page per platform, each with what it already monitors, the gap, and a Telegram alert in three steps.

[Render uptime monitoring](https://logdash.io/monitor/render): Render health-checks each instance and can email or Slack you when a service turns unhealthy, but nothing at Render requests your public URL from outside, so uptime monitoring on Render means an external monitor on a /health route.

[Fly.io monitoring](https://logdash.io/monitor/fly-io): Fly.io gives you health checks that steer traffic between machines and Grafana dashboards of your metrics, but nothing that tells you when the app goes down, so pair the fly.toml check with an outside HTTP monitor that sends you a Telegram message.

[Cloudflare uptime monitoring](https://logdash.io/monitor/cloudflare): Cloudflare has no uptime check on the free plan; Health Checks start on Pro at $20 a month billed yearly and probe your origin directly, so to see what users see through Cloudflare you need an outside HTTP check on a health path Cloudflare never caches or challenges.

[Uptime monitoring](https://logdash.io/features/monitoring): HTTP checks as often as every 15 seconds. When one fails, Telegram tells you before your users do.