Uptime monitoring for Railway apps
Railway's dashboard tells you if your service is running. SitePulse tells you if your users can reach it. External 1-minute checks on your production URLs, with email alerts when deploys crash, databases go silent, or cold starts break your API. Free for 5 monitors.
The outage Railway can't detect
Railway restarts a crashed container in under a minute. But during that minute, every user request fails — and Railway doesn't send you an email. Your service shows “Running” in the dashboard 60 seconds later. Nobody told you about the downtime.
SitePulse probes your URL every minute from outside Railway. The moment a probe fails, you get an email. When the service recovers, you get a second email with the exact downtime duration.
What to monitor on a Railway app
Production web service
Your main app URL. Catches crashes, out-of-memory kills, failed migrations, and broken environment variables within one probe interval.
/api/health endpoint
Add a route that queries your database (SELECT 1) and returns 200 or 503. This catches Railway Postgres degradation, Redis downtime, and connection pool exhaustion before users notice.
Background workers
Expose a status endpoint on your worker process that returns 200 while healthy. Monitor it. Workers silently die more often than web processes — usually from memory leaks or unhandled promise rejections.
Cron jobs
If you use Railway Cron or a custom scheduler, point a monitor at the job's HTTP trigger endpoint. Know within minutes when a daily report or cleanup job starts failing.
External dependencies
Build a /api/health/deep endpoint that checks your Stripe, Resend, or OpenAI integrations. Distinguish between 'your code is broken' and 'your vendor is broken' during an incident.
Public status page
Turn on SitePulse's free status page. Share it with customers. When Railway has an incident, link your status page in Discord — users see real data instead of wondering if it's just them.
Set it up in 60 seconds
- Sign up — free, no credit card.
- Add your Railway service URL (custom domain or *.up.railway.app).
- Add /api/health if you have one, plus any critical API routes.
- Check interval: 5 min on Free, 1 min on Pro ($9/mo).
- Email alert fires the moment any monitor goes red.
What you get
1-minute checks
On Pro plan ($9/mo). Free plan checks every 5 minutes — enough for side projects.
SSL expiry alerts
Get an email 14 days before your TLS certificate expires. Railway doesn't handle custom-domain renewal for you.
Public status page
Free on every plan. Custom slug, shareable URL, 30-day uptime history.
Add monitoring before your next Railway deploy
5 monitors, 5-minute checks, email alerts, public status page — free forever. No credit card.
Frequently asked questions
Railway has health checks built-in — why use an external monitor?+
Railway's health checks tell the platform whether to route traffic to a container. They don't tell you whether the application is actually responding correctly to real requests. A service can pass Railway's TCP health check and still 500 on every HTTP request because of a broken env var, a failed database migration, or a crashing background worker. SitePulse hits your public URLs from outside Railway — exactly as a user would — and alerts you the moment something returns an unexpected status.
My Railway service crashes and auto-restarts. Is that a problem?+
Yes, and Railway won't tell your users. A crash-restart cycle takes 10–60 seconds; during that window your users get connection refused or 502 from Railway's proxy. SitePulse detects that window and emails you immediately. Over time, crash-restart patterns show up as downtime spikes in your 30-day uptime history — which is useful data to bring to a post-mortem.
How do I monitor my Railway Postgres database?+
Don't expose your database port publicly. Instead, add a /api/health route to your app that does a cheap database query (SELECT 1) and returns 200 or 503 accordingly. Point SitePulse at that route. Now if Railway's managed Postgres goes degraded or your connection pool exhausts, SitePulse catches it within a minute.
Railway generates random subdomains — what URL do I monitor?+
Monitor your custom domain, not the random *.up.railway.app URL. If you haven't set up a custom domain yet, monitor the stable *.up.railway.app URL that Railway assigns to your service — it doesn't change between deploys. Avoid monitoring per-deploy preview URLs as they expire.
Can I monitor a private Railway service?+
Only if it has a public endpoint. For internal services, the best approach is to add a lightweight health-check route that exercises the service's core functionality, then make that one route accessible. For fully private services with no public surface, consider Railway's built-in metrics or a log-based alerting solution.