Is this a Node project? If so, try: https://docs.railway.com/deployments/troubleshooting/nodejs-sigterm-handling

I dont know what a node project is, but it went back online instantly idk why it showed down for even a brief moment. is this related to github issue today?

no, the github issue today wouldn't cause that. github's only involved when railway builds a new deploy, not in serving traffic, so an outage there can block a deploy but can't take a live site down.

("node project" just means the app is written in javascript, you'd see npm or node in your deploy logs.)

best way to pin it down: open the service's deployments tab and see if anything restarted or redeployed at the exact time you saw the crash page. if something was cycling, the site really is unreachable for a few seconds while the new container boots, and your logs stay clean because the app wasn't running yet. that's the usual reason for down-then-instantly-back.

if nothing restarted then, check if serverless is on in settings, that lets the app sleep when idle and the first visitor has to wake it

I searched for node in the logs, what would you say I should saearch logs to see if it caused a reset or something because this never happened before.

don't search for "node", search for the container stopping/starting. try these in the log filter:

Stopping Container

Starting Container

SIGTERM

if any show up around that time, the container restarted and that's your cause, you'd also see your app's startup line again right after.

quicker still: check the deployments tab for a restart or deploy at that timestamp, that confirms it on its own. if there's nothing in either, it wasn't your container and staff would need the exact time to check the edge.

So weird nothing came up. i see nothing , no bad logs or anything.

good news, that actually tells us something: your app never went down. if it had crashed or restarted, there'd be a trace of it. so whatever went wrong happened before the visitor's request even reached your app.

one thing left for you to check: open your service, go to Settings, and look for an option called Serverless. tell me if it's on or off.

if it's ON, that's likely the whole explanation. serverless lets your app go to sleep when nobody's using it, and the very first visitor after that has to wait for it to wake up, which can show an error page for one moment and then work fine.

if it's OFF, then the hiccup happened in railway's own network layer that sits in front of your app. that's not something you can see or fix, and it's also why your logs are empty. in that case just tell railway staff the exact date and time you saw it (and your timezone), and say there's nothing in your logs or deployments at that moment.

either way, if it only happened once and hasn't come back, it's not something to worry about.

It is off. I have to keep my platform on always has its super complex. That said it was that DNS page showing a page crashed and said host (us) was down) I was laying in bed jumped out of bed but by the time I stood up it was back. So maybe it was railway?

that detail helps a lot. if the page said something about DNS or "can't reach the host", that was your browser's own error page, not one from railway.

the difference matters: a railway error page is dark with railway branding and means railway got your request but couldn't reach your app. a DNS error page is your browser saying it couldn't even find where to send the request, so it never left your device.

that fits everything, your app was fine the whole time (no logs, nothing restarted), and it came back the moment you stood up because your connection or DNS lookup recovered on its own. usually a wifi/ISP hiccup, or your router's DNS blipping for a second.

so it most likely wasn't railway at all. if it happens again, take a screenshot of the actual page you see, that tells you instantly which side it came from.

I thought so too but a client got kicked off same time with a service he was using. but maybe just a coicedence . Hasn't happened since...guess ill just wait and see. Thank you for your help.

fair, a client dropping at the same time does make the local network idea less likely, two people at once is a stretch for a wifi blip. could still be coincidence, or something upstream you both route through.

if it happens again, note the exact time, whether anyone else is hit, and screenshot the page. that's enough for staff to check the edge for that window. good that it's been stable since.