Project ID:
4ad0daef-0101-4a89-bd13-8e6b477312cd
Service ID:
3c953baa-b27f-4500-8de3-8a231c745a1d

Hey, on Railway there's no such difference between web service and a worker, both of them are treated as a service and will run indefinitely. One thing that I can think off is that your background service is using way too memory and thus OOM acts on it.

Hi again,

That is interesting, the process is very small (Discord.js bot, no web server running, no heavy tasks), and it consistently gets terminated within 20-30 seconds even though it logs in successfully.

A few questions that I have;

Is the container actually being killed by OOM (out-of-memory), or is it receiving a normal SIGTERM from the platform?
Is there a way to see the memory usage graph or the exact reason for the SIGTERM for this service?
What memory limit is currently applied to this service/environment?

In the logs I only see:
Stopping Container npm error signal SIGTERM

No stack trace or crash from Node itself.

If this is OOM-related, I’d like to confirm whether:
The service is hitting a memory limit, or if there is some automatic idle / lifecycle rule still stopping it

On your service metrics, there's a memory chart, however, if your service experiences a rapid spike in memory usage, the chart often fails to register it. I can assure you that Railway has no idle / lifecycle rule

The memory limits depends on your plan, if you're on a Hobby plan, the limits are 8gb and 8vCPU per service.

Thanks, that rules out OOM then I guess…

Since the service has 8GB RAM and still receives SIGTERM shortly after startup, could you please check from the platform side:

• What component is sending the SIGTERM (supervisor / deploy system / lifecycle manager)?

• Whether the process is being considered “completed” or “exited” by Railway?

Right now the service is started with:
node dist/index.js

The bot logs in successfully and stays running (event loop active), but Railway still stops it.

Is there any requirement for background services to keep STDOUT active or to prevent the supervisor from treating the process as finished?

I'm not part of the Railway team, just a community member, unfortunately can't do that for you.

ah okay that makes sense, do you have a suggestion for what I can do to try and fix this? im kind of lost haha 😅 maybe I can force the process to never look idle or something?

imma try and apply

setInterval(() => {}, 1 << 30);

to the bottom of my index.ts, hopefully it will keep the event loop permanently alive and preventing it from thinking it finished?

Again, there's no system for killing your application if it's on idle (well, only if you're on Serverless, but you said that it's disabled). Railway does not detect any sort of event loop idle.

okay gotcha, well then I am out of ideas on how to fix this lol, I feel like I tried everything

I'm doing some tests now to check if Railway emits alerts for OOM, give me a minute.

hm, then it sounds like the node process itself may be exiting on its own and Railway is only sending SIGTERM after the process ends.

In that case I suspect something in my code (or one of the background systems like BumpReminder / DB init / startup flow) is calling process.exit() or throwing an unhandled error after initialization, but I am not sure what does this…

Do you by chance know if Railway logs anywhere whether the process exits normally vs being force-killed? Or if there is a way to see the real exit code before SIGTERM?

From my perspective, the bot logs in successfully and then the container stops with no visible stack trace :/

Do you maybe see this error on our service?

nope, never seen that yet.

the one to the left is a new one i just made an hour ago or so to see if the issue was related to something else but it didnt work out lol

and regarding your question, no I don't think Railway logs that. Then yeah, I think your service is crashing somewhere else.
Maybe you can add those lines to check?

    process.on('unhandledRejection', (error) => { 
      console.log(`Unhandled Rejection: ${error}`); 
    });

    process.on('uncaughtException', (error) => { 
      console.log(`Uncaught Exception: ${error}`); 
    });

gotcha, well I already have this implemented into my index file from earlier, had the same idea

uhmm no logs then? yeah definitely weird.

Yeah very weird, it should have been working by now I imagined :/ It doesn’t look like an exception or rejection.

And the shutdown always happens right after this log line:
[BumpReminder] Loaded last bump from history: ...

instead of using npm, try using the node command directly, might help a little bit more

I've heard some weird issues with package mangers running commands on Railway due to how they handle signals but just shot in the dark

oh yeah and I also have npm start

ill try something rq, ill have a look at one of my other files that prints
[BumpReminder] Loaded last bump from history
and see if there is something I oversee

Try adding try catch everywhere 🥲

Also Railway offers SSH, might help the debug part a little bit more tolerable. And try to replicate your Railway environment as close as possible (same env variables and all), if it crashes then a debugger would be the option.

If your code is public, I wouldn't mind taking a look too <:salute:1137099685417451530> really intrigued by this.

Okay, I have now added extensive logging in index.ts (exit / beforeExit / startup try-catch) to catch any silent exits, and I’m redeploying to see if I can capture where the process ends. I’ll also try reproducing it locally with the same env variables. The code is currently private, but if this continues I can make a minimal public reproduction or share the relevant files with you! I’m very curious about what is causing this issue myself lol.

I really appreciate you out here trying to help me out bro! This has been bugging me for 2 days now haha and I am getting really tired of it. xD

Let me know how it goes! and I understand your pain, had the same issue of silently crashing, replicating the environment did the trick for me

okay I have ran some testing but it seems with no good results. If this build I am deploying right now doesnt work I'll let you have a look if you are still interested!

Yep, totally just let me know. If you prefer to give me private access, just send me an invite to my github at

okay just invited you!

Can you change your railway.json code to use Railpack instead? we're deprecating Nixpacks.

alright, did so and also start command runs through railway.json now. Redeploying now, will update you with logs

The bot now boots successfully, logs in to Discord, finishes startup, and prints:
🟢 STARTUP SEQUENCE COMPLETE — BOT SHOULD STAY ONLINE

But a few seconds later Railway still sends SIGTERM and stops the container with no crash, no exception, no OOM, no unhandledRejection, or uncaughtException logs.

FYI:
Serverless is OFF
No healthcheck
No cron
No public domain
No HTTP server running

this is with the most recent deployment^

I'm off to bed soon, and again, I really appreciate you being interested in helping! Please just reach out and tell me if you got something, and I will respond again once I am up tomorrow!

Mine seems to be staying online, will try with more real env variables to confirm

ooo okay that is very strange…

could my variables be at fault maybe?

maybe the env variables are not triggering the exact state you're in so let me confirm mine first

I think it makes sense in a way then. The crashing started happening once all my real env vars are loaded and startup finishes, before that it seemed stable and good. Let me know what variables or config you want me to share so you can match the environment as closely as possible! Thanks again my friend!

mine still seems to not crash with real env variables

really do not know what I could do to replicate it even more

Okay that’s really nice to see but still very strange to me. I’ll have a look at the variables again tomorrow and perhaps you can help me out and we can see if there is something very wrong. Does that sound okay to you?

Yep, no problem, see you tomorrow!

Alright, since the same code + env vars don’t crash on your side, it must be something specific to my Railway deployment/runtime…

What seems different on my side:

• Hobby plan

• Using tsx (not prebuilt dist)

• Start command: tsx src/index.ts

• Builder was Nixpacks originally, now trying Railpack

Let me know what you want me to change next (builder, Node version, start command, etc). I can also give you temporary Railway access if needed! :D

This is my most recent log output

1464961354107457617

I see that the logs updated after supposedly Stopping, and features like Bump reminder still works. Is this perhaps just Railway being dumb and false claiming the process is stopped?
Stopping Container npm error path /app npm error command failed npm error signal SIGTERM npm error command sh -c tsx src/index.ts npm error A complete log of this run can be found in: /root/.npm/_logs/2026-01-25T01_58_09_591Z-debug-0.log [BumpReminder] Reminder sent. [BumpReminder] Reminder sent. [BumpReminder] New DISBOARD message detected. lastBumpAt=2026-01-25T12:33:43.648Z [BumpReminder] New DISBOARD message detected. lastBumpAt=2026-01-25T12:33:43.648Z

That's good to know, and yeah no idea what's happening but if it's working then I'm closing this thread.