3 months ago
Hello Railway Team,
I’m facing a critical issue with my Railway-hosted services and would appreciate your assistance. My user-id is Keshu92.
Summary of the Problem
- None of my deployed services are reachable via their public Railway URLs.
- This issue is affecting multiple projects simultaneously, which suggests it is not application-specific.
- The services appear to start successfully, but then become unreachable, and containers sometimes restart.
What I’m Observing
- Logs show:
- Server starts successfully (
Server running on PORT) - Database initialization completes
- Shortly after, the container stops or restarts
- Server starts successfully (
- No incoming requests are logged when accessing the public URL.
- DNS resolution for the Railway domains is working correctly.
- Even after regenerating domains and redeploying, the issue persists.
Important Context (Billing)
- There was an unpaid invoice ($8.05) earlier.
- This invoice has now been successfully paid (Receipt available, dated April 19, 2026).
- The issue began around the time of the billing restriction and has continued even after payment.
Troubleshooting Already Done
- Verified application code:
- Server binds to
0.0.0.0 - Uses
process.env.PORT - No crashes or unhandled exceptions
- Server binds to
- Ensured single process execution (no conflicting start scripts)
- Redeployed services multiple times
- Deleted and regenerated Railway domains
- Tested via incognito and cleared DNS cache
- Added health endpoint and request logging (no requests are reaching the app)
Key Concern
Since:
- All services are affected
- DNS works but routing does not
- Containers start but are not consistently reachable
I suspect this may be related to:
- Account-level restrictions not fully lifted after payment
- Stale or broken routing/domain mappings
- Health check or service exposure issues at the platform level
Request
Could you please:
- Verify if my account/services are fully restored after the invoice payment
- Check if there are any routing, networking, or healthcheck issues affecting my deployments
- Confirm whether my services are correctly exposed to public traffic
- Advise if any manual intervention is required on my end
This issue is blocking access to all my deployed applications, so any help would be greatly appreciated.
1 Replies
Status changed to Open Railway • 3 months ago
a month ago
Because this is affecting multiple projects after an invoice restriction, only Railway staff can confirm whether the account/workspace restriction was fully lifted. But I would narrow the evidence before changing more domains, because regenerating domains can add noise.
The three checks I would make on one affected service:
-
In Service Settings -> Networking -> Public Networking, confirm the Railway domain exists and that its target port matches the port your app is actually listening on. Railway's public networking docs say the app should listen on 0.0.0.0:$PORT, and the target port/domain routing has to line up with that: https://docs.railway.com/public-networking
-
If a healthcheck is configured, confirm the healthcheck path returns HTTP 200 quickly and on the same port. Railway only switches traffic after healthcheck success, and a bad healthcheck port/path can leave the new deploy failed while the old one remains active: https://docs.railway.com/reference/healthchecks
-
From outside Railway, run
curl -v https://your-service.up.railway.app/healthand save the exact timestamp, status code, and response headers. If the app logs show no request at that same timestamp, that is strong evidence the request is not reaching the container and points back to routing/account/platform state rather than application code.
For Railway staff, I would include one minimal repro service with: project ID, service ID, current deployment ID, public URL, region, healthcheck path if any, restart reason from the Deployments tab, and a curl timestamp where DNS resolves but the app logs receive no request. Given the billing timing, also explicitly ask them to check whether any account-level egress/edge/routing restriction remains attached to the workspace after the paid invoice.