Railway uptime monitoring with outside checks and downtime alerts every 30 seconds
Short answer: Railway does not include uptime monitoring. Its healthcheck runs only at the start of a deployment, and its Monitors alert on resource thresholds such as CPU, RAM, disk and network, not on whether your public URL answers. To know within seconds that a Railway app stopped serving customers, you need a check that runs from outside Railway and pages a person.
Railway behavior checked against docs.railway.com
alertping ▸ check preview
simulated
▸ type a domain to watch a check and an alert play out
▸ simulation of 3 regions · US East · EU Central · EU East
▸ waiting…▌
queued
probing▌
If ever goes down, you get:
Alert fired ▸ 2 channels · 6.2 s after first failure
AlertPing app
● DOWN : HTTP timeout confirmed from 3/3 regions (US East, EU Central, EU East). Incident opened.
sms · on-call
AlertPing: DOWN. Confirmed 3/3 regions . First fail: EU Central.
Simulation, not a measurement of your site: this preview runs entirely in your browser and the latencies are generated from the domain you typed. Real checks on your monitors run from our US East, EU Central and EU East regions.
read this first
A deploy-time healthcheck is not an uptime monitor
Railway documents its healthcheck plainly: the endpoint is called at the start of a deployment, Railway checks it before routing traffic to the new version, and it does not monitor the endpoint after the deployment is live. The default timeout is 300 seconds. That is a rollout gate, and a good one, but it says nothing about the three weeks after the deploy when a memory leak, an expired upstream key or a bad migration takes the app down at 2 a.m.
Railway Monitors are the closest thing to alerting, and they are about resources. They email you and send in-app notifications when CPU, RAM, disk usage or network egress crosses a limit, and they require the Pro plan. A service that is out of memory is a real signal. A service that is up, using normal memory and returning an error page to every customer is not, and that second case is the common one.
Railway also offers webhooks for platform events like deploy failures and crashes. Useful, and still inside the platform. If the problem is your domain, your certificate, a bad response body or Railway itself, the events never fire. The same docs point to an Uptime Kuma template for continuous monitoring, which is a service you deploy and run yourself, on the platform it is supposed to be watching.
the honest table
What Railway catches and what only an outside check catches
| Failure | Railway on its own | AlertPing from outside |
|---|---|---|
| Deploy fails its healthcheck | Yes, at deploy time only | Not its job, use your CI or Railway |
| CPU, memory, disk or network crosses a threshold | Yes, Monitors on Pro (email and in-app) | No |
| Service crashes or a deploy fails | Yes, via webhooks and notifications | Sees the symptom, not the cause |
| App returns 500s or the wrong content on a live domain | Not from a scheduled check | Yes, with response assertions |
| Custom domain DNS breaks or the domain lapses | No | Yes |
| TLS certificate fails to renew | No | Yes, with days of warning |
| Railway itself has an incident | Inside the affected system | Yes, from outside |
| Failure confirmed from a second region before paging | No | Yes, three regions |
The two tools do different jobs. Keep Railway Monitors for capacity planning and use an outside check for the question customers actually care about, which is whether the page loads and the API answers.
the mechanics
Setting up outside monitoring for a Railway service
Step one, add the public URL of the service, preferably your custom domain rather than the railway.app address, so DNS and certificate failures are in scope. Step two, add a /health route that runs a trivial query against your database or Redis and returns a fixed string. Step three, assert on that string and on response time, not only the status code, because a proxy can return 200 for a dead app.
Step four, choose 30-second checks for anything customer-facing, confirmed from a second region before it counts as downtime, so a single network blip does not wake anyone. Step five, route alerts to SMS and Slack. SMS, email, Slack and webhook alerts are included on every AlertPing plan with no credit packs. Nothing is installed in your Railway project and no code changes are needed.
If you run a worker or cron service with no public URL, use a heartbeat: the job calls a URL when it finishes, and you are alerted when the call does not arrive. That covers the Railway services a public check cannot reach.
pick one
Which Railway teams need this
Startups selling a SaaS product from Railway, where an hour of downtime is a support queue and a churned trial. Agencies hosting client apps on Railway who need to hear about an outage before the client does. Teams running a public API where partners depend on a response. Anyone who moved from a managed platform with built-in alerts and noticed the quiet.
If your Railway app is an internal prototype nobody depends on, the built-in metrics are enough. When someone pays you, or pages you, for that URL, an outside check is the cheapest insurance you can add.
straight answer
What AlertPing does not replace on Railway
AlertPing does not show CPU, memory or logs from inside your container, and it does not roll back a bad deploy. Keep Railway metrics and logs for diagnosis. We detect and page, and then you open Railway to find out why. Pricing is flat from $49 a month, with 30-second checks from $59.
questions people ask
Railway uptime monitoring questions
Does Railway have uptime monitoring?
No. Railway shows CPU, memory, disk and network metrics per service, and Monitors email you when a threshold is crossed. Monitors need the Pro plan. None of it visits your public URL on a schedule, so nothing tells you the app stopped answering real requests.
Do Railway healthchecks keep checking after deploy?
No. The Railway docs say the healthcheck endpoint is only called at the start of a deployment, and that Railway does not monitor it after the deployment goes live. It gates the rollout. It is not continuous monitoring.
How do I get alerted when my Railway app goes down?
Point an external monitor at your public domain, add a health route that touches your database, assert on a known response string, confirm failures from more than one region and send the alert to SMS or Slack. AlertPing does this every 30 seconds without changes to your Railway project.
Can I run Uptime Kuma on Railway for monitoring?
Railway lists an Uptime Kuma template for continuous monitoring. It works, but you deploy it as another service, you maintain it, and it runs on the platform it is supposed to watch. A platform outage can silence the monitor and the app together.
Does Railway send alerts when a service crashes?
Railway webhooks can deliver platform events such as deploy success, failure and crashes to a URL you choose. That covers crashes the platform sees. It does not cover a running container that returns errors, a broken domain or a failed certificate.
Can AlertPing monitor a Railway TCP service or database port?
Yes. AlertPing checks HTTP and HTTPS endpoints, ports and APIs, so a public TCP proxy port can be checked for a successful connection. For databases, a health route in your app that runs a trivial query is usually the better signal.
Watch your Railway app from outside Railway
AlertPing checks your custom domains and API routes as often as every 30 seconds, confirms every failure from a second region, warns before your SSL certificate expires, and sends SMS, email, Slack and webhook alerts on every plan. Flat pricing from $49 a month, with 30-second checks from $59.