Server continuously got crashed!
arjunsinhji
HOBBYOP

5 hours ago

Deploying production apps is already challenging enough — but repeated platform downtime makes it even harder.

Recently faced another issue on Railway where deployments were paused temporarily due to “Limited Access Deploys”, causing the server to go down for live clients.

As developers, we trust cloud platforms not just for deployment, but for reliability, uptime, and client confidence. When production services stop unexpectedly, it directly impacts businesses, client trust, and developer reputation.

Auto-pay subscriptions are always collected on time, so consistent infrastructure and communication should also be a priority.

After redeployed still server got crashed

Awaiting User Response$10 Bounty

5 Replies

Status changed to Open Railway about 5 hours ago


Status changed to Awaiting User Response Railway about 5 hours ago


arjunsinhji
HOBBYOP

5 hours ago

Will provide soon


Status changed to Awaiting Railway Response Railway about 5 hours ago


arjunsinhji
HOBBYOP

4 hours ago


arjunsinhji
HOBBYOP

4 hours ago

IMG_20260522_204211.jpg

Attachments


arjunsinhji
HOBBYOP

4 hours ago

Also need quick response kindly reply


sheeki03
FREETop 10% Contributor

2 hours ago

I would debug this as an application crash first, not a Railway build failure.

From the screenshots, the image builds and the container starts:

server@1.0.0 start
node index.js
Server is running on port 8000

Then the app logs:

MongoDB connection failed: crypto is ...

That means Railway is getting the process to runtime. The crash is happening in the Node/MongoDB startup path after the server begins listening.

I would check this in order:

  1. Open the deploy logs and copy the full line after MongoDB connection failed:. The exact text after crypto is matters. If it says crypto is not defined, fix the Node runtime or the app code. Redeploying the same commit will keep crashing.

  2. Pin the Node runtime so Railway does not choose a different major version than the one you tested locally:

{
  "engines": {
    "node": "20.x"
  }
}

Use 22.x only if you have tested the app and MongoDB driver with Node 22 locally.

  1. If your code uses crypto directly, import it explicitly instead of relying on a global:
import crypto from "node:crypto";

or, for CommonJS:

const crypto = require("node:crypto");
  1. Verify the MongoDB variable without printing the secret:
node -e "console.log(process.version); console.log('has web crypto:', typeof globalThis.crypto); console.log('has db env:', Boolean(process.env.MONGODB_URI || process.env.DATABASE_URL));"

The DB ENV: line in your screenshot only proves that a variable exists. It does not prove the URI is valid, that the credentials are correct, or that the app is reading the same variable name that the code expects.

  1. If MongoDB is another Railway service, use a Railway reference variable from that database service instead of copying a hardcoded URI. If MongoDB is external, verify the username, password, database name, authSource, TLS option, and network allowlist for the deployed environment.

  2. Make the startup failure explicit so the next crash gives you a useful stack trace:

mongoose.connect(process.env.MONGODB_URI)
  .then(() => {
    app.listen(process.env.PORT || 8000, () => {
      console.log("Server is running");
    });
  })
  .catch((err) => {
    console.error("MongoDB connection failed", err.stack || err);
    process.exit(1);
  });
  1. Since the crashed deploy appears to be from Merge pull request #1, compare that PR against the last working deployment. Look specifically for changes to package-lock.json, MongoDB driver/Mongoose versions, environment variable names, and any code that uses crypto.

Status changed to Awaiting User Response Railway about 2 hours ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...